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, Arnold -------------- 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>