[libvirt] [PATCH] Fix macvtap device tear down problem on virsh destroy

[Stefan Berger]

Ed Swierk <eswierk at aristanetworks.com> wrote on 02/15/2010 11:15:11 PM:


> 
> On Mon, Feb 15, 2010 at 4:39 PM, Stefan Berger <stefanb at 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.
> 
> 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.
> 

As an RFC, now attached the patch that tears down the macvtap device upon
termination of the Qemu process without checking whether the device(s)
with the given MAC address are in use.

Signed-off-by: Stefan Berger <stefanb at us.ibm.com>



> --Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100216/de3f09b4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macvtap_virsh_destroy.diff
Type: application/octet-stream
Size: 6171 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100216/de3f09b4/attachment-0001.obj>