[DRBD-user] [drbd-mc] LCMC display says "up to date" but DRBD is not

Whit Blauvelt whit+drbd at transpect.com
Thu Oct 25 16:27:27 CEST 2012

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



More information about the drbd-user mailing list