Porting the block-iscsi hotplug script

[Gustau Pérez]

El 4/03/16 a les 16:54, Roger Pau Monné ha escrit:
> On Fri, 4 Mar 2016, Gustau Pérez wrote:
>> El 4/03/16 a les 11:00, Roger Pau Monné ha escrit:
>>> What other parameters do you want to pass to your script that cannot be 
>>> fetched from xenstore? IMHO I was planning to only pass the xenstore 
>>> backend node and the action.
>>    The action (if I understand it correctly) is already there.
> Yes, the xenstore backend path is $1 and the action $2.
>
>>    OTOH, I'd like to check if the disks are already in use, and so I'd
>> need to walk the /local/domain/0/backend/vbd/$domin/$devid/ looking if
>> the disks are already there. This arises two questions:
>>
>>   * can I assume the domain0 store would always be /local/domain/0/?
> Hm, I wouldn't be on it. This is true in the most common scenario, where 
> Dom0 (domain with id 0) runs all the backends. But if you are using a 
> driver domain or a radically disagregated system (where control domain != 
> hardware domain) this is no longer true. So in general you shouldn't make 
> this assumption.
>
>>   * would I need to walk for each $domid checking for each $devid and
>>     getting the physical device?

   Hi,

   today I had some time to work a bit the script. I managed to have
something that works with plain 'sh' and seems to do its job. I need to
split the script (for example, the xenstore_[read|write] functions can
be used by other scripts) and I also need to tackle the locking
functions, which are not 'sh' compliant.

   If you want I can post it somewhere. I make the assumption that
domain0 can also be the dom0 domain. As you previously stated, in
general this assumption should hold; given the fact that the domain ids
are given sequentially in the worst case the dom0 would be > 0. This is
used when checking if the disk is already in use, that way we can return
the domid of the domain already using the device or 0 if the device can
be used.

   Thank you,

   Gustau