xen-devel
Re: [Xen-devel] Live vm migration broken in latest xen-unstable
Hi Folks, I am facing another problem. after the vm migration, the frontend of guest VM doesn't properly attaches with the new backend. I observed that after VM migration, the disk requests sent by blkfront driver are not seen by the blkif_schedule process in the blkback driver. Do you think it is a known problem? has anybody else observed this?
Thanks, Sanjay
On 9/8/06, sanjay kushwaha <sanjay.kushwaha@xxxxxxxxx> wrote:
Hi Tim, Yes. This patch solved my problem. now live VM migration happens but I am experiencing another problem. when I reattach to the migrated VM console on the destination machine, I see the following traceback in
the dmesg of the guest VM.
------------[ cut here ]------------ kernel BUG at drivers/xen/netfront/netfront.c:717! invalid opcode: 0000 [#1] SMP Modules linked in: CPU: 0 EIP: 0061:[<c02598e0>] Not tainted VLI
EFLAGS: 00010082 (2.6.16.13-xenU #15) EIP is at network_alloc_rx_buffers+0x470/0x4b0 eax: c056fc80 ebx: ccbc0d80 ecx: d1001040 edx: c05d0000 esi: c05d02a0 edi: c05d034c ebp: c0551f14 esp: c0551eac
ds: 007b es: 007b ss: 0069 Process xenwatch (pid: 8, threadinfo=c0550000 task=c057a540) Stack: <0>00000208 00000000 0000cbc1 00000000 c05d034c c05d31b8 c05d0000 00000000 00000337 00000337 0000002f 00000208 ccbc1000 000000d1 cdd25838 00000100
000000d1 00000011 c05d0000 00000001 c02f8013 c05d0000 00000001 c05d02a0 Call Trace: [<c01058ed>] show_stack_log_lvl+0xcd/0x120 [<c0105aeb>] show_registers+0x1ab/0x240 [<c0105e11>] die+0x111/0x240
[<c0106178>] do_trap+0x98/0xe0 [<c0106491>] do_invalid_op+0xa1/0xb0 [<c01052c7>] error_code+0x2b/0x30 [<c025a554>] backend_changed+0x1a4/0x250 [<c025517e>] otherend_changed+0x7e/0x90
[<c0253361>] xenwatch_handle_callback+0x21/0x60 [<c025345d>] xenwatch_thread+0xbd/0x160 [<c0132b0c>] kthread+0xec/0xf0 [<c0102c45>] kernel_thread_helper+0x5/0x10 Code: 82 04 15 00 00 8d 9e f8 14 00 00 e8 db 78 ea ff 8b 5d d8 39 9a
fc 14 00 00 0f 84 16 fe ff ff e9 51 ff ff ff 8d b4 26 00 00 00 00 <0f> 0b cd 02 2c a0 2f c0 e9 cd fc ff ff 0f 0b d1 02 2c a0 2f c0
[root@localhost ~]#
Does anyone know if this is a known problem?
Thanks for your help. Sanjay
On 9/7/06, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx> wrote: > Hi Sanjay, > > Does the attached patch fix this problem for you? It tries to make sure
> there is enough spare memory to enable shadow pagetables on the domain > before starting the migration. > > Cheers, > > Tim > > At 15:09 -0400 on 05 Sep (1157468999), sanjay kushwaha wrote:
> > Hi Ewan, > > I did a "hg pull -u" on my tree which also got the changeset 11422. but I am > > still facing the same problem. btw this changeset seems to be specific to > > hvm domain while I am facing this problem with paravirtualized domain.
> > > > Thanks, > > Sanjay > > > > On 9/5/06, Ewan Mellor <ewan@xxxxxxxxxxxxx> wrote: > > > > > >On Fri, Sep 01, 2006 at 05:36:00PM -0400, sanjay kushwaha wrote:
> > > > > >> Folks, > > >> I am experiencing that live migration is not working in latest > > >> xen-unstable. I get the following message during migration > > >>
> > >> [root@pc5 ksanjay]# xm migrate --live 1 [1]199.77.138.23 > > >> Error: /usr/lib/xen/bin/xc_save 18 1 0 0 1 failed > > >> [root@pc5 ksanjay]# > > >> > > >> I traced the problem to a function in xen named set_sh_allocation() in
> > >> file xen/arch/x86/mm/shadow/common.c > > >> > > >> tools/libxc/xc_linux_save.c:xc_linux_save() is called from the python > > >> script which makes the following hypercall
> > >> > > >> if (live) { > > >> if (xc_shadow_control(xc_handle, dom, > > >> XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY,
> > >> NULL, 0, NULL, 0, NULL) < 0) { > > >> ERR("Couldn't enable shadow mode"); > > >> goto out; > > >> }
> > >> last_iter = 0; > > >> } else { > > >> ----------- > > >> > > >> this particular hypercall leads to the call of set_sh_allocation which
> > >> fails in the following code > > >> > > >> if ( d-> arch.shadow.total_pages < pages ) > > >> { > > >> /* Need to allocate more memory from domheap */
> > >> pg = alloc_domheap_pages(NULL, SHADOW_MAX_ORDER, 0); > > >> if ( pg == NULL ) > > >> { > > >> SHADOW_PRINTK("failed to allocate shadow pages.\n");
> > >> return -ENOMEM; > > >> } > > >> > > >> alloc_domheap_pages fails and returns NULL. however I think I have > > >enough
> > >> memory available so this function should not fail. > > >> > > >> Is there anybody else experiencing the same problem? Could someone > > >please > > >> tell me how to fix it?
> > > > > >I've put some changes into xen-unstable today which might help. The last > > >fix > > >is on its way through testing now. Look out for xen-unstable changeset
> > >11422, and try that, see how you get on. > > > > > >Cheers, > > > > > >Ewan. > > > > > > > > > > > -- > > ----------------------
> > PhD Student, Georgia Tech > > http://www.cc.gatech.edu/~ksanjay/ <http://www.cc.gatech.edu/%7Eksanjay/
> > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@xxxxxxxxxxxxxxxxxxx > >
http://lists.xensource.com/xen-devel > > > >
-- ---------------------- PhD Student, Georgia Tech
http://www.cc.gatech.edu/~ksanjay/
-- ---------------------- PhD Student, Georgia Tech http://www.cc.gatech.edu/~ksanjay/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|