Virtualization
In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.
Contributing Writer: Dale Bewley
Enterprise Management Tools List
This section contains the discussion happening on the et-mgmt-tools list
Virt-manager and Virtinst Closely Related
After upgrading virt-manager to 0.6.0, Maikel Dollé received[1] the error ImportError: cannot import name Storage. Cole Robinson explained[2] virt-manager is tied closely with virtinst and installing virtinst 0.400.0 would likely fix the problem.
[1] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00038.html
[2] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00039.html
Migration Support in Virt-manager GUI
Shigeki Sakamoto followed[1] up on a previous[2] request for comments on a patch, submitted by same, which works to allow the migration of domains from within the virt-manager GUI. Daniel P. Berrange suggested[3] using a submenu rather than a pop-up window, and commented on the sanity checks[4] in libvirt.
Live Migration Sanity Checks were recently discussed on @libvir
list (see FWN #141 Live Migration Sanity Checks[5]).
[1] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00045.html
[2] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00016.html
[3] https://www.redhat.com/archives/et-mgmt-tools/2008-September/msg00046.html
[4] http://wiki.libvirt.org/page/TodoPreMigrationChecks
[5] http://fedoraproject.org/wiki/FWN/Issue141#Live_Migration_Sanity_Checks
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
DomU Network Interface Problem Leads to Discussion of HVM Requirements
Guillaume[1] asked[1] about a paravirtualized domU which did not show any network interfaces. There was a suggestion made that this could be due to a lack of HVM support in the host hardware, which isn't the case. Paul Wouters cleared[2] up such confusion by describing the main virtualization techniques used in Fedora. Quoting:
- Xen hypervisor for para_virt guests does not need HVM.
- Problem here is that Fedora 8 is the last release to support this setup on x86_64, though work is in progress to add this support to Fedora 9/10. Para_virt guests are booted via kernel= and rootfs images, or via pygrub, which is just a wrapper for grabbing kernel from bootable disk images.
- Qemu is a software emulator for various architectures including PC hardware.
- It requires no HVM instructions, but it can use them if they exist via the kernel "kvm" code. This is how Fedora9 does its VM's via the libvirt and virt-install. This does NOT [sic] use or require a xen hypervisor.
- Xenner is a software emulation for the Xen hypervisor.
- It requires HVM because it uses the kernel "kvm" code. The idea behind Xenner is that you can run VM's based on kernel-xen kernels (eg migration from Fedora8)
Paul went on to mention other[5] virtualization technologies such as VirtualBox/Vmx, lguest, uml, virtuoso, and openvz.
[1] https://www.redhat.com/archives/fedora-xen/2008-September/msg00018.html
[2] https://www.redhat.com/archives/fedora-xen/2008-September/msg00021.html
In another post[3] Paul suggested that Guillaume's domU may have an initrd which lacks xenblk and xennet, and pointed[4] to a debate in the FC6 era concerning the xenblk kernel module.
[3] https://www.redhat.com/archives/fedora-xen/2008-September/msg00022.html
[4] https://www.redhat.com/archives/fedora-xen/2007-April/msg00054.html
[5] http://virt.kernelnewbies.org/TechComparison
Libvirt List
This section contains the discussion happening on the libvir-list.
Minimal Client-only Libvirt Build
Ben Guthro patched[1] the libvirt spec file to
allow for a minimal client-only build.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00264.html
Access to CPU Flags
Ben Guthro needed[1] to access CPU flags to determine if VMX
features were available, and suggested src/nodeinfo.c would be
the place to parse this. This however raised a concern that adding to the nodeinfo struct breaks the API. Additionally, since this is an x86 specific change, Ben wondered if it would be acceptable.
[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00271.html
Daniel P. Berrange stated[1] "any struct or API in include/libvirt/libvirt.h is immutable to preserve ABI",
and the API shouldn't be specifically x86. Daniel did offer that
the most likely place for exposing CPU flags would be in the
capabilities[3] XML format. Where PAE, VMX, and SVM flags are already exposed.
[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00273.html
[3] http://libvirt.org/html/libvirt-libvirt.html#virConnectGetCapabilities
Ben noted[4] that Xen will report those flags, but oVirt running KVM does not,
and said "It seems to me that it might be useful for some sort of "node" info driver, where we might be able to share code for hypervisor independent info about the physical machine it is running on." Daniel pointed[5] to src/nodeinfo.c as "a place for this useful reusable node info code".
[4] https://www.redhat.com/archives/libvir-list/2008-September/msg00292.html
[5] https://www.redhat.com/archives/libvir-list/2008-September/msg00316.html
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
Other Virtualization News
This section contains virtualization news which may not have been directly discussed on the above mailing lists.