Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Oct 25, 2012 at 2:13 AM, Whit Blauvelt <whit+drbd at transpect.com> wrote: > On Thu, Oct 25, 2012 at 12:50:57AM +0200, Rasto Levrinc wrote: >> On Wed, Oct 24, 2012 at 11:16 PM, Whit Blauvelt <whit.drbd at transpect.com> wrote: >> > I wrote: >> > >> >> > I've got a fairly simple setup, that back some time ago was working well, >> >> > but at some point has slipped away from me. I have a number of KVM VMs which >> >> > have been set up by using a distinct LVM partition behind each, and then >> >> > using DRBD to mirror these between two servers via a dedicated crossover. >> >> You mean LVM -> DRBD -> KVM, not LVM->(KVM, DRBD), right? > > Hmm. Could this be where the administrative error occurs? In terms of > installation order it was LVM (on both servers), then KVM (directly to the > LVM volume on on server), then DRBD (doing an initial sync from the one Yup, it's your DRBD understandig problem. DRBD doesn't work like that although I guess it could. KVM has to write to DRBD, DRBD writes to LVM in your case. > server to the other). This may well be where I got stupid, because I > accepted the default in LCMC of internal metadata. I have no good reason to > think that the raw storage for a KVM VM is compatible with internal > metadata. Just wasn't thinking that through. My past use of DRBD has been > with file systems (where I've never had a problem with that) not with > logical volumes as raw storage. > > So while I can wish that DRBD (or even LCMC) would be smart enough to > complain when asked to used internal metadata in a context where it isn't > really sane, there can't be guardrails on everything. For external metadata, > the DRBD manual is less than complete. There are a couple of formulas to > calculate needed size, but I don't find a step-by-step example. I think that LCMC tries to prevent error like that. It doesn't let you create internal meta-data on an existing VM images, unless you choose "Create new meta-data & destroy data". I think I'll change that to "Destroy data & create new meta-data" if there're people that stop reading after the first "&". > > If I were, on installation, to do LVM then DRBD then create the KVM VM on > that (as raw storage) would the KVM VM respect the space used by the DRBD > metadata? This might actually be an easier process, cloning each of the VMs > to a new DRBD-on-LVM pair, than creating external metadata (somehow) for > each of the current pairs. But I assume when KVM-QEMU is told to use the LVM > as a raw partition, it's just going to use the whole thing, no matter what > DRBD's written to the end. Or is it? When you use DRBD drbd block devices, the internal meta-data safety is already taken care of. At this point if you use LCMC to configure KVM, it doesn't even let you to see the LVM block devices that have DRBD on them. If you configure it like that outside of LCMC, the GUI could warn about this kind (and many other) misconfigurations, but that's not implemented yet. Rasto > > What's the right way to use DRBD with KVM, when KVM is writing each VM to a > dedicated raw LVM volume? If KVM were writing qcows to a filesystem layer, > with DRBD behind that filesystem, this becomes a conventional problem. But > with the LVM volume being used raw, and a distinct DRBD mirror desired for > each KVM VM on raw LVM volume instance, what are the good options? > > Thanks, > Whit -- Dipl.-Ing. Rastislav Levrinc rasto.levrinc at gmail.com Linux Cluster Management Console http://lcmc.sf.net/