Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> No. To actually pull this off, you'd need to do it with two resources,
> simply use two resource sections, both using the local hostname (what
> uname -n reports), and some "non-existant-peer" hostname, then connect
> those to each other.
>
> I really doubt that this would be useful, though, and I'm not sure about
> deadlock potential due to "unexpected sharing" of e.g. memory pools.
> But feel free to try.
>
> resource to-be-used-as-primary {
> on self { # (what uname -n reports)
> address 127.0.0.1:8000;
> disk ... # your local device here
> }
> on other { # arbitrary
> address 127.0.0.1:8001; # only value actually used on "self"
> ... nonsense values
> }
> }
>
> resource to-be-used-as-secondary, never to be made primary {
> on self {
> address 127.0.0.1:8001; # what is above in "on other"
> disk ... # your iscsi device here
> }
> on other {
> address 127.0.0.1:8000; # what is above in "on self"
> ... nonsense values
> }
> }
Aha! That got it working, devices are synchronizing, now. I'm running
this all on a test system right now, so I'll try to hit it with a bunch
of data and make sure I don't get any unexpected behavior.
The naming of the drbd devices seems to be a little picky. I'd like to
be able to call one /dev/drbd-do-no-use or something like that, but drbd
seems to choke on this and is fairly strict about the drbd<minor> naming
scheme. Oh well, not a huge deal, I'll just have to be very careful.
>
> Regardless of what replication technology you use, you better make
> absolutely sure that is the only entity ever modifying your disk images
> on the iSCSI target host. Not even "read-only loop mount" that stuff,
> typically even read-only mounts first replay the journal...
> much less start a VM directly from those images. Or the replication
> will lose track of blocks in need for resynchronisation.
> In other words: if you scramble your data, don't blame technology.
>
Understood. I've done enough with shared storage to know that this
would be bad. Only the primary device will be mounted, and the
secondary one won't be used at all. I'll use the snapshots off the
secondary one for restore purposes, but restores will likely be done by
presenting the iSCSI snapshots/clones to a different system altogether
and mounting them there.
-Nick
--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.