Ed Swierk <eswierk@aristanetworks.com> wrote on 02/15/2010 11:15:11 PM:
On Mon, Feb 15, 2010 at 4:39 PM, Stefan Berger <stefanb@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