Quoting Derek Simkowiak (<email address hidden>):
> This bug is probably a duplicate issue as this:
>
> https://bugs.launchpad.net/ubuntu/maverick/+source/qemu-kvm/+bug/584048
>
> The problem is with Linux bridging. When adding or removing a MAC
> address (like for KVM, VirtualBox, or even LXC) then if the bridge
> changes its MAC, this symptom happens. See comment #60 at the URL
> above, and also see this:
>
> https://www.redhat.com/archives/libvir-list/2010-July/msg00450.html
>
> The workaround is to use a MAC address that starts with "fe" (or any
> high really high number) for your guests. This causes the kernel to
> default to the hardware MAC for the bridge.
Derek, thanks so much for this. You're almost 100% correct. I had even
suspected that bug (in comment #7), but I failed to make the simple
connection explaining this behavior.
The proposed solution does *not* suffice, and in fact I just reproduced
the bug in natty!
The current solution counts on the bridge being associated with a physical
NIC. But our default configuration uses a NAT bridge which starts with
no physical devices attached. So it starts with a zero-ed out mac addr.
Then every time you start a VM with a lower MAC address than the first
VM's, you can see this pause. And if you shut down the VM with the
lowest MACADDR, you'll again see the pause.
Quoting Derek Simkowiak (<email address hidden>): /bugs.launchpad .net/ubuntu/ maverick/ +source/ qemu-kvm/ +bug/584048 /www.redhat. com/archives/ libvir- list/2010- July/msg00450. html
> This bug is probably a duplicate issue as this:
>
> https:/
>
> The problem is with Linux bridging. When adding or removing a MAC
> address (like for KVM, VirtualBox, or even LXC) then if the bridge
> changes its MAC, this symptom happens. See comment #60 at the URL
> above, and also see this:
>
> https:/
>
> The workaround is to use a MAC address that starts with "fe" (or any
> high really high number) for your guests. This causes the kernel to
> default to the hardware MAC for the bridge.
Derek, thanks so much for this. You're almost 100% correct. I had even
suspected that bug (in comment #7), but I failed to make the simple
connection explaining this behavior.
The proposed solution does *not* suffice, and in fact I just reproduced
the bug in natty!
The current solution counts on the bridge being associated with a physical
NIC. But our default configuration uses a NAT bridge which starts with
no physical devices attached. So it starts with a zero-ed out mac addr.
Then every time you start a VM with a lower MAC address than the first
VM's, you can see this pause. And if you shut down the VM with the
lowest MACADDR, you'll again see the pause.