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?
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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"