Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them
On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote: > On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote: > > > > > Could the domain ID be used for that? > > > > I don't like it because it only says how recent a domain was > > started relative to others, not any intention about start/stop > > order. Shut one down manually (or crash) and start it again and it > > gets a new domid higher than all existing. > > It is a (really) simple heuristic and likely too simple. > But at first glance it seemed (to me) to actually do the right thing. It is *definitely* too simple to do a good job; however, this has the advantages of being a significant improvement and simple enough to be in service quickly. On Wed, Sep 29, 2021 at 01:24:58AM +0200, Diederik de Haas wrote: > On Wednesday, 29 September 2021 00:02:46 CEST Andy Smith wrote: > > On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote: > > The idea of the domid controlling/influencing order of shutdown > > It was just an idea that popped in my head. All in all I've likely spend less > then a minute thinking about the domid idea. > Don't spend more on it then you already have ;) The record shows I suggested it first: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452721#35 This isn't an adaquate solution, but is a distinct improvement. > > > I really agree with the 'upstream' tag as not only should it be > > > fixed/adjusted there, but it also engages a (much) larger audience who > > > think of scenarios we likely didn't think about. > > > > Should we move discussion to xen-us...@lists.xen.org then? > > I can make a case for both xen-users and xen-devel. > xen-users: > It could be that a solution already exists. I know that in Qubes (which uses > Xen) has some dependency mechanism in that if you start vmA which depends on > vmB, then it first starts vmB and then vmA. I don't know if that is a Qubes > 'extension' or that they simply use available functionality of Xen. Could be interesting to learn of what solutions are already out there and what features are must have. Most existing solutions likely have problems. Some may be GPL-incompatible. Most are likely very limited. > xen-devel: > If needed functionality doesn't yet exist and needs to be built anew, then > xen-devel is the right place to discuss that. > > It could be that the best place to start is xen-users which then may/could > 'transition' to xen-devel. > > Let's hear others first what they think is the best approach. Perhaps. Question is how much person-time is available for this? If a great deal of xen-devel person-time can be devoted to this a very ambitious solution might be viable. If only a little bit of xen-devel person-time is available, the approach would need to be very limited. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them
Hi Andy, On Wednesday, 29 September 2021 00:02:46 CEST Andy Smith wrote: > On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote: > The idea of the domid controlling/influencing order of shutdown It was just an idea that popped in my head. All in all I've likely spend less then a minute thinking about the domid idea. Don't spend more on it then you already have ;) > > I really agree with the 'upstream' tag as not only should it be > > fixed/adjusted there, but it also engages a (much) larger audience who > > think of scenarios we likely didn't think about. > > Should we move discussion to xen-us...@lists.xen.org then? I can make a case for both xen-users and xen-devel. xen-users: It could be that a solution already exists. I know that in Qubes (which uses Xen) has some dependency mechanism in that if you start vmA which depends on vmB, then it first starts vmB and then vmA. I don't know if that is a Qubes 'extension' or that they simply use available functionality of Xen. xen-devel: If needed functionality doesn't yet exist and needs to be built anew, then xen-devel is the right place to discuss that. It could be that the best place to start is xen-users which then may/could 'transition' to xen-devel. Let's hear others first what they think is the best approach. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them
Hi Diederik, On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote: > On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote: > > We agree about reverse order, I think we only disagree about when to > > shut down domains that don't have a preference set. > > Indeed. Okay, well I am satisfied by the lesser idea of having to specify order of all domains but if the implementer of the solution isn't and decides to implement it so not-specified domains shut down first then that works for me too so have no objection to it. The idea of the domid controlling/influencing order of shutdown would not work for me as to me that is not much different to how we have things now - domains shut down in increasing order of domid. I can't control it so I just would continue using my own shutdown script. > I really agree with the 'upstream' tag as not only should it be > fixed/adjusted > there, but it also engages a (much) larger audience who think of scenarios we > likely didn't think about. Should we move discussion to xen-us...@lists.xen.org then? Cheers, Andy
Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them
Hi Andy, On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote: > > If that's correct, then I find it more logical to do *everything* in > > reverse. The VM that was started first, should be saved/shutdown last and > > IIUC your proposal would not do that. > > No, that's what I am suggesting too: again walk the "auto" directory > but in reverse order. I understood that. My point was about the sequence of auto vs non-auto > > Once all the "remaining" ones have been saved/shutdown, THEN do > > the auto ones in reverse order. > > A problem here would be excluding the domains that have a specified > order from the initial round of shutdowns That may involve some scripting/programming, but *I* don't consider that a valid argument to not do it... > which is why I suggested doing it in reverse order by the "auto" directory > and THEN shutting down anything that's left as normal, since that way you > don't need to check anything. ... and I think that's wrong. The use case I'm imagining is some domains are important or even essential for the working of other domains and that's why you want/need to start them as soon as possible with (potentially) a dependence between them, therefor you specify the correct order in the auto directory. Let's say you have a special storage domain which provides storage for all the domU domains. Without that domain running you CANNOT start any other domain, so you start that domain first in the auto directory. If you start the shutdown/save-all-domains procedure the storage domain MUST be the last one to be shutdown, because otherwise you'd pulling the storage under live domains, which likely will make them crash. In any case, they will not be able to shutdown cleanly or save their current state to disk ... because the disks are gone. > As you've pointed out, this does mean that if you had linked say > /etc/xen/auto/010-important.cfg with the intention that it be > started first and shut down last, you would have to also link in > every other domain in its correct order otherwise the not-mentioned > ones would be shut down after 010-important. Indeed. I hope that I explained sufficiently why that is wrong or can even be catastrophic AFAICT. > However, I feel like people who use the /etc/xen/auto directory do > already link all or the majority of their domains in there I think that that is a (too) dangerous assumption. You could use (say) 3 domains which provide essential services to all other domains, but after that every user is free to do whatever (s)he wants. > - I certainly do. I don't find it onerous to say that if you want to > specify shutdown order then you must link all of the domains in > /etc/xen/auto not just some of them. That would make the scenario I described above unworkable or needlessly complex, so I don't think that's a good/valid solution. > > Could the domain ID be used for that? > > I don't like it because it only says how recent a domain was > started relative to others, not any intention about start/stop > order. Shut one down manually (or crash) and start it again and it > gets a new domid higher than all existing. It is a (really) simple heuristic and likely too simple. But at first glance it seemed (to me) to actually do the right thing. > We agree about reverse order, I think we only disagree about when to > shut down domains that don't have a preference set. Indeed. > I am all for keeping it simple by saying ordering must be set for all > domains otherwise ordering for remaining ones is not defined. I like simple too, but I think this actually makes it complex. I really agree with the 'upstream' tag as not only should it be fixed/adjusted there, but it also engages a (much) larger audience who think of scenarios we likely didn't think about. And they're certainly much more knowledgeable then I am. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them
Hi Diederik,
On Tue, Sep 28, 2021 at 11:45:08AM +0200, Diederik de Haas wrote:
> On Monday, 27 September 2021 19:13:04 CEST Andy Smith wrote:
> > I think the "auto" directory is a pretty good and simple interface,
> > so how about using it for save/shutdown as well? So, instead of just
> > enumerating all running domids, enumerate all files in
> > /etc/xen/auto/ in REVERSE order, parsing the name of the domain out
> > of each one and doing the action on that name. When all files have
> > been exhausted, THEN do the action on any remaining running domains.
>
> I'm not familiar with the "auto" directory('s functionality), but I _assume_
> that it's a directory which contains Xen domain config files which are
> automatically started up at boot time (in alphabetical sequence).
> The user can choose to start other VMs if (s)he so chooses.
Yes; you typically symlink for example /etc/xen/foo.cfg to
/etc/xen/auto/100-foo.cfg so as to enforce some order of automatic startup.
Currently shutdown just goes in order of running domain id though.
> If that's correct, then I find it more logical to do *everything* in reverse.
> The VM that was started first, should be saved/shutdown last and IIUC your
> proposal would not do that.
No, that's what I am suggesting too: again walk the "auto" directory
but in reverse order.
> Once all the "remaining" ones have been saved/shutdown, THEN do
> the auto ones in reverse order.
A problem here would be excluding the domains that have a specified
order from the initial round of shutdowns, which is why I suggested
doing it in reverse order by the "auto" directory and THEN shutting
down anything that's left as normal, since that way you don't need
to check anything.
As you've pointed out, this does mean that if you had linked say
/etc/xen/auto/010-important.cfg with the intention that it be
started first and shut down last, you would have to also link in
every other domain in its correct order otherwise the not-mentioned
ones would be shut down after 010-important.
However, I feel like people who use the /etc/xen/auto directory do
already link all or the majority of their domains in there - I
certainly do. I don't find it onerous to say that if you want to
specify shutdown order then you must link all of the domains in
/etc/xen/auto not just some of them.
Otherwise, if you wanted to say that all non-mentioned domains must
be shutdown first then I guess you'd have to parse the list of
domain names from the "suto" directory first, then get the list of
running domains from /usr/lib/xen-common/bin/xen-init-list and
exclude one from the other for the initial round of shutdowns.
> Could the domain ID be used for that?
I don't like it because it only says how recent a domain was
started relative to others, not any intention about start/stop
order. Shut one down manually (or crash) and start it again and it
gets a new domid higher than all existing.
> But my main point is that I think the proposed sequence should be adjusted.
We agree about reverse order, I think we only disagree about when to
shut down domains that don't have a preference set. I am all for
keeping it simple by saying ordering must be set for all domains
otherwise ordering for remaining ones is not defined.
Cheers,
Andy
Bug#452721: [Pkg-xen-devel] Bug#452721: "xendomains" does not restore domains in same order as it would start them
On Monday, 27 September 2021 19:13:04 CEST Andy Smith wrote:
> I think the "auto" directory is a pretty good and simple interface,
> so how about using it for save/shutdown as well? So, instead of just
> enumerating all running domids, enumerate all files in
> /etc/xen/auto/ in REVERSE order, parsing the name of the domain out
> of each one and doing the action on that name. When all files have
> been exhausted, THEN do the action on any remaining running domains.
I'm not familiar with the "auto" directory('s functionality), but I _assume_
that it's a directory which contains Xen domain config files which are
automatically started up at boot time (in alphabetical sequence).
The user can choose to start other VMs if (s)he so chooses.
If that's correct, then I find it more logical to do *everything* in reverse.
The VM that was started first, should be saved/shutdown last and IIUC your
proposal would not do that.
What makes the most sense to me is that the last started VM should be saved/
shutdown first, which would be one of the "remaining running domains". Once all
the "remaining" ones have been saved/shutdown, THEN do the auto ones in
reverse order.
Could the domain ID be used for that?
I haven't studied it 'in detail', but they seem sequential.
But my main point is that I think the proposed sequence should be adjusted.
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
