Re: [libvirt] [PATCH] network: Defer online of macvtap during qemu migration
On 05/14/2014 08:19 AM, Wangrui (K) wrote:
> -----Original Message-----
> From: sendmail [mailto:justsendmailnothingelse@gmail.com] On Behalf Of
> Laine Stump
> Sent: Tuesday, May 13, 2014 10:11 PM
> To: Matthew Rosato; libvir-list(a)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(a)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".