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

[Xen-devel] Problems with HVM Save/Restore.

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Problems with HVM Save/Restore.
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Fri, 20 Apr 2007 15:53:14 +0200
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "Woller, Thomas" <thomas.woller@xxxxxxx>
Delivery-date: Fri, 20 Apr 2007 06:52:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceDUz1/BmwvgkqHQpy0LKqCUGAiPw==
Thread-topic: Problems with HVM Save/Restore.
In general, and without trying to break it, HVM save/restore works quite
well... 

There is one obvious and immediate problem: 
The SDL display is (correctly) removed as part of the first save, but
restore never restores the display. 

The more complex but rarer problem:
However, my attempts to break it does indeed break it after some random
amount of time. The breaking is in the form of relatively heavy disk
activity whilst looping over save/restore/sleep. 

The application in this case is a simple C-program run on sles 9.3
(32bit, HVM, 128MB on 64-bit hypervisor) generates a file of 25MB with a
incrementing pattern, then starts reading the data and writing the
inverse back, in blocks of 512 bytes, checking that the read data is
what's expected.

The current behaviour indicates that the guest gets into a state where
it's idle, but no longer communicating on the ssh-connection, and from
what I can tell, nor on the disk-io. Trying to bring up a VNC display
doesn't work either. 

Since I loose the SDL console display, I can't see if there's any
error/warning messages from the guest. 

It is entirely possible that the disk-io is continuing, but the network
connection to the guest is DEFINITELY lost.

I'm at a loss on even where to start looking at the problem - one thing
I do know: the guest is not killed and restarted, because I've set
"on_crash=destroy" in the configuration file. 

I believe I can also reproduce the same problem with a "simple guest"
(single executable file loaded instead of hvmloader that executes
disk-testing to a disk-image that is filled with a running 32-bit count
[writen back inverted). This guest also fails to properly operate after
some number of save/restore cycles, but I'm not 100% sure if this is a
problem with the guest itself not handling aborted IDE operations in
some way - this is why I created the disk-io in Linux application above.


--
Mats



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