Re: [Xen-devel] Live vm migration broken in latest xen-unstable

["sanjay kushwaha" <sanjay.kushwaha@xxxxxxxxx>]

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