|
|
| (382 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 | | Contributing Writer: [[User:Dale | Dale Bewley]] |
| <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 | | === Fedora Virtualization List === |
| extend the node capabilities XML to provide information about the
| | This section contains the discussion happening on the |
| cluster as a whole - we currently have <guest> element describing
| | [http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list]. |
| 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 | | ==== 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