Bug 643947
Summary: | RFE: Support a logical network switch abstraction | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Daniel Berrangé <berrange> |
Component: | libvirt | Assignee: | Laine Stump <laine> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.1 | CC: | abaron, acathrow, ajia, cpelland, crobinso, dallan, danken, djuran, dyuan, eblake, iheim, laine, martin.wilck, mzhan, shavivi, veillard, xen-maint, xhu, yoyzhang |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-0.9.4-rc1-1.el6 | Doc Type: | Enhancement |
Doc Text: |
When bridged and direct connections are used, the network interface definition of guests managed by libvirt can have host-specific information embedded in the guest config; for example in direct mode, the name of the physical device being used, or in bridge mode the name of the bridge device. In order to make migrations between non-identical hosts possible, this RFE provides a method of removing the host-specific items in the guest's network interface config, placing it in a libvirt virtual network definition instead. The guest can then simply reference the network to use by name, avoiding the necessity to put host-specific info in the guest config. At run-time libvirt will look up the guest definition for the current host, and use that information (which may be different for each host) to setup the guest's network connectivity.
Note that, in addition to making migration possible, this RFE allows setting up "pools" of physical interfaces for use in direct mode - rather than the config for each guest needing to specify a particular device (which must then be reserved for that guest even when it's not running), the guest just references a network - libvirt will then locate an unused (or the least used, depending on which is appropriate) interface, and use that interface instead.
|
Story Points: | --- |
Clone Of: | 636106 | Environment: | |
Last Closed: | 2011-12-06 10:52:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 632760 | ||
Bug Blocks: | 655920, 693512, 703851 |
Description
Daniel Berrangé
2010-10-18 15:42:32 UTC
I just posted a proposal for implementing this functionality upstream. https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html I notice that this RFE doesn't mention openvswitch at all. Wouldn't that offer all you need, and even more, if there was a plugin for configuring openvswitch in libvirt? (In reply to comment #5) > I notice that this RFE doesn't mention openvswitch at all. Wouldn't that offer > all you need, and even more, if there was a plugin for configuring openvswitch > in libvirt? In order to keep the discussion in one place (and to make sure there is full participation, since not everyone on the list is following this bug), I've replied to this question in the mailing list thread given in Comment 4. Please post followups to the mailing list thread. (the summary is that openvswitch cannot be considered an alternative to the proposed code, but that code will likely make it easier to add support for openvswitch to libvirt) I just posted a reply to Oved's latest mail on this topic where I propose what the new host network and guest interface XMLM will look like. Please take a look and see if it fits all the requirements: https://www.redhat.com/archives/libvir-list/2011-April/msg01269.html Here is the latest proposal for how this will work: https://www.redhat.com/archives/libvir-list/2011-June/msg00471.html Please comment appropriately in followup messages on the mailing list. A series of patches providing this functionality has been posted upstream: https://www.redhat.com/archives/libvir-list/2011-July/msg00149.html It is functionally complete, and has gone through rudimentary testing. A series of patches to support this has been pushed upstream, and will be in the next libvirt upstream release: commit 6fe5fde2922405176fbe9315971ab818193af0e0 Author: Laine Stump <laine> Date: Tue Jul 19 22:08:15 2011 -0400 util: define MAX commit a3d95b550bf6a1fa032d7cc70352c88685670bac Author: Laine Stump <laine> Date: Wed Jun 29 00:38:10 2011 -0400 conf: put virtPortProfile struct / functions in a common location commit 524655eea2500196a98af20be3edfa198f870e85 Author: Laine Stump <laine> Date: Mon Jul 18 18:44:38 2011 -0400 conf: virDomainNetDef points to (rather than contains) virtPortProfile commit 07f4136993c3cce619ff92f4687171a335f6bf51 Author: Laine Stump <laine> Date: Sun Jun 26 04:09:00 2011 -0400 conf: support abstracted interface info in domain interface XML commit 40fd7073befbd6e8ed2b6935898079bb2ff874dd Author: Laine Stump <laine> Date: Tue Jul 19 23:01:09 2011 -0400 conf: support abstracted interface info in network XML commit b48e81bf945314d491b0919144dee8565d3d446f Author: Laine Stump <laine> Date: Thu Jun 30 17:05:07 2011 -0400 network: separate Start/Shutdown functions for new network types commit 03caa988a6a1497a012205796f78b2005edc09cf Author: Laine Stump <laine> Date: Sun Jul 3 21:57:45 2011 -0400 qemu: use virDomainNetGetActual*() functions where appropriate commit e9949a586a9a2e6642d6394f85bd58955740b69d Author: Laine Stump <laine> Date: Wed Jul 20 00:06:45 2011 -0400 qemu: use virDomainNetGetActual*() in qemuDomainXMLToNative commit 04711a0f32ac2e9c44081911295b436b2c0a11cf Author: Laine Stump <laine> Date: Mon Jul 4 02:27:12 2011 -0400 network: internal API functions to manage assignment of physdev to guest This error sounds like you don't have a vepa-capable switch connected to the ethernet. If you don't, then this error is expected, and you can't test vepa mode. If that's the case, then you can mark this bug verified because you've tested everything you are able to test, and all of the tests passed. If you *do* have a vepa-capable switch, first see if you can successfully start a domain using this <interface> definition instead: <interface type='direct'> <mac address='52:54:00:1b:6f:e5'/> <source dev='eth0' mode='vepa'/> <virtualport type='802.1Qbg'> <parameters managerid='13' typeid='3193047' typeidversion='4' instanceid='70bf45f9-01a8-f5ee-3c0f-e25a0a2e44a6'/> </virtualport> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> If that fails, then either there's something wrong with your virtualport element, or there is a bug that's unrelated to the new code added for this feature. If it succeeds, then there may be something wrong with the new logical switch code in libvirt (because it effectively creates the above interface definition out of the <interface> and <network> definitions you provided in the failing case above). (In reply to comment #18) > This error sounds like you don't have a vepa-capable switch connected to the > ethernet. If you don't, then this error is expected, and you can't test vepa > mode. If that's the case, then you can mark this bug verified because you've > tested everything you are able to test, and all of the tests passed. > > If you *do* have a vepa-capable switch, first see if you can successfully start > a domain using this <interface> definition instead: > > <interface type='direct'> > <mac address='52:54:00:1b:6f:e5'/> > <source dev='eth0' mode='vepa'/> > <virtualport type='802.1Qbg'> > <parameters managerid='13' typeid='3193047' typeidversion='4' > instanceid='70bf45f9-01a8-f5ee-3c0f-e25a0a2e44a6'/> > </virtualport> > <model type='virtio'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x03' > function='0x0'/> > </interface> > > If that fails, then either there's something wrong with your virtualport > element, or there is a bug that's unrelated to the new code added for this > feature. > > If it succeeds, then there may be something wrong with the new logical switch > code in libvirt (because it effectively creates the above interface definition > out of the <interface> and <network> definitions you provided in the failing > case above). for the switch is not vepa-capable, so I change the bug to verified status. The documentation in upstream commit 073ef15c876a8257a077b8b3aa054da2d6ca2ef9 also need to be pulled in for this bug, Daniel Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When bridged and direct connections are used, the network interface definition of guests managed by libvirt can have host-specific information embedded in the guest config; for example in direct mode, the name of the physical device being used, or in bridge mode the name of the bridge device. In order to make migrations between non-identical hosts possible, this RFE provides a method of removing the host-specific items in the guest's network interface config, placing it in a libvirt virtual network definition instead. The guest can then simply reference the network to use by name, avoiding the necessity to put host-specific info in the guest config. At run-time libvirt will look up the guest definition for the current host, and use that information (which may be different for each host) to setup the guest's network connectivity. Note that, in addition to making migration possible, this RFE allows setting up "pools" of physical interfaces for use in direct mode - rather than the config for each guest needing to specify a particular device (which must then be reserved for that guest even when it's not running), the guest just references a network - libvirt will then locate an unused (or the least used, depending on which is appropriate) interface, and use that interface instead. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1513.html |