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

Re: [Xen-users] GPL PV drivers for Windows 0.9.11-pre12



Good news! I've reinstalled windows 2003 ent. 32bit, .net2 and gplpv
0.9.11-pre13 and live migration is working. I've migrated 20 times
without issue. Save/restore is also working. 'xm shutdown domU' still
results in a "system recovered from unexpected shutdown" on the next
power up even though it appears to be shutting down properly.

I'm confused about the errors I was seeing last night. The only
difference is that I had installed an earlier version of GPLPV
(~0.9.9) then upgraded each time a new release came out. Live
migrations often succeeded in earlier 0.9.11-pre releases so I didn't
think there was a problem with upgrading but now I'm not so sure.

Keith

On Wed, Aug 27, 2008 at 2:41 AM, keith coleman <keith@xxxxxxxxxxx> wrote:
> On Wed, Aug 27, 2008 at 12:24 AM, James Harper
> <james.harper@xxxxxxxxxxxxxxxx> wrote:
>>> On Thu, Aug 21, 2008 at 8:59 PM, James Harper
>>> <james.harper@xxxxxxxxxxxxxxxx> wrote:
>>> >>
>>> >> Win2003 32bit live migrations don't work for me. They were mostly
>>> >> working with 0.9.11-pre9 but the xm migrate command hangs with
>>> >> 0.9.11-pre12. The domU is paused on the destination machine and the
>>> >> migrating-domU is still running on the source machine.
>>> >>
>>> >> Live migrations succeed when I revert to non-GPLPV mode so I don't
>>> >> think my setup is the problem.
>>> >>
>>> >
>>> > Yes, I probably broke it when I fixed the bugs in the network code.
>> I'll
>>> > look at it next.
>>> >
>>>
>>> Same behavior in 0.9.11-pre13.
>>
>> Hmmm... as I don't have the hardware to test live migrations the best I
>> can do to approximate it is to do a save then a restore, which I have
>> tested pretty thoroughly on a 4 way SMP system.
>
> I just tried a regular save and was not successful. The domU changes
> to migrating-domU but continues to run. The save file only grows to
> 1473 bytes. Here's the output of xend.log:
> [2008-08-27 05:59:26 19958] INFO (XendDomain:1165) Domain winserver
> (24) unpaused.
> [2008-08-27 06:01:17 19958] DEBUG (XendCheckpoint:89) [xc_save]:
> /usr/lib64/xen/bin/xc_save 5 24 0 0 4
> [2008-08-27 06:01:17 19958] DEBUG (XendCheckpoint:336) suspend
> [2008-08-27 06:01:17 19958] DEBUG (XendCheckpoint:92) In
> saveInputHandler suspend
> [2008-08-27 06:01:17 19958] DEBUG (XendCheckpoint:94) Suspending 24 ...
> [2008-08-27 06:01:17 19958] DEBUG (XendDomainInfo:467)
> XendDomainInfo.shutdown(suspend)
> [2008-08-27 06:01:17 19958] DEBUG (XendDomainInfo:1111)
> XendDomainInfo.handleShutdownWatch
>
>>
>> When you say 'live migration', is this with 'xm migrate -l'? Did you try
>> it without the -l? the non-live migration is probably closer to the
>> save+restore that I've been testing.
>
> Yes, I've been trying "--live" migration. Here's the output of xend.log:
> [2008-08-27 06:33:16 19958] DEBUG (DevController:150) Waiting for devices 
> vtpm.
> [2008-08-27 06:33:16 19958] INFO (XendDomain:1165) Domain winserver
> (30) unpaused.
> [2008-08-27 06:34:13 19958] DEBUG (XendCheckpoint:89) [xc_save]:
> /usr/lib64/xen/bin/xc_save 5 30 0 0 5
> [2008-08-27 06:34:24 19958] INFO (XendCheckpoint:365) Saving memory
> pages: iter 1  95%^M 1: sent 982159, skipped 849, delta 10959ms, dom0
> 84%, target 83%, sent 2936Mb/s, dirtied 3Mb/s 1041 pages
> [2008-08-27 06:34:24 19958] INFO (XendCheckpoint:365) Saving memory
> pages: iter 2   0%^M 2: sent 1006, skipped 35, delta 78ms, dom0 93%,
> target 51%, sent 422Mb/s, dirtied 52Mb/s 124 pages
> [2008-08-27 06:34:24 19958] INFO (XendCheckpoint:365) Saving memory
> pages: iter 3   0%^M 3: sent 112, skipped 11, delta 32ms, dom0 31%,
> target 71%, sent 114Mb/s, dirtied 17Mb/s 17 pages
> [2008-08-27 06:34:25 19958] INFO (XendCheckpoint:365) Saving memory
> pages: iter 4   0%^M 4: sent 15, skipped 2, Start last iteration
> [2008-08-27 06:34:25 19958] DEBUG (XendCheckpoint:336) suspend
> [2008-08-27 06:34:25 19958] DEBUG (XendCheckpoint:92) In
> saveInputHandler suspend
> [2008-08-27 06:34:25 19958] DEBUG (XendCheckpoint:94) Suspending 30 ...
> [2008-08-27 06:34:25 19958] DEBUG (XendDomainInfo:467)
> XendDomainInfo.shutdown(suspend)
> [2008-08-27 06:34:25 19958] DEBUG (XendDomainInfo:1111)
> XendDomainInfo.handleShutdownWatch
>
>
> Non-live migration also failed. The domU continues to run and xend.log shows:
> [2008-08-27 06:20:56 19958] DEBUG (DevController:150) Waiting for devices 
> vtpm.
> [2008-08-27 06:22:12 19958] DEBUG (XendCheckpoint:89) [xc_save]:
> /usr/lib64/xen/bin/xc_save 5 27 0 0 4
> [2008-08-27 06:22:12 19958] DEBUG (XendCheckpoint:336) suspend
> [2008-08-27 06:22:12 19958] DEBUG (XendCheckpoint:92) In
> saveInputHandler suspend
> [2008-08-27 06:22:12 19958] DEBUG (XendCheckpoint:94) Suspending 27 ...
> [2008-08-27 06:22:12 19958] DEBUG (XendDomainInfo:467)
> XendDomainInfo.shutdown(suspend)
> [2008-08-27 06:22:12 19958] DEBUG (XendDomainInfo:1111)
> XendDomainInfo.handleShutdownWatch
>
>
> When I reboot the domU into non-gplpv mode things work properly.
>
>>
>> If you can run the debugger on the source machine you might be able to
>> spot something, but there is some hang detection code in there that
>> fails when running under the debugger - for some reason when the
>> debugger is attached and code is executing at HIGH_LEVEL, it slows to a
>> crawl. If you are willing to test it I could send you a version of
>> xenpci.sys with that code removed.
>
> Sure.
>
>>
>> James
>>
>

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

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