[DRBD-user] DRBD with KVM for live migrations

Arnold Krille arnold at arnoldarts.de
Sun Oct 30 22:07:25 CET 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Sunday 30 October 2011 21:24:33 Bart Coninckx wrote:
> On 10/30/11 21:18, Trey Dockendorf wrote:
> > I do need live migration but not as a failover.  So the migration will
> > be manual and not automatic.  In that case I would at some point have to
> > run in primary/primary.  Is the cluster fs only for shared storage
> > configurations?  Also what ensures that the VMs disk is only being
> > accesses by one hypervisor node at a time?  Would libvirt or drbd
> > controll/ensurs that or is it up to me?  Thats my main concern once I
> > know this is feasible and the best route.
> OK, I see now. Regardless, you need prim/prim then. The shared storage
> IS the DRBD resource. You need it to be the same on both nodes to be
> able to live migrate or even fail over. You could however also use DRBD
> to serve as shared storage for the config files. It makes sense to have
> this information the same on both nodes.

At least when you set up your machines with the graphical manager from libvirt 
and make then move at least once (before adding them as cluster-resources) the 
configs get copied automatically.

For a drbd with dual-primary, the layer above needs to know about 
synchronizing locks and accesses. Like with clvm, gfs2 and ocfs2 (which I am 
using for our virt-pool).
But I am thinking: The images are only accessed by one "app" (the virtual 
machine), there shouldn't be any need for additional locks. So one could get 
away with just using ext for the partition too. Unless there is some meta-data 
writing/locking I am missing...

> Ensuring unique access is established by, as mentioned, cluster
> software. The KVM resource (in case of Pacemaker) will have to be
> configured to be able to run uniquely on ONE node.

Which is the default for primitives. And running virtual machines as clones 
would only make sense for unique-clones with a shared read-only image.

Have fun,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111030/786b6672/attachment.pgp>

More information about the drbd-user mailing list