On 23/07/2013 18:11, Charles Lyons - ConnetU wrote:

If we snapshot the LV itself, presumably we'll get a copy not only of
the VM's volume block data but also of DRBD metadata on the LV (which I
understand is stored in the end/final segment(s) of the LV).

Yes, assuming you are using internal metadata. I'm doing exactly this too.

(1) Is there any danger of this process not giving a DRBD-consistent
snapshot? Is there anything within DRBD which needs to be flushed/synced
prior to starting the snapshot (as is the practice with SQL)?

I've found it to be 100% reliable, it worked absolutely fine when I really needed it.

(2) How is best to restore an image file of the LV, assuming the VM is
offline and, if necessary, the DRBD resource can be
detached/disconnected on each/both side(s)?

I treat it more or less like a new resource. I do the below, this works but is perhaps OTT:

# Shutdown the VM
drbdadm secondary <resource> # on the primary node
drbdadm down <resource>   # on both nodes
# Restore the LV image to the LV on one node
drbdadm create-md <resource> # on both nodes
drbdadm up <resource> # on both nodes
drbdadm -- -o primary <resource> # on the node I restored
# Start the VM

Because you have new metadata on both nodes, there will be a full resync doing the above.

I suppose, but have not tried and proven, that this could be simplified by just doing:

# Shutdown the VM
# Restore the LV image to the DRBD resource in primary role.
# Start the VM

The LV image will of course be longer than the DRBD resource but the extra is the metadata at the end of the volume which we're not interested in anyway. Because you write to the DRBD resource rather than the underlying LV, the sync to the secondary is already happening during your restore.

(3) Presumably it doesn't matter if the snapshot is taken on the primary
or secondary?

With protocol C, it doesn't matter.

Second related topic: if we've got an existing snapshot, can we use this
as the basis for creating a totally new DRBD resource... i.e. creating a
new LV of identical size, dd the image to the LV and then create a new
DRBD resource on top. Is there anything in the metadata (like global
UUIDs) which could be duplicated and confuse DRBD? If so, is there a
recommended way to "reset" the metadata prior to attaching so it will
appear as a totally new pre-seeded volume?

Yes, using the method I described above (drbdadm create-md <resource>) you'll have fresh metadata on both sides. You'll be prompted before it overwrites the existing metadata.

HTH,
Simon

_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user

Reply via email to