|
|
| Line 1: |
Line 1: |
| {{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 on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies. |
|
| |
|
| Contributing Writer: [[DaleBewley | Dale Bewley]] | | Contributing Writer: [[DaleBewley | Dale Bewley]] |
| Line 7: |
Line 7: |
| === Enterprise Management Tools List === | | === 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] | | 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 === | | === Fedora Xen List === |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/fedora-xen 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 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. [[DanielBerrange|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
| |
|
| |
| [[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 === | | === Libvirt List === |
| This section contains the discussion happening on the [http://www.redhat.com/mailman/listinfo/libvir-list libvir-list]. | | This section contains the discussion happening on the [http://www.redhat.com/mailman/listinfo/libvir-list libvir-list]. |
|
| |
|
| ==== Host Device Enumeration API Complete ==== | | === oVirt Devel List === |
| | |
| [[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 ====
| |
| | |
| [[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
| |
| | |
| 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."
| |
| | |
| [5] http://www.redhat.com/archives/libvir-list/2008-November/msg00026.html
| |
| | |
| === <code>oVirt</code> Devel List ===
| |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list]. | | This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/ovirt-devel ovirt-devel list]. |
|
| |
| ==== Contributing to <code>oVirt</code> ====
| |
|
| |
| [[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.
| |
| 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 ====
| |
|
| |
| [[RichardJones|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 <code>virt-viewer</code> 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 <code>virt-viewer</code> or <code>vinagre</code> 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 <code>oVirt</code> WUI to do authentication, get available consoles, and launch a Gtk-VNC widget with the appropriate tunnelling (<code>openssh.exe</code> 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
| |
|
| |
| [[DanielBerrange|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
| |
