[Pkg-xen-devel] Bug#452721: Bug#452721: "xendomains" does not restore domains in same order as it would start them

[Diederik de Haas]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20210928/c8c56d34/attachment.sig>