[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: Win2003R2 64 suspend failed in self live migration



Thanks, James.
 
I was able to log out by KeRaiseIrql(HIGH_LEVEL, &old_irql) to raise irq to HIGH_LEVEL.
And later, I also found that the cause of failure of self live migration. Nothing to do with PV driver.
 
That is in my env I specified vifname for Guest, so after self migration there will be vifname
conflict, and the new vif will failed to be renamed, and thus failed to be add into bridge.
Which results in net lost inside Guest and finally furthur migration failed since vif can not suspend
anymore.
 
Thanks for your help.
 
> Subject: RE: Win2003R2 64 suspend failed in self live migration
> Date: Thu, 16 Jun 2011 09:20:04 +1000
> From: james.harper@xxxxxxxxxxxxxxxx
> To: tinnycloud@xxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
>
> > Hi James;
> >
> > I've been testing Windows HVM live migration for a while, OS type
> covers
> > 2003, and 2008.
> > It works well most of time. I mean migration been two physical
> host.
> > But 2003R2 64 bit failed on self live migration. (VM migration on
> the
> > same host)
> >
> > After instal debug version PV driver inside VM, not debug log
> show up.
> > Later I learnt that, in your code you implied that the debug
> routine
> > could not be hooked since
> > "// can't patch IDT on AMD64 "(in xenpci_dbprint.c
> XenPci_HookDbgPrint())
> >
>
> Windows 2003 doesn't have an API for getting debug messages so I hook
> the IDT, but under x64 PatchGuard monitors the IDT and causes a BSoD if
> it detects a change. A program from SysInternals called DebugView can do
> it so it must be possible but I've never figured out how.
>
> > I was able to get the log output simply by redefine the KdPrint
> macro
> > like below. But unfortunately
> > , VM is suffuring hang now and then.
> >
>
> As per my previous email, if you run out of stack space at a high IRQL
> then windows can hang very hard - even the debugger won't work. I think
> allocating 4KB of data on the stack (your char buf[4096]) might cause it
> to run out.
>
> You can allocate a global variable as long as you protect it with a
> lock, as long as you know what you are doing with locks and IRQLs.
> Alternatively you can allocate one buffer per CPU.
>
> James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.