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

[Elliott Mitchell]

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-users at 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+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445