FWN/Beats/Virtualization

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

Mapping virt-image XML to Cobbler

Bryan Kearney pointed[1] out his posting[2] to @cobbler list describing efforts to reconcile the XML formats used by virt-image and Cobbler[3].

[1] http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00013.html

[2] https://fedorahosted.org/pipermail/cobbler/2008-November/001346.html

[3] https://fedorahosted.org/cobbler/

Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

libvirt Updates Unlikely for Fedora 8

Daniel Veillard began[1] by pointing out that libvirt 0.4.6 has been available[2] for some time, the libvirt in Fedora 8 is ancient, and that Fedora 8 is nearing retirement. Daniel then asked for opinions about pushing out an update so late in the Fedora 8 life cycle.

[1] http://www.redhat.com/archives/fedora-xen/2008-October/msg00014.html

[2] https://admin.fedoraproject.org/updates/F8/FEDORA-2008-8447

There was tepid support for an update. Daniel P. Berrange was convinced it would cause regressions and was firmly against[3] an update. He also suggested users build the new releases if they desire them. Daniel V. mentioned new releases could be built and left in updates-testing[4].

[3] http://www.redhat.com/archives/fedora-xen/2008-October/msg00017.html

[4] https://admin.fedoraproject.org/updates/F8/testing

Maxim Doucet noted[5] there will be no Xen dom0 support in any current Fedora release when F8 is retired, and asked if these test builds would be maintained after F8 reaches end of life. Daniel P. Berrange said[6] F8 will be removed from the update system when it reaches end of life, and said "If you want a long term usable Xen host then for now CentOS or RHEL are the best options."

[5] http://www.redhat.com/archives/fedora-xen/2008-October/msg00019.html

[6] http://www.redhat.com/archives/fedora-xen/2008-October/msg00020.html

Libvirt List

This section contains the discussion happening on the libvir-list.

Host Device Enumeration API Complete

David Lively completed[1] the host device enumeration API which enables querying of physical node hardware features. Also see coverage in FWN #146[2].

[1] http://www.redhat.com/archives/libvir-list/2008-October/msg00617.html

[2] http://fedoraproject.org/wiki/FWN/Issue146#Host_Device_Enumeration_API

Allow Arbitrary Paths to virStorageVolLookupByPath

Chris Lalancette reconciled[1] device names used to track devices within a storage pool with the names returned by virStorageVolLookupByPath. "Basically, it tries to convert whatever path it is given (say /dev/sdc) into the form currently used by the Pool (say /dev/disk/by-id). It then goes and looks up the form in the pool, and returns the storageVolume object as appropriate." This change augments scanning for LVM devices in oVirt.

[1] http://www.redhat.com/archives/libvir-list/2008-October/msg00762.html

Fully Modular Drivers and Optional dlopen Support

Daniel P. Berrange posted[1] a set of 10 patches which "clean up our internal modularization to remove unneccessary dependancies between source files, and make everything follow a consistent pattern of XXXX.h declaring stuff in XXXX.c. Later in the series is plays some games with the linker scripts, and finally makes all hypervisor drivers fully modular, and optionally dlopen'able."

[1] http://www.redhat.com/archives/libvir-list/2008-October/msg00718.html

OpenNebula Libvirt Implementation

Ruben S. Montero announced[1] a new implementation[2] of libvirt by way of the OpenNebula[3] project.

"The implementation of libvirt on top of a distributed VM manager, like OpenNebula, provides an abstraction of a whole cluster of resources (each one with its hypervisor). In this way, you can use any libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a distributed level. "

"For example, you may create a new domain with 'virsh create', then OpenNebula will look for a suitable resource, transfer the VM images and boot your VM using any of the supported hypervisors."

[1] http://www.redhat.com/archives/libvir-list/2008-November/msg00004.html

[2] http://trac.opennebula.org/wiki/LibvirtOpenNebula

[3] http://www.opennebula.org

Having only just learned of OpenNebula, Daniel Veillard asked[4] "isn't OpenNebula in some way also an abstraction layer for the hypervisors, so in a sense a libvirt driver for OpenNebula is a bit 'redundant'?" Daniel also wondered if OpenNebula intended to submit patches to libvirt.

[4] http://www.redhat.com/archives/libvir-list/2008-November/msg00016.html

Ruben confirmed[5] intent to submit patches to libvirt and went on to further describe OpenNebula.

"The libvirt API is just another interface to the OpenNebula system" which "provides an abstraction layer for A SET of distributed resources (like Platform VM Orchestrator or VMWare DRS). In this way, OpenNebula leverages the functionality provided by the underlying VM hypervisors to provide a centralized management (allocation and re/allocation of VMs, balance of workload....) of a pool physical resources."

"For example, oVirt uses libvirt to interact with the physical nodes. With OpenNebula+libvirt, one of the nodes managed with oVirt could be a whole cluster."

[5] http://www.redhat.com/archives/libvir-list/2008-November/msg00020.html

This explaination led Daniel Veillard to the conclusion[6] that this is "the reverse appraoch from oVirt, where we use libvirt to build the distributed management. One interesting point is that your driver would allow to access EC2 using libvirt APIS..."

And, referring to the oVirt example, added "This is a bit against the Node principle of libvirt, and could result in some fun in the hardware discovery mode, but in general the approach might work. Still we are looking at bits on the node to provide capabilities of the hypervisor, which may break in your case, and migration is defined as an operation between a domain in a given node and a connection to another node, so the migration within the OpenNebula cluster won't be expressable in a simple way with the normal libvirt API."

[6] http://www.redhat.com/archives/libvir-list/2008-November/msg00025.html

Daniel P. Berrange was intrigued[7] by this problem. "We might like to extend the node capabilities XML to provide information about the cluster as a whole - we currently have <guest> element describing what guest virt types are supported by a HV connection, and a <host> element describing a little about the host running the HV. It might make sense to say that the <host> info is optional and in its place provide some kind of 'cluster' / 'host group' information."

[7] http://www.redhat.com/archives/libvir-list/2008-November/msg00029.html

Solaris Containers Support

Jovial asked[1] about support for Solaris Zones AKA Containers.

Daniel P. Berrange denied[2] knowledge of Solaris Zone support in libvirt, and went on to describe the state of support for other Solaris virtulization technologies[3].

Sun forked an older libvirt release, and added LDoms support. "Hopefully they'll find the time to re-submit the driver for inclusion in main libvirt codebase again in the future." "There has been work in official [libvirt] releases to support Xen dom0 on Open Solaris, but I think there are still some outstanding patches in the Open Solaris repositories that aren't in our offcial releases." There is also no support for Sun xVM[4] at this time.

[1] http://www.redhat.com/archives/libvir-list/2008-November/msg00005.html

[2] http://www.redhat.com/archives/libvir-list/2008-November/msg00007.html

[3] http://www.sun.com/software/solaris/virtualization.jsp

[4] http://en.wikipedia.org/wiki/Sun_xVM

As to an LDoms patch submission, Ryan Scott from Sun replied[5] "it's a case of too much to do and not enough time. The LDoms port is currently on hold." Ryan also added, the Open Solaris Xen dom0 work is "temporarily stuck on 0.4.0 for the time being, which makes forwarding-porting patches difficult. I hope to update our internal gate to 0.4.6 within a month, which will allow me to send out some patches." and finally "I would like to port libvirt to Zones, but it looks unlikely that I'll have the time to do so."

[5] http://www.redhat.com/archives/libvir-list/2008-November/msg00026.html

oVirt Devel List

This section contains the discussion happening on the ovirt-devel list.

Contributing to oVirt

Will Zhou asked[1] how to contribute to the oVirt project. Alan Pevec pointed[2] out the oVirt contribution page[3] and Richard Jone's page[4] on contributing to open source projects, and described the process as "basically, follow http://ovirt.org/build-instructions.html and checkout 'next' branch from git repositories and send patches to the ovirt-devel list. Create your local git branch and rebase it to 'next' before sending patches with git-send-email. For Git Crash Courses see http://git.or.cz/"

[1] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00358.html

[2] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00359.html

[3] http://ovirt.org/contribute.html

[4] http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/

oVirt Console Conundrum

Richard W.M. Jones referred[1] to a previous discussion[2] on adding guest console access to the Web User Interface while including Windows support. Richard enumerated the options explored thus far:

• A Gtk-based VNC browser plugin. "Unfortunately we couldn't make this stable enough for real production use."

• Launching an external program such as virt-viewer from a browser plugin. "This works, but it's a security issue, and we can't use a Gtk dialog to get around the warning issue because of (1)."

• Running virt-viewer or vinagre as separate, standalone programs. "This works, but requires the user to type in some very long and complicated command line by hand, and there are unresolved authentication problems."

Richared then listed a new fourth option:

• Write a custom C/Gtk/Gtk-VNC Windows program which contacts the oVirt WUI to do authentication, get available consoles, and launch a Gtk-VNC widget with the appropriate tunnelling (openssh.exe based?).

[1] http://www.redhat.com/archives/ovirt-devel/2008-November/msg00040.html

[2] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00004.html

Daniel P. Berrange liked[3] option four: "This is actually quite a good idea - a oVirt thin client desktop [...] Basically this is kind of a cross of virt-viewer + vinagre, but talking to oVirt instead of libvirt. Or you could write a libvirt driver that talks to oVirt - cf the OpenNebula guys."

[3] http://www.redhat.com/archives/ovirt-devel/2008-November/msg00042.html