c: 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
> -Original Message-
> From: sendmail [mailto:justsendmailnothinge...@gmail.com] On Behalf Of
> Laine Stump
> Sent: Tuesday, May 13, 2014 10:11 PM
> To: Matthew Rosato; libvir-list@redhat.com
> Cc: Wangrui (K)
> Subject: Re: [libvirt] [PATCH] network: Defer online o
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
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 so
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
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
