Re: [Xen-devel] Xen 4.2.1 live migration with qemu device model

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-12-11 at 11:45 +0000, Alex Bligh wrote:
> In this email message:
>  http://www.gossamer-threads.com/lists/xen/devel/256737
> a patch to libxl_domain_suspend is presented to enable live migrate
> with the qemu device model in xen-unstable. This patch has *NOT*
> been taken into the 4.2.1 tree (as far as I can see).
> 
> In 4.2.0, adding this patch and attempting a live migrate using
> the qemu device model (using xl) produces a seg fault due to
> unitialised variables.

Really using xl? because the stack trace suggests otherwise.

> Should I expect live-migrate of qemu-dm vms to work under 4.2.1?

Do you mean VMs using the upstream "qemu-xen" device model, as opposed
to the default "qemu-xen-traditional" model?

Migration of HVM guests in 4.2.x is only supported with the
qemu-xen-traditional device model and AFAIK there is no plan to backport
this support to 4.2.

It still shouldn't crash though. I'm not sure how it got this far since
libxl on 4.2 explicitly checks the DM version before attempting to
migrate and will refuse to even try with a qemu-xen DM.

Ian.

> If so, should the patch (or a modification thereof) to remove
> the check from libxl_domain_suspend be applied to 4.2.1-testing
> or is there more to do?
> 
> I am very happy to commit test resources to this.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffeffff700 (LWP 5995)]
> 0x00007ffff5a0862a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x00007ffff5a0862a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff6d4e970 in libxl__domain_suspend_common_switch_qemu_logdirty 
> (domid=<optimized out>, enable=<optimized out>, user=0x7ffff00024e8) at 
> libxl_dom.c:728
> #2  0x00007ffff6d5c1ae in libxl__srm_callout_received_save 
> (msg=0x7fffefffe41a " error", len=<optimized out>, user=0x7ffff00024e8) at 
> _libxl_save_msgs_callout.c:162
> #3  0x00007ffff6d5b736 in helper_stdout_readable (egc=0x7fffefffe5a0, 
> ev=0x7ffff0002560, fd=38, events=<optimized out>, revents=<optimized out>) at 
> libxl_save_callout.c:283
> #4  0x00007ffff6d601f1 in afterpoll_internal (egc=0x7fffefffe5a0, 
> poller=0x7ffff00028c0, nfds=4, fds=0x7ffff00048b0, now=...) at 
> libxl_event.c:948
> #5  0x00007ffff6d604db in eventloop_iteration (egc=0x7fffefffe5a0, 
> poller=0x7ffff00028c0) at libxl_event.c:1368
> #6  0x00007ffff6d616b3 in libxl__ao_inprogress (ao=0x7ffff0001d40, 
> file=<optimized out>, line=<optimized out>, func=<optimized out>) at 
> libxl_event.c:1614
> #7  0x00007ffff6d3ab75 in libxl_domain_suspend (ctx=<optimized out>, domid=1, 
> fd=10, flags=<optimized out>, ao_how=<optimized out>) at libxl.c:796
> #8  0x000000000043677e in migrate_domain_send (ctx=0x7ffff0008860, domid=1, 
> fd=10) at hypervisor/xen_libxl.c:587
> #9  0x000000000043698a in live_migrate_send (hyperconn=0x7ffff0001c70, 
> server=0x7ffff0001cb0, node_ip=0x7ffff00041e0 "10.157.128.20", fd=10) at 
> hypervisor/xen_libxl.c:647
> #10 0x0000000000422a70 in migrate_server_action (request=0x7ffff0002980) at 
> action/node_action.c:1287
> #11 0x00000000004240c1 in runAction (socket_fd=8) at action/handleaction.c:138
> #12 0x00000000004179bd in runcomm (socket=0x8) at xvpagent.c:253
> #13 0x0000000000427502 in trackedthread_run (arg=0x66df20) at util/util.c:179
> #14 0x00007ffff5c9ce9a in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #15 0x00007ffff59ca4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
> #16 0x0000000000000000 in ?? ()
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel