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


[Xen-devel] xen, drbd, live migration

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] xen, drbd, live migration
From: Michael Paesold <michael@xxxxxxxxxx>
Date: Wed, 07 Sep 2005 18:11:12 +0200
Delivery-date: Wed, 07 Sep 2005 18:21:00 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

I would like to enable live migration of vm's between two hosts using a block device synced via drbd between the two hosts.

Google doesn't help much. Searching for
> xen drbd "live migration"
gives 2 related posts on xen-users.

Myself asking about the same topic, in June:

This one is about "non-live" migration, including a hack of libxs:

DRBD allows to syncronize a block device between two hosts, it can be seen as raid-1 over network. The most importent issue for live migration is that you must access the drbd block device only from either of the hosts, never from both.

I have created a block-drbd script to make a /dev/drbd device accessable at vbd "bind" and release the resource on "unbind" (drbdadm primary and secondary in DRBD terms).

Now the sequence of events in Xen live migration seems to be this:
1) send configuration to target, create resources there (including vbd bind!)
2) copy memory
3) destroy vm on source (unbind vbds)
4) unpause vm on destination


Now (1) is were it fails already, because with drbd you have to first "unbind" the device on the old host and then "bind" it on the new one. There is no way around this.

So the sequence would have to look like this:
1) send configuration to target, don't create vbd resources yet (only place holders perhaps?)
2) copy memory
3) destroy vm on source (unbind vbds)
4) bind vbds on target
5) unpause vm on destination

DRBD is a very reliable and well performing solution. It would be great to be able to use it with xen and would be an outstanding solution for highly available xen, at least in a two-hosts setup.

To those developers with insight in the migration stuff: is it possible to change this in Xen so it will work as above? Do you have time or interest? Could you help me to find the right places so I can try myself?

Best Regards,
Michael Paesold

Xen-devel mailing list

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