On 31 Jul 2023 03:39, Elliott Mitchell wrote:
Presently I hope to convince the Xen core to allow full Python in domain
configuration files, but no news on that front so far. This would mean
/etc/default/xendomains would need to change to match Python syntax.
There was an answer today on xen-devel: the ability to use scripts in
domU cfg files has been explicitely removed for various reasons.
This does not prevent you from "source"-ing teh cfg files in your
script(s) if they are proper Python syntax. Or you could simply
parse/regex the values you want.
And as Marek suggested in his answer, you can also put any arbitrary
settings in the comments.
Although ...
My thinking for adding to domain configuration files would be something
along these lines:
init = {
'tool': 'xendomains-ng',
'version': 0,
'order': 9,
'startwait': 60,
'stopaction': 'save',
}
The problem with adding this to a domU config file is that it could
cause problems for (live) migrations. The start/stop order is "per
dom0", and may be different on another one.
Imagine two dom0s, one storing the domain files "locally", while the
other uses NFS. Only in the second case the domU should wait for the NFS
server/domain to be available.
To me, the start/stop logic should be in a dom0 config file.
'startwait' would tell the script to wait that long before starting
subsquent domains.
A time-based wait may be useful for when everything goes well, but what
about when there are problems ?
If you want to be sure a domain is up (ie. ready to serve), you would
need to peek at the related "service".
For example, to be sure a DNS domU is up, you would have to try a DNS
request, as a ping or "xl list" would not be enough.
Also, domains in xen/auto are started with a mix of serialization AND
parallelization, as "xl create" returns once the domain has started (ie.
in the Xen point of view, not the user's).
'stopaction' would allow different actions if the machine was to stop.
The 3 options which come to mind are 'stop' (shutdown), 'save' (save to
specified storage location), and 'migrate'.
Then, each time you do NOT want to follow the usual action, you'd have
to edit -each- domU cfg file ?
If full Python doesn't become available, this might take the format:
init = 'tool=xendomains-ng,version=0,order=9,startwait=60,stopaction=save'
Not needing to parse the string though does make one's life simpler.
Well, it makes -your- life easier, not the maintainers' one ;)
I'm basically certain writing a new xendomains script in Python is the
way to go. Now to get an answer as to whether full Python in domain
configuration files could be reenabled.
I'm not sure a Python script would solve anything, as (ba)sh variables
are imported from other files.
(see for example
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/tools/hotplug/Linux/xendomains.in)
Everything considered, I'm not sure why Xen should provide such
functionnality.
I think custom scripts can handle all the various use cases, don't you
think ?
PS: as mentionned by diederik, the "dependency" logic is already handled
by Qubes since years, and it never made it to Xen (I don't know the
reasons though).
But I agree the shutdown sequence could be adapted to :
1. first shutdown the domains NOT in xen/auto
2. then shutdown the domains in xen/auto, in reverse order
For fine grained start/stop order, maybe having a dom0 config file
handling this could be added, like:
# START/STOP ORDER
# domains not in these lists will be started after and stopped
# before the ones here
start-order=(list of domU names)
stop-order=(list of domU names)
But then again, this only ensures "domains" start order, not "services
availability" in said domains.
--
zithro / Cyril
