[libvirt-users] Hot-migration of OVS Vlan configuration
Hi list, I'm using OVS as backend for guest networking on my hypervisors. VLAN configuration for each interface is specified into the guest XML definition. When I need to change VLAN configuration of a running guest, I first edit the inactive XML to keep the changes for future boots, then I use ovs-vsctl to instruct the changes on the existing OVS Port. The problem happen when the guest is migrated to another hypervisor. The "active" XML is used to instantiate the VM on the destination and this XML doesn't incorporate the changes made to the inactive one. All the changes made on source are lost on the running guest at destination. I'm looking for a solution to this problem: - IFAIK, I cannot edit the "active" XML myself other than by using provided Libvirt API (like attach-device), and such API doesn't exists for VLANs modification on OVS interface - I cannot use a migration hook to pass changes made to the inactive XML into the active one because the inactive XML is not reachable from the hook - I found a patch allowing to transport some information attached to an OVS port during migration[1]. Unfortunately, this patch doesn't transport the VLAN configuration - Modification of the active XML during the migration itself is not desirable because it will complicate the migration process by requesting an external tool Did I miss something to achieve VLAN configuration migration? How to implement that into the Libvirt properly? Thanks! Antoine [1] https://www.redhat.com/archives/libvir-list/2012-September/msg01092 .html
On 07/11/2017 10:47 AM, Antoine Millet wrote:
Hi list,
I'm using OVS as backend for guest networking on my hypervisors. VLAN configuration for each interface is specified into the guest XML definition.
When I need to change VLAN configuration of a running guest, I first edit the inactive XML to keep the changes for future boots, then I use ovs-vsctl to instruct the changes on the existing OVS Port.
The problem happen when the guest is migrated to another hypervisor. The "active" XML is used to instantiate the VM on the destination and this XML doesn't incorporate the changes made to the inactive one. All the changes made on source are lost on the running guest at destination.
I'm looking for a solution to this problem:
- IFAIK, I cannot edit the "active" XML myself other than by using provided Libvirt API (like attach-device), and such API doesn't exists for VLANs modification on OVS interface - I cannot use a migration hook to pass changes made to the inactive XML into the active one because the inactive XML is not reachable from the hook - I found a patch allowing to transport some information attached to an OVS port during migration[1]. Unfortunately, this patch doesn't transport the VLAN configuration - Modification of the active XML during the migration itself is not desirable because it will complicate the migration process by requesting an external tool
Did I miss something to achieve VLAN configuration migration? How to implement that into the Libvirt properly?
The cleanest way to make this work would be to enhance the function qemuDomainChangeNet() to know what to do when it detects that the vlan tag was changed with a device update ("virsh update-device") - this command can take effect immediately rather than waiting until the next time the domain is started, so the XML that is migrated would have the new vlan tag already in place (and also you wouldn't need to issue the ovs-vsctl command for it out of band any more!). Currently that function notices that the vlan tag has changed, but this just leads to an "UNSUPPORTED" error. If the network type is OVS, then it *should* work to just reconnect the bridge (libvirt sets the vlan tag as part of connecting to the ovs bridge). So how are your programming chops? :-)
On Tue, 2017-07-11 at 14:56 -0400, Laine Stump wrote:
The cleanest way to make this work would be to enhance the function qemuDomainChangeNet() to know what to do when it detects that the vlan tag was changed with a device update ("virsh update-device") - this command can take effect immediately rather than waiting until the next time the domain is started, so the XML that is migrated would have the new vlan tag already in place (and also you wouldn't need to issue the ovs-vsctl command for it out of band any more!).
Currently that function notices that the vlan tag has changed, but this just leads to an "UNSUPPORTED" error. If the network type is OVS, then it *should* work to just reconnect the bridge (libvirt sets the vlan tag as part of connecting to the ovs bridge).
So how are your programming chops? :-)
Hi Laine, Thank you for the answer! I finally achieved to implement what you suggested. :-) I'll post the patch on the developer ML in a few days. Antoine
On 07/13/2017 11:02 AM, Antoine Millet wrote:
On Tue, 2017-07-11 at 14:56 -0400, Laine Stump wrote:
The cleanest way to make this work would be to enhance the function qemuDomainChangeNet() to know what to do when it detects that the vlan tag was changed with a device update ("virsh update-device") - this command can take effect immediately rather than waiting until the next time the domain is started, so the XML that is migrated would have the new vlan tag already in place (and also you wouldn't need to issue the ovs-vsctl command for it out of band any more!).
Currently that function notices that the vlan tag has changed, but this just leads to an "UNSUPPORTED" error. If the network type is OVS, then it *should* work to just reconnect the bridge (libvirt sets the vlan tag as part of connecting to the ovs bridge).
So how are your programming chops? :-)
Hi Laine,
Thank you for the answer!
I finally achieved to implement what you suggested. :-) I'll post the patch on the developer ML in a few days.
Nice! Please Cc me so it doesn't get lost in all my mail folders.
participants (2)
-
Antoine Millet -
Laine Stump