|
|
| (381 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| | [[Category:Virtualization]] <!-- do not copy into FWN issue --> |
| | |
| {{Anchor|Virtualization}} | | {{Anchor|Virtualization}} |
| | |
|
| |
|
| == 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. | | In this section, we cover discussion of Fedora virtualization technologies on the |
| | | @fedora-virt list. |
| Contributing Writer: [[DaleBewley | Dale Bewley]]
| |
| | |
| === Enterprise Management Tools List ===
| |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
| |
| | |
| === Fedora Xen List ===
| |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
| |
| | |
| === Libvirt List ===
| |
| This section contains the discussion happening on the [http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
| |
| | |
| ==== Host Device Enumeration API Complete ====
| |
| [[DavidLively|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 ====
| |
| [[ChrisLalancette|Chris Lalancette]] reconciled[1] device names used to track
| |
| devices within a storage pool with the names returned by <code>virStorageVolLookupByPath</code>.
| |
| "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 <code>oVirt</code>.
| |
| | |
| [1] http://www.redhat.com/archives/libvir-list/2008-October/msg00762.html
| |
| | |
| ==== Fully Modular Drivers and Optional dlopen Support ====
| |
| [[DanielBerrange|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...
| |
| | |
| [[RubenMontero|Ruben S. Montero]] announced[1] a new implementation[2] of
| |
| <code>libvirt</code> by way of the OpenNebula[3] project.
| |
| | |
| <pre>
| |
| 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.
| |
| </pre>
| |
| | |
| [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, [[DanielVeillard|Daniel Veillard]] asked[4]
| |
| <pre>
| |
| 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.
| |
| </pre>
| |
| | |
| [4] http://www.redhat.com/archives/libvir-list/2008-November/msg00016.html
| |
| | |
| Ruben confirmed[5]
| |
| <pre>
| |
| 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).
| |
| </pre>
| |
| | |
| and
| |
| | |
| <pre>
| |
| 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.
| |
| </pre>
| |
| | |
| [5] http://www.redhat.com/archives/libvir-list/2008-November/msg00020.html
| |
| | |
| This explaination led [[DanielVeillard|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
| |
| | |
| <pre>
| |
| > 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.
| |
| </pre>
| |
| | |
| 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
| |
| | |
| [[DanielBerrange|Daniel P. Berrange]] was intrigued[7] by the problem
| |
| <pre>
| |
| > > 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.
| |
| </pre>
| |
| | |
| [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.
| |
| | |
| [[DanielBerrange|Daniel P. Berrange]] denied[2] knowledge of Solaris Zone support in <code>libvirt</code>, and went on to describe the state of support for other Solaris virtulization technologies[3].
| |
| | |
| Sun forked an older <code>libvirt</code> 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 <code>xVM</code>[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 | | Contributing Writer: [[User:Dale | Dale Bewley]] |
|
| |
|
| As to an LDoms patch submission, [[RyanScott|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."
| | === Fedora Virtualization List === |
| | This section contains the discussion happening on the |
| | [http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list]. |
|
| |
|
| [5] http://www.redhat.com/archives/libvir-list/2008-November/msg00026.html | | ==== Virt Status Report ==== |
| | [[JustinForbes|Justin Forbes]] |
| | posted<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html</ref> a Fedora virtualization status report. |
| | Justin pointed out F13 bugs<ref>http://fedoraproject.org/wiki/Virtualization_bugs</ref> now include Important and Pony classifications in addition to Blocker and Target. |
|
| |
|
| === oVirt Devel List ===
| | <references /> |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list].
| |
|
| |
|
| ==== Contributing to oVirt ==== | | ==== RHEL and Fedora Virtualization Feature Parity ==== |
| [[WillZhou|Will Zhou]] asked[1] how to contribute to the <code>oVirt</code> project. [[AlanPevec|Alan Pevec]] pointed[2] out the <code>oVirt</code> 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.
| | Robert Day wondered how the virtualization features<ref>http://www.redhat.com/virtualization/rhev/</ref> of Red Hat Enterprise Linux 5.4 |
| Create your local git branch and rebase it to 'next' before sending patches with git-send-email.
| | compared to Fedora 12. |
| For Git Crash Courses see http://git.or.cz/"
| |
|
| |
|
| | [[DanielBerrange|Daniel Berrange]] |
| | explained<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html</ref> |
| | "The KVM based virtualization in RHEL-5.4 is not nearly so far behind |
| | Fedora as you might think. The {{package|libvirt}} mgmt stack in RHEL-5.4 was |
| | rebased to be near parity with [[Releases/11|Fedora 11]], and KVM in RHEL-5.4 is |
| | also pretty close to that using what's best described as a hybrid of |
| | kvm-83 and kvm-84." |
|
| |
|
| [1] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00358.html
| | <references /> |
|
| |
|
| [2] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00359.html
| |
|
| |
|
| [3] http://ovirt.org/contribute.html
| | ==== ==== |
| | <references /> |
|
| |
|
| [4] http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/
| | ==== ==== |
| | <references /> |
libvirt