date:20170503

Re: [libvirt] [PATCH 2/2] mdev: Fix daemon crash on domain shutdown after reconnect

2017-05-03 Thread Erik Skultety

On Wed, May 03, 2017 at 11:25:30AM -0400, Laine Stump wrote:
> On 04/28/2017 03:46 AM, Erik Skultety wrote:
> > The problem resides in virHostdevUpdateActiveMediatedDevices which gets
> > called during qemuProcessReconnect. The issue here is that
> > virMediatedDeviceListAdd takes a pointer to the item to be added to the
> > list to which VIR_APPEND_ELEMENT is used, which also clears the pointer.
> > However, in this case only the local copy of the pointer got cleared,
> > leaving the original pointing to valid memory. To sum it up, during
> > cleanup phase, the original pointer is freed and the daemon crashes
> > basically any time it would access it.
> >
> > Backtrace:
> > 0x73ccdeba in __strcmp_sse2_unaligned
> > 0x772a444a in virMediatedDeviceListFindIndex
> > 0x77241446 in virHostdevReAttachMediatedDevices
> > 0x7fffc60215d9 in qemuHostdevReAttachMediatedDevices
> > 0x7fffc60216dc in qemuHostdevReAttachDomainDevices
> > 0x7fffc6046e6f in qemuProcessStop
> > 0x7fffc6091596 in processMonitorEOFEvent
> > 0x7fffc6091793 in qemuProcessEventHandler
> > 0x77294bf5 in virThreadPoolWorker
> > 0x77294184 in virThreadHelper
> > 0x73fdc3c4 in start_thread () from /lib64/libpthread.so.0
> > 0x73d269cf in clone () from /lib64/libc.so.6
> >
> > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446455
> >
> > Signed-off-by: Erik Skultety 
>
> Reviewed-by: Laine Stump 
>
> or ACK, or whatever is the new accepted hotness.

Thanks, I pushed them both to master and v3.2-maint.
Erik

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] 答复: Re: 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

2017-05-03 Thread Laine Stump

(Please don't top-post replies. ALso, I added libvir-list back to the To:)

On 05/03/2017 08:46 PM, lu.zhip...@zte.com.cn wrote:
> 
> Some other scenarios such as migration. 
> 
> Can we guarantee that the network card driver has been
> closed before  killing QEMU ?

During a migration, before we ever get to the point of killing the
source qemu process, we have already stopped the guest CPUs and made
sure that the entire state of the guest has been transferred to the qemu
process on the destination host. It doesn't matter if we detach the tap
device from the bridge or not - any traffic received on the source host
during that time (after stopping the guest CPUs) will be dropped (and
re-transmitted + received by the guest after it starts running on the
destination).

Since the guest CPU is already stopped on the source, and the guest on
the destination already has the full state of the guest ready to start
up (and will not receive any new updates), keeping the tap device
connected to the bridge for a small fraction of a second is not going to
make any difference at all.

Is that convincing enough? :-)

> 
> if we are sure,that's ok
> 
> 
> 
> 
> 
> *为了让您的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  F:+86 755 
> M: +86 xxx
> E: lu.zhip...@zte.com.cn
> www.zte.com.cn 
> 
> 原始邮件
> *发件人：*＜la...@laine.org＞;
> *收件人：*芦志朋10108272;
> *日 期 ：*2017年05月04日 08:31
> *主 题 ：**Re: 答复: Re: [libvirt] [PATCH] qemu: change the name of tap
> device for a tapand bridge network*
> 
> 
> 
> 
> On May 3, 2017 8:28 PM,  ＜lu.zhip...@zte.com.cn
> ＞ wrote:
> 
> 
> I'm worried that the network packet loss rate will increase after
>  reversing the order.
> 
> 
> Why? The guest is already shut down (or being shut down). By this time
> there is no traffic that would make any difference. And anyway, we've
> already determined that the current order causes a race so it is wrong.
> 
> 
> 
> 
> 
> *为了让您的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  F:+86 755 
> M: +86 xxx
> E: lu.zhip...@zte.com.cn 
> www.zte.com.cn 
> 
> 原始邮件
> *发件人：*＜berra...@redhat.com ＞;
> *收件人：*＜la...@laine.org ＞;
> *抄送人：*＜libvir-list@redhat.com  l...@redhat.com>＞;芦志朋10108272;
> *日 期 ：*2017年05月02日 16:30
> *主 题 ：**Re: [libvirt] [PATCH] qemu: change the name of tap device
> for a tapand bridge network*
> 
> 
> On Fri, Apr 28, 2017 at 01:08:45PM -0400, Laine Stump wrote:
> ＞ On 04/28/2017 05:33 AM, Daniel P. Berrange wrote:
> ＞ ＞ On Fri, Apr 28, 2017 at 05:23:19PM +0800, ZhiPeng Lu wrote:
> ＞ ＞＞ Creating tap device and adding the device to bridge are not atomic 
> operation.
> ＞ ＞＞ Similarly deleting tap device and removing it from bridge are not 
> atomic operation.
> ＞ ＞＞ The Problem occurs when two vms start and shutdown. When one vm with 
> the nic
> ＞ ＞＞ named "vnet0" stopping, it deleted tap device but not removing 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 deleted the tap device from the same 
> bridge.
> ＞ ＞＞ Finally, the tap device of the second vm don't attached to the 
> bridge.
> ＞ ＞＞ So, we can add domid to vm's nic name. For example, the vm's domid 
> is 1 and vnet0
> ＞ ＞＞ is renamed to vnet1.0.
> ＞ ＞ 
> ＞ ＞ Surely deleting the NIC automatically removes it from the bridge so we
> ＞ ＞ can just remove the code that delets the bridge port.
> ＞ 
> ＞ That is true when using a Linux host bridge, but I recall that for
> ＞ openvswitch (which I think is what ZhiPeng is using, based on an earlier
> ＞ patch), you must explicitly remove the port from the bridge - apparently
> ＞ the port is still there in openvswitch's table as some sort of "zombie"
> ＞ connection even after the tap device itself no longer exists.
> ＞ 
> ＞ 
> ＞ But instead of changing the naming scheme, maybe we should just delete
> ＞ the bridge port *before* deleting the tap device instead of after. (Am I
> ＞ recalling correctly that the tap device is deleted autom

[libvirt] 答复: Re: [PATCH] qemu: change the name of tap device for a tapand bridge network

2017-05-03 Thread lu.zhipeng

I'm worried that the network packet loss rate will increase after reversing
the order.

为了让您的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 F:+86 755
M: +86 xxx
E: lu.zhip...@zte.com.cn
www.zte.com.cn

原始邮件

发件人： ＜berra...@redhat.com＞
收件人： ＜la...@laine.org＞
抄送人： ＜libvir-list@redhat.com＞芦志朋10108272
日 期 ：2017年05月02日 16:30
主 题 ：Re: [libvirt] [PATCH] qemu: change the name of tap device for a tapand
bridge network

On Fri, Apr 28, 2017 at 01:08:45PM -0400, Laine Stump wrote:
＞ On 04/28/2017 05:33 AM, Daniel P. Berrange wrote:
＞ ＞ On Fri, Apr 28, 2017 at 05:23:19PM +0800, ZhiPeng Lu wrote:
＞ ＞＞ Creating tap device and adding the device to bridge are not atomic
operation.
＞ ＞＞ Similarly deleting tap device and removing it from bridge are not atomic
operation.
＞ ＞＞ The Problem occurs when two vms start and shutdown. When one vm with the
nic
＞ ＞＞ named "vnet0" stopping, it deleted tap device but not removing 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 deleted the tap device from the same
bridge.
＞ ＞＞ Finally, the tap device of the second vm don't attached to the bridge.
＞ ＞＞ So, we can add domid to vm's nic name. For example, the vm's domid is 1
and vnet0
＞ ＞＞ is renamed to vnet1.0.
＞ ＞
＞ ＞ Surely deleting the NIC automatically removes it from the bridge so we
＞ ＞ can just remove the code that delets the bridge port.
＞
＞ That is true when using a Linux host bridge, but I recall that for
＞ openvswitch (which I think is what ZhiPeng is using, based on an earlier
＞ patch), you must explicitly remove the port from the bridge - apparently
＞ the port is still there in openvswitch's table as some sort of "zombie"
＞ connection even after the tap device itself no longer exists.
＞
＞
＞ But instead of changing the naming scheme, maybe we should just delete
＞ the bridge port *before* deleting the tap device instead of after. (Am I
＞ recalling correctly that the tap device is deleted automatically when
＞ the qemu process is killed? If so, then what's needed is to move the
＞ loop in qemuProcessStop() that cleans up network interfaces so that it
＞ happens before qemuProcessKill() is called.

Agreed, we should just reverse the order.

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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

40 matches

Mail list logo