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 F8 is nearing retirement. Daniel then asked for opinions about pushing out an update so late in the F8 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 firmly against[3] an update. Also suggesting 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

This thread is not yet digested...

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

        You may find of interest a new implementation of the libvirt 
virtualization API. This new implementation adds support to OpenNebula, a 
distributed VM manager system. 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. The distributed management is 
completely transparent to the libvirt application. This is, a whole cluster 
can be managed as any other libvirt node.

The current implementation is targeted for libvirt 0.4.4, and includes a patch 
to the libvirt source tree (mainly to modify the autotools files), and a 
libvirt driver.

[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 just learned of OpenNebula, Daniel Veillard asked[4]

  Interesting, but this raises a couple of questions:
    - 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' ? Maybe i didn't understood well the
      principles behind OpenNebula :-) (sorry first time I learn about
      this).
    - what is the future of that patch ? Basically libvirt internals
      changes extremely fast, so unless a driver gets included as part
      of libvirt own code source, there is a lot of maintainance and
      usability problems resulting from the split. Do you intent to
      submit it for inclusion, or is that more a trial to gauge interest ?
      Submitting the driver for inclusion means the code will have to be
      reviewed, released under LGPL, and a voluteer should be available
      for future maintainance and integration issues.

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

Ruben confirmed[5]

Yes you are right, OpenNebula 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. 

The libvirt API is just another interface to the OpenNebula system. The beauty 
is that you can manage a whole cluster of hypervisors using the libvirt 
standard, i.e. in the same way you interact with a single machine. 

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. In this case you could use the great interface from oVirt to manage 
several clusters. And you could abstract those applications from the details 
of managing the cluster (for example, is there NFS in it?, group/user 
policies...)

Finally, and may be adding more confusion, OpenNebula also uses libvirt 
underneath to interface with some of the hypervisors of the physical nodes 
(e.g. KVM). 

and

Yes we are highly interested in contributing the driver. We have no problems 
with the requirements and we can commit resources to maintain and integrate 
the driver.

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

This explaination led Daniel Veillard to the revelation[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..."

also

> 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. In this case you could use the great interface from oVirt to manage 
> several clusters. And you could abstract those applications from the details 
> of managing the cluster (for example, is there NFS in it?, group/user 
> policies...)

  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. Except that things should work conceptually I think.

Daniel V. went on to describe the patch submission process, which was met with enthusiasm by Ruben.

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

Daniel P. Berrange was intrigued[7] by the problem

> >   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. Except that things should work conceptually I think.
> 
> You are totally right, this is putting the standard to the limit ;). There are 
> some function calls that can not be implemented right away or, as you said, 
> the semantics are slightly different. Maybe there is room to extend the API in 
> the future, right now there is no standard way to interface a distributed VM 
> Manager....

This is a really interesting problem to figure out. 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. I won't
try to suggest what now - we'll likely learn about what would be
useful through real world use of your initial driver functionality.

[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/