From Fedora Project Wiki

< FWN‎ | Beats

(→‎OpenNebula Libvirt Implementation: digesting thread a bit)
 
(378 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]
 
==== Mapping virt-image XML to Cobbler ====
[[BryanKearney|Bryan Kearney]] pointed[1] out his posting[2] to @cobbler list
describing efforts to reconcile the XML formats used by
<code>virt-image</code> and <code>Cobbler</code>[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 [https://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
 
==== libvirt Updates Unlikely for Fedora 8 ====
[[DanielVeillard|Daniel Veillard]] began[1] by pointing out that <code>libvirt</code> 0.4.6 has been available[2] for some time, the <code>libvirt</code> 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. [[DanielBerrange|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
 
[[MaximDoucet|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. [[DanielBerrange|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 [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
 
==== <code>OpenNebula</code> 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 <code>OpenNebula</code>[3] project.
 
"The implementation of <code>libvirt</code> on top of a
distributed VM manager, like <code>OpenNebula</code>, provides an abstraction of a whole
cluster of resources (each one with its hypervisor). In this way,  you can use
any <code>libvirt</code> 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 <code>OpenNebula</code>
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 <code>OpenNebula</code>, [[DanielVeillard|Daniel Veillard]] asked[4]
"isn't <code>OpenNebula</code> in some way also an abstraction layer for the hypervisors, so in a
sense a <code>libvirt</code> driver for <code>OpenNebula</code> is a bit 'redundant'?"
Daniel also wondered if <code>OpenNebula</code> intended to submit patches to <code>libvirt</code>.
 
[4] http://www.redhat.com/archives/libvir-list/2008-November/msg00016.html
 
Ruben confirmed[5] intent to submit patches to <code>libvirt</code> and went on to further
describe <code>OpenNebula</code>.
 
"The <code>libvirt</code> API is just another interface to the <code>OpenNebula</code> system"
which "provides an abstraction layer for A ''SET'' of
distributed resources (like Platform VM Orchestrator or VMWare DRS). In this
way, <code>OpenNebula</code> 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, <code>oVirt</code> uses <code>libvirt</code> to interact with the physical nodes. With
<code>OpenNebula</code>+<code>libvirt</code>, one of the nodes managed with <code>oVirt</code> could be a whole
cluster."
 
[5] http://www.redhat.com/archives/libvir-list/2008-November/msg00020.html
 
This explaination led [[DanielVeillard|Daniel Veillard]] to the conclusion[6]
that this is "the reverse appraoch
from <code>oVirt</code>, where we use <code>libvirt</code> to build the distributed management.
One interesting point is that your driver would allow to access EC2
using <code>libvirt</code> APIS..."
 
And, referring to the <code>oVirt</code> example, added
"This is a bit against the Node principle of <code>libvirt</code>, 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 <code>OpenNebula</code>
cluster won't be expressable in a simple way with the normal <code>libvirt</code>
API."
 
[6] http://www.redhat.com/archives/libvir-list/2008-November/msg00025.html
 
[[DanielBerrange|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.
 
[[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 />

Latest revision as of 18:09, 18 December 2009



Virtualization

In this section, we cover discussion of Fedora virtualization technologies on the @fedora-virt list.

Contributing Writer: Dale Bewley

Fedora Virtualization List

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

Virt Status Report

Justin Forbes posted[1] a Fedora virtualization status report. Justin pointed out F13 bugs[2] now include Important and Pony classifications in addition to Blocker and Target.

  1. ↑ http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html
  2. ↑ http://fedoraproject.org/wiki/Virtualization_bugs

RHEL and Fedora Virtualization Feature Parity

Robert Day wondered how the virtualization features[1] of Red Hat Enterprise Linux 5.4 compared to Fedora 12.

Daniel Berrange explained[2] "The KVM based virtualization in RHEL-5.4 is not nearly so far behind Fedora as you might think. The Package-x-generic-16.pnglibvirt mgmt stack in RHEL-5.4 was rebased to be near parity with 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. ↑ http://www.redhat.com/virtualization/rhev/
  2. ↑ http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html



Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Virtualization&oldid=142485"