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

Reply via email to