Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 24/06/11 16:45, Noah Mehl wrote: > I've done a lot of thinking on this point, but I've come to a > different conclusion. I think that a drbd resource per guest HD is > not a great way to go. I think that adds a lot of complexity and > overhead you don't necessarily need. I prefer this route myself. Even though, you're right, there is quite a lot more complexity, that's the price you pay for the flexibility. It lets you move a single VM from A to B (or even to C if it needs dedicated hardware) without having to move lots of them. > I have not seen a significant performance difference between lvm and > qcow2. Perhaps you have? I've not done any testing, and although I wouldn't suspect there's a massive difference between qcow2 and lvm, I'd personally rather not have the extra indirection layer of a filesystem at the host level, which is why I like LVM. Disk is (relatively) cheap these days, and LVM's simple to grow anyway :) On Jun 24, 2011, at 10:58 AM, Whit Blauvelt wrote: >> There also should be a whole lot less needed on the pacemaker- >> corosync/heartbeat side. What I've been hoping to find is documentation on >> just enough of pacemaker-corosync/heartbeat to handle this simplified >> architecture adequately. But most of the documentation isn't aimed towards >> an architecture like this at all, and just about nothing I've found >> addresses a KVM environment. 'Just enough' is the approach that proxmox VE seems to take at the moment, which is why it's my current favourite :-) It can be made to use primary-primary DRBD with LVM volumes, although there's no CLVM - it just relies on the proxmox management stuff to not run the same VM on both hosts. It's 'good enough' for us though, and is basically a helpful wrapper around some simple text config files - the main reason I like it.