Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Michael, sorry I did not speak about KVM, I have never used it, my experience is with Xen, so I can only assume you can do something similar with KVM. My point was that having a dedicated DRBD resource for each VM (as opposed to replicating the entire volume) gives you granular control over each virtual disk. Allowing you to move a VM from one machine to the other, and not requiring that you have a primary/primary setup and a cluster file system. This is of course at the expense of having many LVs and DRBD resources, but I have not run into any issues with my setup so far. On Mon, May 10, 2010 at 2:29 PM, Ben Timby <btimby at gmail.com> wrote: > Michael, I have a similar setup, however, I am going with a simpler > configuration. > > I have two Xen hypervisor machines, each with a 1TB volume. I use LVM > on top of the 1TB volume to carve out LVs for each VM harddrive. > > Then I have DRBD replicating each LV. So, currently I have 14 DRBD > devices, I add a new DRBD resource whenever I create a new VM. > > This allows each VM to migrate from one hypervisor to the other > independently. All the DRBD resources are setup for dual primary, this > is needed to support Xen live migration. > > I let Hearbeat manage the VMs and I use the drbd: storage type for the > Xen VMs, so Xen can handle the DRBD resources. This gives me failover > for all the VMs, as well as manual live migration. Currently I run > half the VMs on each hypervisor 7/7, to spread the load, of course > Hearbeat will boot up the VMs on the remaining hypervisor if one of > the systems fail. When I perform maintenance, I can put a Heartbeat > node into standby and the VMs live migrate. > > This has been a very stable configuration for me.