Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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