<tt>Ed Swierk <eswierk@aristanetworks.com> wrote on 02/15/2010 11:15:11 PM:</tt> <tt>> > 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.</tt> <tt>This is for the case when the device gets created. In that case I do </tt> <tt>check for someone else 'accidentally' having the same MAC address.</tt> <tt> > > 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.</tt> <tt>This would be for the case that the SIGKILL on the Qemu process didn't actually</tt> <tt>tear down the process. I was hoping that that would not happen. I guess the </tt> <tt>solution is to introduce another function like 'delMacvtapByAddressNoBusyCheck'</tt> <tt>that skips the test that tries to open the tap device. Does this sound</tt> <tt>right ?</tt> <tt> Stefan</tt> <tt> > > --Ed </tt>