Ed Swierk <eswierk(a)aristanetworks.com> wrote on 02/15/2010 11:15:11 PM:
On Mon, Feb 15, 2010 at 4:39 PM, Stefan Berger <stefanb(a)us.ibm.com>
wrote:
> This patch fixes the problem with the tear down of the macvtap
device
> when issuing a 'virsh destroy' by moving the tear down block past the
> point of killing the Qemu process. It seems necessary to loop at least
> once in the case of 'virsh destory' since the device seems to be busy
> for a while after the Qemu process has been killed. This also still
> properly tears down the macvtap device when the VM is 'virsh
shutdown'ed
> or halted from inside.
I think it's fine to check just once, before replacing an existing
macvtap interface with a new one, that the existing interface's fd can
be opened, to avoid stomping on an interface owned by someone else.
This is for the case when the device gets created. In that case I do
check for someone else 'accidentally' having the same MAC address.
On shutdown, I think it's safe to assume that an interface whose name,
macaddr and type matches is in fact the interface it created. I think
it should just go ahead and delete it without again trying to open the
fd. Otherwise we end up with such annoying races, e.g. if qemu hangs
or takes a long time to shut down, you end up leaving the orphaned
interfaces sitting around as well as the hung qemu process.
This would be for the case that the SIGKILL on the Qemu process didn't
actually
tear down the process. I was hoping that that would not happen. I guess
the
solution is to introduce another function like
'delMacvtapByAddressNoBusyCheck'
that skips the test that tries to open the tap device. Does this sound
right ?
Stefan
--Ed