* xl save -c issues with Windows 7 Ultimate
@ 2011-04-29 19:28 AP Xen
2011-05-03 11:07 ` George Dunlap
2011-05-03 13:01 ` Ian Campbell
0 siblings, 2 replies; 15+ messages in thread
From: AP Xen @ 2011-04-29 19:28 UTC (permalink / raw)
To: xen-devel
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.
root@ubuntu:/etc/xen# xl -v save -c win7 win7chk win7
Saving to win7chk new xl format (info 0x0/0x0/232)
xc: detail: delta 8875ms, dom0 20%, target 0%, sent 971Mb/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
root@ubuntu:/etc/xen# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 2914 4 r----- 604.5
win7 8 1019 2
---ss- 9.8
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?
BTW, if I destroy the domain and bring it back up using "xl restore",
it comes up successfully.
Thanks,
AP
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-04-29 19:28 xl save -c issues with Windows 7 Ultimate AP Xen
@ 2011-05-03 11:07 ` George Dunlap
2011-05-03 19:04 ` AP Xen
2011-05-06 22:01 ` AP Xen
2011-05-03 13:01 ` Ian Campbell
1 sibling, 2 replies; 15+ messages in thread
From: George Dunlap @ 2011-05-03 11:07 UTC (permalink / raw)
To: AP Xen; +Cc: xen-devel
Have you tried it with other operating systems and found it to work?
I.e., is it something specific to Windows 7, or is it a general HVM /
Windows problem?
-George
On Fri, Apr 29, 2011 at 8:28 PM, AP Xen <apxeng@gmail.com> 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.
>
> root@ubuntu:/etc/xen# xl -v save -c win7 win7chk win7
> Saving to win7chk new xl format (info 0x0/0x0/232)
> xc: detail: delta 8875ms, dom0 20%, target 0%, sent 971Mb/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
>
> root@ubuntu:/etc/xen# xl list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 2914 4 r----- 604.5
> win7 8 1019 2
> ---ss- 9.8
>
> 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?
>
> BTW, if I destroy the domain and bring it back up using "xl restore",
> it comes up successfully.
>
> Thanks,
> AP
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-04-29 19:28 xl save -c issues with Windows 7 Ultimate AP Xen
2011-05-03 11:07 ` George Dunlap
@ 2011-05-03 13:01 ` Ian Campbell
2011-05-03 14:09 ` Shriram Rajagopalan
2011-05-03 19:15 ` AP Xen
1 sibling, 2 replies; 15+ messages in thread
From: Ian Campbell @ 2011-05-03 13:01 UTC (permalink / raw)
To: AP Xen; +Cc: Rajagopalan, xen-devel, Shriram
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?
[...]
> 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.
Ian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 13:01 ` Ian Campbell
@ 2011-05-03 14:09 ` Shriram Rajagopalan
2011-05-03 14:31 ` Ian Campbell
2011-05-03 19:17 ` AP Xen
2011-05-03 19:15 ` AP Xen
1 sibling, 2 replies; 15+ messages in thread
From: Shriram Rajagopalan @ 2011-05-03 14:09 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1117 bytes --]
On Tue, May 3, 2011 at 6:01 AM, Ian Campbell <Ian.Campbell@citrix.com>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?
shriram
> Ian.
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 1925 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 14:09 ` Shriram Rajagopalan
@ 2011-05-03 14:31 ` Ian Campbell
2011-05-03 14:42 ` Tim Deegan
2011-05-03 19:17 ` AP Xen
1 sibling, 1 reply; 15+ messages in thread
From: Ian Campbell @ 2011-05-03 14:31 UTC (permalink / raw)
To: rshriram; +Cc: xen-devel
On Tue, 2011-05-03 at 15:09 +0100, Shriram Rajagopalan wrote:
> Remus works with HVM domains via normal xenstore based suspend/resume.
> Only PV-HVM support is "disabled" for the moment.
I'm confused ;-)
PV-HVM uses PV suspend, which can be triggered either by xenstore or the
suspend evtchn, but the choice of which is mostly orthogonal to whether
or not suspend cancellation is supported.
The alternative to PV suspend is the inject an ACPI S3 (or whatever)
event option, isn't it?
Ian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 14:31 ` Ian Campbell
@ 2011-05-03 14:42 ` Tim Deegan
2011-05-03 16:32 ` Shriram Rajagopalan
0 siblings, 1 reply; 15+ messages in thread
From: Tim Deegan @ 2011-05-03 14:42 UTC (permalink / raw)
To: Ian Campbell; +Cc: rshriram, xen-devel
At 15:31 +0100 on 03 May (1304436713), Ian Campbell wrote:
> On Tue, 2011-05-03 at 15:09 +0100, Shriram Rajagopalan wrote:
>
> > Remus works with HVM domains via normal xenstore based suspend/resume.
> > Only PV-HVM support is "disabled" for the moment.
>
> I'm confused ;-)
>
> PV-HVM uses PV suspend, which can be triggered either by xenstore or the
> suspend evtchn, but the choice of which is mostly orthogonal to whether
> or not suspend cancellation is supported.
>
> The alternative to PV suspend is the inject an ACPI S3 (or whatever)
> event option, isn't it?
The alternative is not to involve the OS at all; just use the normal HVM
save and restore functions. For Remus, where downtime will be low and
storage consistency is handled elsewhere, that's good enough.
Tim.
--
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 14:42 ` Tim Deegan
@ 2011-05-03 16:32 ` Shriram Rajagopalan
2011-05-03 16:35 ` Brendan Cully
0 siblings, 1 reply; 15+ messages in thread
From: Shriram Rajagopalan @ 2011-05-03 16:32 UTC (permalink / raw)
To: Tim Deegan; +Cc: Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1320 bytes --]
On Tue, May 3, 2011 at 7:42 AM, Tim Deegan <Tim.Deegan@citrix.com> wrote:
> At 15:31 +0100 on 03 May (1304436713), Ian Campbell wrote:
> > On Tue, 2011-05-03 at 15:09 +0100, Shriram Rajagopalan wrote:
> >
> > > Remus works with HVM domains via normal xenstore based suspend/resume.
> > > Only PV-HVM support is "disabled" for the moment.
> >
> > I'm confused ;-)
> >
> > PV-HVM uses PV suspend, which can be triggered either by xenstore or the
> > suspend evtchn, but the choice of which is mostly orthogonal to whether
> > or not suspend cancellation is supported.
> >
> > The alternative to PV suspend is the inject an ACPI S3 (or whatever)
> > event option, isn't it?
>
> The alternative is not to involve the OS at all; just use the normal HVM
> save and restore functions. For Remus, where downtime will be low and
> storage consistency is handled elsewhere, that's good enough.
>
> Tim.
>
>
Enabling it is a matter of just removing the check for pvhvm, which I ll
remove
and send out a patch soon. :-)
I was waiting for the last remus patch (remus: fix incorrect error handling
for
switch_qemu_logdirty...) to get pulled in before sending the patch.
shriram
> --
> Tim Deegan <Tim.Deegan@citrix.com>
> Principal Software Engineer, Xen Platform Team
> Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
>
>
[-- Attachment #1.2: Type: text/html, Size: 2029 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 16:32 ` Shriram Rajagopalan
@ 2011-05-03 16:35 ` Brendan Cully
0 siblings, 0 replies; 15+ messages in thread
From: Brendan Cully @ 2011-05-03 16:35 UTC (permalink / raw)
To: rshriram; +Cc: Ian Campbell, xen-devel, Tim Deegan
[-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --]
On 2011-05-03, at 9:32 AM, Shriram Rajagopalan wrote:
> On Tue, May 3, 2011 at 7:42 AM, Tim Deegan <Tim.Deegan@citrix.com> wrote:
> At 15:31 +0100 on 03 May (1304436713), Ian Campbell wrote:
> > On Tue, 2011-05-03 at 15:09 +0100, Shriram Rajagopalan wrote:
> >
> > > Remus works with HVM domains via normal xenstore based suspend/resume.
> > > Only PV-HVM support is "disabled" for the moment.
> >
> > I'm confused ;-)
> >
> > PV-HVM uses PV suspend, which can be triggered either by xenstore or the
> > suspend evtchn, but the choice of which is mostly orthogonal to whether
> > or not suspend cancellation is supported.
> >
> > The alternative to PV suspend is the inject an ACPI S3 (or whatever)
> > event option, isn't it?
>
> The alternative is not to involve the OS at all; just use the normal HVM
> save and restore functions. For Remus, where downtime will be low and
> storage consistency is handled elsewhere, that's good enough.
>
> Tim.
>
>
> Enabling it is a matter of just removing the check for pvhvm, which I ll remove
> and send out a patch soon. :-)
> I was waiting for the last remus patch (remus: fix incorrect error handling for
> switch_qemu_logdirty...) to get pulled in before sending the patch.
As we discussed earlier, please do not do this without actually testing that pvhvm checkpointing works. On windows. PV suspend is a cooperative process and the reason it is disabled is that it hasn't been tested.
[-- Attachment #1.2: Type: text/html, Size: 2265 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 11:07 ` George Dunlap
@ 2011-05-03 19:04 ` AP Xen
2011-05-06 22:01 ` AP Xen
1 sibling, 0 replies; 15+ messages in thread
From: AP Xen @ 2011-05-03 19:04 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel
I have only tried with Windows 7 for now. Let me try with CentOS 5.6
and get back to you.
Thanks,
AP
On Tue, May 3, 2011 at 4:07 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Have you tried it with other operating systems and found it to work?
> I.e., is it something specific to Windows 7, or is it a general HVM /
> Windows problem?
>
> -George
>
> On Fri, Apr 29, 2011 at 8:28 PM, AP Xen <apxeng@gmail.com> 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.
>>
>> root@ubuntu:/etc/xen# xl -v save -c win7 win7chk win7
>> Saving to win7chk new xl format (info 0x0/0x0/232)
>> xc: detail: delta 8875ms, dom0 20%, target 0%, sent 971Mb/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
>>
>> root@ubuntu:/etc/xen# xl list
>> Name ID Mem VCPUs State Time(s)
>> Domain-0 0 2914 4 r----- 604.5
>> win7 8 1019 2
>> ---ss- 9.8
>>
>> 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?
>>
>> BTW, if I destroy the domain and bring it back up using "xl restore",
>> it comes up successfully.
>>
>> Thanks,
>> AP
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 13:01 ` Ian Campbell
2011-05-03 14:09 ` Shriram Rajagopalan
@ 2011-05-03 19:15 ` AP Xen
1 sibling, 0 replies; 15+ messages in thread
From: AP Xen @ 2011-05-03 19:15 UTC (permalink / raw)
To: Ian Campbell; +Cc: Shriram Rajagopalan, xen-devel
I am not running with any PV drivers. I can try with James Harper's
GPLPV drivers and see how it behaves.
Thanks,
AP
On Tue, May 3, 2011 at 6:01 AM, Ian Campbell <Ian.Campbell@citrix.com> 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?
>
> [...]
>> 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.
>
> Ian.
>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 14:09 ` Shriram Rajagopalan
2011-05-03 14:31 ` Ian Campbell
@ 2011-05-03 19:17 ` AP Xen
2011-05-05 14:42 ` Shriram Rajagopalan
1 sibling, 1 reply; 15+ messages in thread
From: AP Xen @ 2011-05-03 19:17 UTC (permalink / raw)
To: rshriram; +Cc: xen-devel, Ian Campbell
On Tue, May 3, 2011 at 7:09 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
> On Tue, May 3, 2011 at 6:01 AM, Ian Campbell <Ian.Campbell@citrix.com>
> 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
> shriram
>>
>> Ian.
>>
>>
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 19:17 ` AP Xen
@ 2011-05-05 14:42 ` Shriram Rajagopalan
2011-05-05 21:01 ` AP Xen
0 siblings, 1 reply; 15+ messages in thread
From: Shriram Rajagopalan @ 2011-05-05 14:42 UTC (permalink / raw)
To: AP Xen; +Cc: xen-devel, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 7431 bytes --]
On Tue, May 3, 2011 at 2:17 PM, AP Xen <apxeng@gmail.com> wrote:
> On Tue, May 3, 2011 at 7:09 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>
> wrote:
> > On Tue, May 3, 2011 at 6:01 AM, Ian Campbell <Ian.Campbell@citrix.com>
> > 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.
> >>
> >>
> >
> >
>
>
[-- Attachment #1.2: Type: text/html, Size: 8880 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-05 14:42 ` Shriram Rajagopalan
@ 2011-05-05 21:01 ` AP Xen
2011-05-06 2:31 ` Shriram Rajagopalan
0 siblings, 1 reply; 15+ messages in thread
From: AP Xen @ 2011-05-05 21:01 UTC (permalink / raw)
To: rshriram; +Cc: xen-devel, Ian Campbell
On Thu, May 5, 2011 at 7:42 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
> On Tue, May 3, 2011 at 2:17 PM, AP Xen <apxeng@gmail.com> wrote:
>>
>> On Tue, May 3, 2011 at 7:09 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>
>> wrote:
>> > On Tue, May 3, 2011 at 6:01 AM, Ian Campbell <Ian.Campbell@citrix.com>
>> > 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
xm save -c doesn't seem to work at all.
root@tubuntu:/etc/xen# xm save -c win7 win7chk
Error: Timeout waiting for domain 2 to suspend
[2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:124) [xc_save]:
/usr/lib/xen/bin/xc_save 22 2 0 0 0
[2011-05-05 13:55:43 1615] INFO (XendCheckpoint:423) xc_save: failed
to get the suspend evtchn port
[2011-05-05 13:55:43 1615] INFO (XendCheckpoint:423)
[2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:394) suspend
[2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:127) In
saveInputHandler suspend
[2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:129) Suspending 2 ...
[2011-05-05 13:55:43 1615] DEBUG (XendDomainInfo:524)
XendDomainInfo.shutdown(suspend)
[2011-05-05 13:55:43 1615] DEBUG (XendDomainInfo:1881)
XendDomainInfo.handleShutdownWatch
[2011-05-05 13:56:44 1615] DEBUG (XendDomainInfo:1881)
XendDomainInfo.handleShutdownWatch
[2011-05-05 13:56:44 1615] INFO (XendCheckpoint:423) xc: error:
Suspend request failed: Internal error
[2011-05-05 13:56:44 1615] INFO (XendCheckpoint:423) xc: error: Domain
appears not to have suspended: Internal error
[2011-05-05 13:56:44 1615] ERROR (XendCheckpoint:185) Save failed on
domain win7 (2) - resuming.
Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
line 146, in save
forkHelper(cmd, fd, saveInputHandler, False)
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
line 395, in forkHelper
inputHandler(line, child.tochild)
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
line 131, in saveInputHandler
dominfo.waitForSuspend()
File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py",
line 2998, in waitForSuspend
raise XendError(msg)
XendError: Timeout waiting for domain 2 to suspend
[2011-05-05 13:56:44 1615] DEBUG (XendDomainInfo:3135)
XendDomainInfo.resumeDomain(2)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-05 21:01 ` AP Xen
@ 2011-05-06 2:31 ` Shriram Rajagopalan
0 siblings, 0 replies; 15+ messages in thread
From: Shriram Rajagopalan @ 2011-05-06 2:31 UTC (permalink / raw)
To: AP Xen; +Cc: xen-devel, Ian Campbell
[-- Attachment #1.1: Type: text/plain, Size: 10061 bytes --]
On Thu, May 5, 2011 at 2:01 PM, AP Xen <apxeng@gmail.com> wrote:
> On Thu, May 5, 2011 at 7:42 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>
> wrote:
> > On Tue, May 3, 2011 at 2:17 PM, AP Xen <apxeng@gmail.com> wrote:
> >>
> >> On Tue, May 3, 2011 at 7:09 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca
> >
> >> wrote:
> >> > On Tue, May 3, 2011 at 6:01 AM, Ian Campbell <Ian.Campbell@citrix.com
> >
> >> > 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
>
> xm save -c doesn't seem to work at all.
>
> root@tubuntu:/etc/xen# xm save -c win7 win7chk
> Error: Timeout waiting for domain 2 to suspend
>
> [2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:124) [xc_save]:
> /usr/lib/xen/bin/xc_save 22 2 0 0 0
> [2011-05-05 13:55:43 1615] INFO (XendCheckpoint:423) xc_save: failed
> to get the suspend evtchn port
> [2011-05-05 13:55:43 1615] INFO (XendCheckpoint:423)
> [2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:394) suspend
> [2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:127) In
> saveInputHandler suspend
> [2011-05-05 13:55:43 1615] DEBUG (XendCheckpoint:129) Suspending 2 ...
> [2011-05-05 13:55:43 1615] DEBUG (XendDomainInfo:524)
> XendDomainInfo.shutdown(suspend)
> [2011-05-05 13:55:43 1615] DEBUG (XendDomainInfo:1881)
> XendDomainInfo.handleShutdownWatch
> [2011-05-05 13:56:44 1615] DEBUG (XendDomainInfo:1881)
> XendDomainInfo.handleShutdownWatch
> [2011-05-05 13:56:44 1615] INFO (XendCheckpoint:423) xc: error:
> Suspend request failed: Internal error
> [2011-05-05 13:56:44 1615] INFO (XendCheckpoint:423) xc: error: Domain
> appears not to have suspended: Internal error
> [2011-05-05 13:56:44 1615] ERROR (XendCheckpoint:185) Save failed on
> domain win7 (2) - resuming.
> Traceback (most recent call last):
> File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
> line 146, in save
> forkHelper(cmd, fd, saveInputHandler, False)
> File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
> line 395, in forkHelper
> inputHandler(line, child.tochild)
> File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
> line 131, in saveInputHandler
> dominfo.waitForSuspend()
> File "/usr/local/lib/python2.6/dist-packages/xen/xend/XendDomainInfo.py",
> line 2998, in waitForSuspend
> raise XendError(msg)
> XendError: Timeout waiting for domain 2 to suspend
> [2011-05-05 13:56:44 1615] DEBUG (XendDomainInfo:3135)
> XendDomainInfo.resumeDomain(2)
>
> Any debug output from xen? "xm dmesg"
shriram
[-- Attachment #1.2: Type: text/html, Size: 12679 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: xl save -c issues with Windows 7 Ultimate
2011-05-03 11:07 ` George Dunlap
2011-05-03 19:04 ` AP Xen
@ 2011-05-06 22:01 ` AP Xen
1 sibling, 0 replies; 15+ messages in thread
From: AP Xen @ 2011-05-06 22:01 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel
On Tue, May 3, 2011 at 4:07 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> Have you tried it with other operating systems and found it to work?
> I.e., is it something specific to Windows 7, or is it a general HVM /
> Windows problem?
I tried this with CentOS 5.6 and saw the same behavior.
root@ubuntu:~# xl -vvv save -c centos /etc/xen/centoschk
Saving to /etc/xen/centoschk new xl format (info 0x0/0x0/255)
libxl: debug: libxl_dom.c:384:libxl__domain_suspend_common_callback
issuing PVHVM suspend request via XenBus control node
libxl: debug: libxl_dom.c:389:libxl__domain_suspend_common_callback
wait for the guest to acknowledge suspend request
libxl: debug: libxl_dom.c:434:libxl__domain_suspend_common_callback
guest acknowledged suspend request
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: type fail: page 0 mfn 000f2000
xc: detail: type fail: page 1 mfn 000f2001
xc: detail: type fail: page 2 mfn 000f2002
xc: detail: delta 9371ms, dom0 25%, target 0%, sent 920Mb/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.7
libxl: debug: libxl_dom.c:546:libxl__domain_save_device_model Qemu
state is 7204 bytes
root@ubuntu:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 2914 4 r----- 6576.4
centos 7 1019 2 ---ss- 575.4
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-05-06 22:01 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-29 19:28 xl save -c issues with Windows 7 Ultimate AP Xen
2011-05-03 11:07 ` George Dunlap
2011-05-03 19:04 ` AP Xen
2011-05-06 22:01 ` AP Xen
2011-05-03 13:01 ` Ian Campbell
2011-05-03 14:09 ` Shriram Rajagopalan
2011-05-03 14:31 ` Ian Campbell
2011-05-03 14:42 ` Tim Deegan
2011-05-03 16:32 ` Shriram Rajagopalan
2011-05-03 16:35 ` Brendan Cully
2011-05-03 19:17 ` AP Xen
2011-05-05 14:42 ` Shriram Rajagopalan
2011-05-05 21:01 ` AP Xen
2011-05-06 2:31 ` Shriram Rajagopalan
2011-05-03 19:15 ` AP Xen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.