[libvirt] [PATCH] network: Defer online of macvtap during qemu migration

[Laine Stump]

On 05/14/2014 08:19 AM, Wangrui (K) wrote:
>
>> -----Original Message-----
>> From: sendmail [mailto:justsendmailnothingelse at gmail.com] On Behalf Of
>> Laine Stump
>> Sent: Tuesday, May 13, 2014 10:11 PM
>> To: Matthew Rosato; libvir-list at redhat.com
>> Cc: Wangrui (K)
>> Subject: Re: [libvirt] [PATCH] network: Defer online of macvtap during qemu
>> migration
>>
>> On 05/13/2014 04:31 PM, Matthew Rosato wrote:
>>> On 05/05/2014 12:33 PM, Matthew Rosato wrote:
>>>> On 05/05/2014 12:26 PM, Matthew Rosato wrote:
>>>>> When generating macvtaps via
>> virNetDevMacVLanCreateWithVPortProfile,
>>>>> the macvtap device is unconditionally set to the up state.  However,
>>>>> during migration, this results in a case where both the source and
>>>>> target system are simultaneously up with the same MAC address.  This
>>>>> patch defers bringing the target macvtap up until later in the
>>>>> migration to shrink this window.
>>>>>
>>>>> Signed-off-by: Matthew Rosato <mjrosato at linux.vnet.ibm.com>
>>>> Forgot to mention that this patch is associated with what Wangrui
>>>> reported here:
>>>>
>>>> http://www.redhat.com/archives/libvir-list/2014-March/msg01054.html
>>>>
>>>> and follows Viktor's suggested solution mentioned here:
>>>>
>>>> http://www.redhat.com/archives/libvir-list/2014-March/msg01654.html
>>>>
>>>>
>>> Ping.
> Thanks for fix the issue that I reported.
> I think it can be considered that all types of netdevs are brought up until migration finish, not only macvtap.

Good idea! Although not necessary for any functional reason, that does
sound like a nice simplification of the code, similar to my idea
(mis-stated below) that this delay in bringing up the devices can be
done *any time* a guest is being brought up, not just when a guest is
being brought up as the destination of a migration. The fewer special
cases we have, 1) the fewer chances there will be for mistakes in logic,
and 2) the easier it will be to split the network device code out from
the hypervisor driver and make a separate public API for it so that an
unprivileged libvirt can take advantage of network device types that
require privileged libvirt.

>
>> Review coming up. Sorry for the delay. (I'm looking to see if the fix
>> can be simplified to bring up the macvtap interfaces *always*, rather
>> than just during migration.)
>>
>> BTW, there is an open BZ for this:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1081461
>>
>>
> I haven't seen the open BZ until Laine mentioned.
> Next time I will search the open BZs before report a new issue.

Actually, you originally reported the issue before David filed the BZ
:-) It was due to your earlier report on the mailing list that I
immediately recognized his problem when he asked about it on IRC, and
told him "that's been reported before; you should file a BZ to make sure
we take care of it".