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

Re: [Xen-devel] xm save -checkpoint supported?

On Sunday, 17 June 2007 at 14:02, Claris Castillo wrote:
> Well the problem is that  I want to be able to 'checkpoint" a running VM
> periodically for
> a server availability experiment and I need some sort of documentation to
> even know if
> it is possible with Xen.
> 
> I did not find anything in the documentation about this feature but I
> emailed the user list
> and I got a reply from Matt where he referred me to "xm save -c" BUT I have
> Xen 3.1
> running on RHEL 5 and the manual page does not  include any information
> about  "xm save -c <vm> <savefile>".
> Am I missing something with Xen 3.1?

I guess the manual page wasn't updated. xm save --help should mention
the option.

> In your email you mentioned  "external-device-migrate". I just looked at
> the script and it does not
> seem to perform the checkpointing.  Does this feature works similar to the
> one
> VMWare uses (REDELOG?).

I don't know how that feature works. xm save -c checkpoints the state
of the VM memory and CPU to disk, but does not deal with
disks. external-device-migrate is a hook to let you add in your own
scripts to checkpoint disks when the guest is being
checkpointed. The form of these scripts will depend on what kind of
disks your domain is using (eg LVM or qcow). For an idea, I'll attach
some demo scripts I posted back in December. They aren't meant to be
deployed, but rather to give you an idea how you might checkpoint your
own disks.

> I know these kind of questions  are more appropriate for the users-mailing
> list but for some
> reason Xen users don't seem to be using the checkpointing feature at all
> (or nobody
> has ran into any issue with the feature --> which it is pretty good!)

The feature could use some better docs. The wiki is probably a good
starting point for them.
--- Begin Message ---
To: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] demo code to create lvm snapshots for checkpointed domains
From: Brendan Cully <brendan@xxxxxxxxx>
Date: Thu, 14 Dec 2006 23:46:18 -0800
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>
Mail-followup-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-11-21)
Here's some terrible code that demonstrates how one might create
synchronised LVM snapshots of running domains. It hooks into the
external-device-migrate script to call lvcreate -s at xm save time
during migrate round 2. There's also an awful wrapper around xm save
-c that rewrites the resulting save record to use the snapshot as its
vbd instead of the parent device. It'd be really nice if there were a
way to rewrite the config at save time instead of afterwards.

This code will probably set your computer on fire. I'm just posting it
because it's hard to play with checkpoints without some kind of disk
snapshot mechanism.

The pieces: a vbd-migrate.sh script that goes into /etc/xen/scripts to
be sourced by external-device-migrate, an lvm-save script called by
vbd-migrate to do the actual work of creating the snapshot, and a
checkpoint wrapper to create the checkpoint and rewrite the resulting
image. They're not useful out of the box unless your home directory is
/users/brendan.

Attachment: vbd-migration.sh
Description: Text document

Attachment: lvm-save
Description: Text document

Attachment: checkpoint
Description: Text document

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

--- End Message ---
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>