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/
Home Products Support Community News


Re: [Fwd: Re: [Xen-users] File-backed VBDs Migration help]

To: Jonathan Wheeler <griffous@xxxxxxxxxxxx>
Subject: Re: [Fwd: Re: [Xen-users] File-backed VBDs Migration help]
From: James Bulpin <James.Bulpin@xxxxxxxxxxxx>
Date: Tue, 14 Jun 2005 11:46:24 +0100
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 14 Jun 2005 10:45:35 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <42AEB352.3040108@xxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <42AEB352.3040108@xxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

An alternative to using file-backed VBDs would be DRBD on top of local disk partitions. DRBD will allow you to have mirrored volumes on the source and target machines of the migration. DRBD will allow background synchronisation of the replicas so that are almost in sync before you perform the migration (or lazy synchronisation after the migration). There still has to be a step where the domain stops and the DRBD primary/secondary assignment is changed. This will generally be quick.

This can be most easily done using save and restore with drbd primary and secondary commands issued between saving and restoring. I have done this with non-live migration (which is essentially just save and restore without having to have a named file) but it required a very dirty hack to libxc.

There has been some discussion here recently of DRBD which you may want to look at.



Jonathan Wheeler wrote:
James Bulpin wrote:


If you only want migration for maintanence purposes then you could
probably put up with a small downtime during the migration. How about
having your "migrate" sequence as:

xm save mydomain /path/mydomain.save
rcp [or whatever] /path/mydomain.save otherhost:/path/mydomain.save
rcp /path/mydomain-vbd.img otherhost:/path/mydomain-vbd.img

then on otherhost:

xm restore /path/mydomain.save

(Disclaimer: I've not tried this but I can't see any reason why it
wouldn't work.)

Downtime would be dictated by the size of your save and vbd files and
the speed of the network between the hosts.


Thanks James,

I tried that out, and it appeared to work ok. The guest didn't pick up
the new time, but perhaps that's just how it works - I'm still rather
new to all this.

I would definitely prefer to not have the downtime associated with
copying the larger images across the network.
Do I have any other options that don't involve using a nfs server as a
single point of failure?


Xen-users mailing list

Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>