WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 		  
Home Products Support Community News
 
   
 

xen-devel

[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate

from [Shriram Rajagopalan] [Permanent Link][Original]
To: AP Xen <apxeng@xxxxxxxxx>
Subject: Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate
From: Shriram Rajagopalan <rshriram@xxxxxxxxx>
Date: Thu, 5 May 2011 09:42:26 -0500
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Thu, 05 May 2011 07:44:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTi=RznjiFROmOycnF3J4W+TLiGtF8Q@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BANLkTik_26kVgBwQbzKyN0AL8aLdE4dqHg@xxxxxxxxxxxxxx> <1304427718.18845.103.camel@xxxxxxxxxxxxxxxxxxxxxx> <BANLkTinCG1NzsSc3dPoS38+ByXv1nwHEaw@xxxxxxxxxxxxxx> <BANLkTi=RznjiFROmOycnF3J4W+TLiGtF8Q@xxxxxxxxxxxxxx>
Reply-to: rshriram@xxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, May 3, 2011 at 2:17 PM, AP Xen <apxeng@xxxxxxxxx> wrote:
On Tue, May 3, 2011 at 7:09 AM, Shriram Rajagopalan <rshriram@xxxxxxxxx> wrote:
> On Tue, May 3, 2011 at 6:01 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> wrote:
>>
>> On Fri, 2011-04-29 at 20:28 +0100, AP Xen wrote:
>> > I am trying to do an "xl save -c" on a Windows 7 Ultimate domain that
>> > will leave the domain running at the end of the save operation.
>>
>> Do you have pv drivers installed which support checkpoint suspends? I'm
>> not sure if such a thing even exists for Windows.
>>
>> I'm also not entirely sure that checkpointing was ever supported for HVM
>> domains without PV drivers (e.g. via emulated hibernation). Perhaps the
>> Remus guys know?
>>
> Remus works with HVM domains via normal xenstore based suspend/resume.
> Only PV-HVM support is "disabled" for the moment.
>>
>> [...]
>> > At the end of this the domain is frozen. Is this a known issue? Any
>> > pointers as to how to debug this? Where does xl pipe its debug
>> > messages to?
>>
>> /var/log/xen/xl-<domname>.log. You can also do "xl -vvv <command>" to
>> get some additional debug output.
>>
> Yes. the logs would be great. Also, by frozen, do you mean the domain
> remains
> in "suspended" state? or is Windows hung?

Not sure what the difference between Windows being suspended and hung
is. Here is the xl list output:
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  2914     4     r-----    1259.0
win7                                        15  1019     2     ---ss-       0.3

Here is the log:
Saving to win7chk new xl format (info 0x0/0x0/255)
libxl: debug: libxl_dom.c:378:libxl__domain_suspend_common_callback
Calling xc_domain_shutdown on HVM domain
libxl: debug: libxl_dom.c:438:libxl__domain_suspend_common_callback
wait for the guest to suspend
libxl: debug: libxl_dom.c:450:libxl__domain_suspend_common_callback
guest has suspended
xc: debug: outbuf_write: 4194304 > 90092@16687124
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: debug: outbuf_write: 4194304 > 4169716@12607500
xc: detail: delta 9991ms, dom0 27%, target 0%, sent 863Mb/s, dirtied
0Mb/s 0 pages
xc: detail: Total pages sent= 263168 (0.25x)
xc: detail: (of which 0 were fixups)
xc: detail: All memory is saved
xc: detail: Save exit rc=0
libxl: debug: libxl_dom.c:534:libxl__domain_save_device_model Saving
device model state to /var/lib/xen/qemu-save.15
libxl: debug: libxl_dom.c:546:libxl__domain_save_device_model Qemu
state is 7204 bytes


Ok. I see a "HVM shutdown". But where is the resume?
Going through the libxl code, one obvious difference I see between xl's implementation of save
and the old xm implementation is, xl calls "xc_domain_unpause" while the xm implementation
calls xc_domain_resume.
 
Just in case, have you tried the same with xm save -c ?
shriram
> shriram
>>
>> Ian.
>>
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  RE: [Xen-devel] PV Audio GSoC Project, James Harper
Next by Date:  Re: [Xen-devel] bug, bad page free with hvm guest after commits about AMD IOMMU, Tim Deegan
Previous by Thread:  Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate, AP Xen
Next by Thread:  Re: [Xen-devel] xl save -c issues with Windows 7 Ultimate, AP Xen
Indexes:  [Date] [Thread] [Top] [All Lists]
 
   

Copyright , Citrix Systems Inc. All rights reserved. Legal and Privacy