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