＞This fix won't work correctly either. You cannot assume that libvirt has
＞control over when the QEMU process exits. It may exit itself *before*
＞libvirt runs any of its cleanup code.
I don't think there's a problem. Although libvirt does not runs cleanup code .but tap devices don't exist when when the QEMU process exits.
libvirt can create tap device and add port to the bridge again by calling virNetDevOpenvswitchAddPort .
i can only delete the port from openvswitch bridge and cleanup other network interfaces after the QEMU process exits.
为了让您的VPlat虚拟化故障得到高效的处理，请上报故障到: $VPlat技术支持。
芦志朋 luzhipeng
IT开发工程师 IT Development
Engineer
操作系统产品部/中心研究院/系统产品 OS Product Dept./Central R＆D Institute/System Product
 |  深圳市南山区科技南路55号中兴通讯研发大楼33楼 33/F, R&D Building, ZTE Corporation Hi-tech Road South, Hi-tech Industrial Park Nanshan District, Shenzhen, P.R.China, 518057 T: +86 755 xxxxxxxx F:+86 755 xxxxxxxx M: +86 xxxxxxxxxxx E: lu.zhipeng@xxxxxxxxxx www.zte.com.cn |
原始邮件
发件人： ＜berrange@xxxxxxxxxx＞;
收件人：芦志朋10108272;
抄送人： ＜libvir-list@xxxxxxxxxx＞; ＜laine@xxxxxxxxx＞;
日 期 ：2017年05月08日 16:39
主 题 ：Re: [libvirt] [PATCH v2] qemu: clean up network interfaces beforeqemuProcessKill is called in qemuProcessStop
On Mon, May 08, 2017 at 03:03:30PM +0800, ZhiPeng Lu wrote:
＞ In qemuProcessStop we explicitly remove the port from the openvswitch bridge after
＞ qemuProcessKill is called. But there is a certain interval of time between
＞ deleting tap device and removing it from bridge. The problem occurs when two vms
＞ start and shutdown with the same name's network interface attached to the same
＞ openvswitch bridge. When one vm with the nic named "vnet0" stopping, it deleted
＞ tap device without timely removing the port from bridge.
＞ At this time, another vm created the tap device named "vnet0" and added port to the
＞ same bridge. Then, the first vm removed the port from the same bridge.
＞ Finally, the tap device of the second vm did not attached to the bridge.
＞ We need to delete the bridge port before deleting the tap device instead of after.
＞ So what's needed is to move the loop in qemuProcessStop that cleans up
＞ network interfaces so that it happens before qemuProcessKill is called.
This fix won't work correctly either. You cannot assume that libvirt has
control over when the QEMU process exits. It may exit itself *before*
libvirt runs any of its cleanup code.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
＞ In qemuProcessStop we explicitly remove the port from the openvswitch bridge after
＞ qemuProcessKill is called. But there is a certain interval of time between
＞ deleting tap device and removing it from bridge. The problem occurs when two vms
＞ start and shutdown with the same name's network interface attached to the same
＞ openvswitch bridge. When one vm with the nic named "vnet0" stopping, it deleted
＞ tap device without timely removing the port from bridge.
＞ At this time, another vm created the tap device named "vnet0" and added port to the
＞ same bridge. Then, the first vm removed the port from the same bridge.
＞ Finally, the tap device of the second vm did not attached to the bridge.
＞ We need to delete the bridge port before deleting the tap device instead of after.
＞ So what's needed is to move the loop in qemuProcessStop that cleans up
＞ network interfaces so that it happens before qemuProcessKill is called.
This fix won't work correctly either. You cannot assume that libvirt has
control over when the QEMU process exits. It may exit itself *before*
libvirt runs any of its cleanup code.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
