On 09/04/2012 04:29 AM, Martin Kletzander wrote:

On 09/02/2012 01:53 PM, Jagath Weerasinghe wrote:

...

Hi All,

Can a VM connected as IEEE802.1Qbh be migrated to a destination host as it were connected as IEEE802.1Qbg? What I wanted to know is, is it possible to change the configuration from IEEE802.1Qbh to IEEE802.1Qbg on the fly?

IIUC, you want to migrate the guest from host A, where it has a network interface connected to 802.1Qbh switch, to host B, where it should be connected to 802.1Qbg switch, right?

I see three possibilities to do that, but unfortunately I cannot say if these will work.

If the guest has <interface type='network'> and that network has <virtualport type='802.1Qbh'> on host A and <virtualport type='802.1Qbg'> on host B, that might be working as-is.

Yes, that's the intent of allowing <virtualport> settings in <network> objects - it divorces the guest config from the specifics of the network it's connecting to (which is really an attribute of the *host* that the guest happens to be running on, so could change). Basically, the guest names a network it wants to use, and a network of that name should be available on both hosts, with <virtualport> setup appropriately. If this doesn't work, it's a bug. In that case (and also if it does work!) please report back here. As rare as it is to have either 802.1Qbg or 802.1Qbh hardware available for testing, it is even more rare to have both available at the same time, so the results of your testing would be very valuable!

If the guest has <virtualport type='802.1Qbh'> specified in its <interface>, you should be able to change the type using migrate hook [1] on host B.

Yes, but more complicated to setup, which implies more fragile. Definitely prefer the first method Martin suggested.

There should be one more option in case the <virtualport> is specified in the guest's <interface>. According to the docs [2], when no "type=" is specified for the <virtualport> element, this should be auto-completed on the domain startup, but that's most probably not applicable for your situation (migration).

That is only the case for 1) very new libvirt (0.10.0+) and 2) <interface type='network'>. It's purpose is to allow specifying, for example, both an openvswitch interfaceid and an 802.11Qbh profileid at the same time (for cases when the guest doesn't know whether the network it connects to will be openvswitch or 802.1Qbh, and wants to specify the appropriate setting for both possibilities).