10:47 p.m.
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
2:56 a.m.
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? :-)
11:02 p.m.
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
12:16 a.m.
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.
2653
days inactive
2655
days old
3 comments
2 participants
participants (2)
-
Antoine Millet -
Laine Stump