Re: VM Migration with IEEE802.1Qbh and IEEE802.1Qbg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]