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 03:30:18PM +0200, Rasto Levrinc wrote: > 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 "&". Not true Rasto. I'm walking through the process right now, with 1.4.1, and when it gets to that step it says "meta-data[Create new meta-data V]". My brackets represent a list box that, if I press the down arrow, then reads, "[Create new meta-data & destroy data]". But leaving that on the first, default option, simply "[Create new meta-data]," when I press the "Create Meta-Data" button to the right of that, it happily goes forward and reports: Meta-data on vmothership1 have been created. Meta-data on vmothership2 have been created. If you have a test for existing data, such that metadata should not be created without the user agreeing to "destroy data," that test is failing when the existing data consists of a KVM VM written directly to an LVM logical volume. On the other hand, it's possible that KVM actually leaves enough space for the metadata, so that your test is satisfied. It's a total mystery to me how KVM-QEMU specifically uses logical volumes when putting VMs directly on them. > > 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. So it can't be used to put KVM VMs on top of DRBD on top of logical volumes, as Lars says is the right way to do this? > 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. LCMC does some things very, very well, for which I thank you. For an overview of systems, it's the best thing I've seen. But for a lot of libvirt operations, the cli utilities are still more powerful, and I prefer them there. Okay, so if I want to put KVM VMs correctly on top of DRBD-mirrored logical volumes, and I don't want to be limited by LCMC at this point, I should: 1. create the logical volumes 2. link them by DRBD with internal metadata 3. then for example clone like this: virt-clone --original someVM --name someVMdrbd --file /dev/drbdN --prompt and it will flow onto DRBD in the right way, and everything will be happy? Then the DRBD manual might be amended to say "Existing data cannot be used if it's a VM." And LCMC might be improved so that at minimum it says "[Create new meta-data & destroy data]" rather than merely "[Create new meta-data]" in a circumstance where the user has been less than fully informed by the DRBD manual. There's a lot going on under the covers here, out of site of admins. I'm light-years from being a filesystem engineer. But I follow their discussions in other contexts, and they commonly even confuse each other. So I understand that this is both hard to document, and hard to write an excellent GUI for. LCMC goes a long way, and recognizes that the main current use for this stuff is with VMs. The DRBD manual, on the other hand, could use a serious update to include correct advice for VM-hosting contexts. Best, Whit