libvirt users - Jul 2017 - Re: 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