On 01/25/2016 04:30 PM, David Sommerseth wrote:
> On 25/01/16 19:32, Yasha Karant wrote:
>> On 01/24/2016 06:06 PM, Lamar Owen wrote:
>>> On 01/23/2016 01:30 PM, Yasha Karant wrote:
>>>> Perhaps someone else has experienced what I related below and can comment
>>>> -- SL 7x.
>>>>
>>>> 1.  ... For 802.3, I prefer to use a manual configuration, not NetworkManager.
>>> For a dynamic connection even with a wired Ethernet you should use the
>>> supported NetworkManager stack, your personal preferences aside.  NM works
>>> and doesn't require munging for a simple DHCP wired connection.
>>>
>>>> 2.  ...Note that I must use MS Win to work with these devices as the
>>>> application software for the device in question is *NOT* available for
>>>> linux, the device is proprietary (no source code available), and
>>>> CrossOver/Wine does not support USB -- forcing the use of a VM running a MS
>>>> Win gues
>>> Neither VMware nor VirtualBox ship as part of SL.  KVM does, and USB
>>> passthrough works very well with Windows 7 running in a KVM virtual machine
>>> on my laptop.  It just works, and it's already part of SL; why not use it?
>>> Performance is very good in my experience, and I'm running a few pieces of
>>> software in Win 7 for the same reasons as you.  You're also far more likely
>>> to get useful help using KVM, either from the list or from other sources,
>>> such as the Red Hat or Fedora documentation.
>>  From the KVM site (http://www.linux-kvm.org/page/Management_Tools) that has a
>> RedHat logo, there is a list of management interfaces, including VMM (Virtual
>> Machine Manager -- https://virt-manager.org/screenshots/ ) that also appears
>> to be a Red Hat entity.  Anyone using VMM?  VMM appears to allow a true host
>> OS (supervisor, not hypervisor) with the VM ("hypervisor") running under the
>> OS (as with VMWare workstation/player or VirtualBox), thus booting an OS, not
>> a hypervisor that actually provisions for guest supervisors.  Is this correct?
> This was a bit confusing for me (getting late, so probably stupid to reply now).
>
> But .... KVM is the core hypervior.  It is in fact just a kernel module which
> you can load at any time on systems with CPUs supporting hardware
> virtualization (VT-d or similar, most modern Intel, AMD and IBM Power 7/8
> supports KVM).
>
> libvirt is the management backend, which provides a generic API.  libvirt can
> be used against other hypervisors as well, such as Xen, but probably more
> often used with KVM.
>
> qemu-kvm is the KVM virtual machine process.  Each qemu-kvm process is started
> per VM.  You seldom start these processes manually, but they are kicked off by
> libvirt.
>
> virt-manager is a management GUI front-end.  And virsh is a console based
> management tool.  Both connects to the libvirt API.
>
> Further, you can also download an oVirt Live image and boot that on a
> bare-metal or virtual machine.  oVirt can then connect to libvirt and provide
> an even more feature rich management tool.
>
> virt-manager and oVirt can also connect to several systems running libvirt
> simultaneously, so you can manage more hypervisors from a single front-end.
> And there are probably even more front-ends, like "Boxes" (not really tried it).
>
>
> I dunno much about vmware stuff, so I will refrain to comment that.  But
> VirtualBox is also two-fold.  My experience with VirtualBox is now quite old
> (5-6 years ago).  You can start VirtualBox guests without a kernel support
> module loaded, which would work on most hardware.  But performance was not too
> good at all.  If you got the init.d script to build the kernel module, you
> could get quite acceptable performance.  However, I see VirtualBox more like a
> single package which gives you both hypervisor and management tool in a single
> software package.
>
> Even though VirtualBox is more a "single unit" and KVM/Qemu/libvirt consists
> of more components ... you normally don't notice that when you start VMs via
> the management tools.
>
>
> I hope this gave a broader perspective.
>
>
> --
> kind regards,
>
> David Sommerseth
>
Thank you for your detailed exposition.  My primary concern is that I do 
*NOT* want a hypervisor actually controlling the physical hardware; we 
have enough security vulnerabilities with a "hardened" supervisor such 
as EL 7.  My secondary issue is the actual human clock execution time in 
the VM as contrasted with the same OS/environment running on the 
physical hardware.  I have found that current production releases of 
VirtualBox and VMware (e.g., VMware player) provide acceptable 
performance, although the USB interface on VMware now does seem better 
than VirtualBox that evidently still has issues (one of the mysteries).  
As neither VMware player nor VirtualBox seem capable of providing a MS 
Win guest with any form of Internet access to an 802.11 connection from 
the host (in both cases, the claim from a MS Win 7 Pro guest is that 
there is no networking hardware, despite being shown by the guest as 
existing), it is possible that the "native" (ships with) vm 
functionality of EL 7 may address this issue.  Note that older versions 
of VirtualBox with older (pre EL 7) releases of the host and guest (MS 
Win XP) did work with a host 802.11 connection.

As a technical point, the VMs I currently have are in vmdk format for 
VirtualBox, as well as ova and vmx format for VMware.  Can the native EL 
7 vm handle any of these formats or must I again transform to another 
format?

Yasha Karant