* Daniel Kahn Gillmor:
> On 03/21/2011 07:12 PM, Hilko Bengen wrote:
>> (1) A shelf/slot address should uniquely identify a target in a
>> broadcast domain.
>>
>> (2) A shelf/slot address should uniquely identify a target reachable
>> from a host via any network interface that is configured for AoE. (Your
>> example above violates this.)
>>
>> If I can't guarantee both, I risk data loss.
>
> Yes, exactly. And the concern you've reported here about vblade-persist
> will *only* be triggered in the case where at least one of these two is
> violated.
As long as the initiator on "B" is configured to use only the interface
in broadcast domain "x" it does not get to see the target exported via
"y" at all, so there is no danger.
> I'm still looking for the use case where vblade-persist's symlink
> creation is actually independently problematic.
Here is another example that I didn't even think of when I first wrote
the bug report. This is what I have been running successfully for a few
years, using vblade and home-grown wrappers:
A server exports identical but separate AoE targets to a number of
rather "dumb" clients, each on a separate VLAN. Separation using VLANs
puts each client into its own broadcast domain, so I am able to present
the same configuration to each client as far as AoE is concerned: From
every client's point of view, the "disk" it accesses is AoE target e0.0.
If I had used vblade-persist, only the first target could be
successfully brought up since the symlink creation would fail for every
target after that.
>> As the node-independent consistent view seems to be important to you:
>> Could you live with putting the symlinks into a different directory
>> (e.g. /var/run/vblade-persist as suggested) and extend the udev rules to
>> create symlinks to any real /dev/etherd/ex.y device node that may pop
>> up? (I would make the last part optional and off-by-default, though.)
>
> This seems excessive to me -- the standard place for these files is
> /dev/etherd.
If they are device nodes using the *initiator* and through udev: yes. I
still think that a configuration tool for an AoE *target* should not put
its files in the same place.
>> Why is the node-independent view so important to you, anyeay? What
>> problem does it solve?
>
> OK, here's an example: consider a group of machines, each providing
> physical storage to a pool on a shared network segment, and each acting
> as a host for some common virtualization implementation (e.g. KVM).
>
> Each virtual server (guest) has a set of configuration information that
> tells it where to pull its disks from.
>
> It would be good to be able to migrate guests from one host to another
> without needing to tweak the guest's configuration. A node-independent
> view of the AoE domain is quite useful in this situation -- i can say
> "guest X has /dev/etherd/e4.3 as a virtual block device" and not have to
> worry about whether guest X happens to be running on the host
> responsible for exporting (shelf=4,slot=3).
Heh, now I see why you haven't been concerned with partitions at all.
:-)
So, you are abstracting away the underlying mechanism that is used to
access the block device. I would rather put this abstraction into the
logic/configuration for management of the VM instances.
I suggest the following changes:
- Don't let vblade-persist create the symlinks by default.
- Add an option so the administrator can explicitly specify a symlink
location. (This should be trivial by setting an environment variable.)
If you want, I'll provide a patch.
If you document the change in NEWS.Debian, there should be no surprises.
Cheers,
-Hilko
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
