[libvirt] [RFC PATCH] Use PAUSED state for domains that are starting up

[Jiri Denemark]

On Thu, Feb 19, 2015 at 16:09:55 +0000, Daniel P. Berrange wrote:
> On Thu, Feb 19, 2015 at 05:07:45PM +0100, Jiri Denemark wrote:
> > On Mon, Feb 16, 2015 at 15:07:19 +0000, Daniel P. Berrange wrote:
> > > On Mon, Feb 16, 2015 at 04:03:50PM +0100, Jiri Denemark wrote:
> > > > On Mon, Feb 16, 2015 at 14:57:17 +0000, Daniel P. Berrange wrote:
> > > > > On Mon, Feb 16, 2015 at 03:50:41PM +0100, Jiri Denemark wrote:
> > > > > > When libvirt is starting a domain, it reports the state as SHUTOFF until
> > > > > > it's RUNNING. This is not ideal because domain startup may take a long
> > > > > > time (usually because of some configuration issues, firewalls blocking
> > > > > > access to network disks, etc.) and domain lists provided by libvirt look
> > > > > > awkward. One can see weird shutoff domains with IDs in a list of active
> > > > > > domains or even shutoff transient domains. In any case, it looks more
> > > > > > like a bug in libvirt than a normal state a domain goes through.
> > > > > 
> > > > > A shutoff transient domain isn't too bad IMHO, but a shutoff domain
> > > > > with an ID number is definitely not expected.
> > > > > 
> > > > > Could we perhaps address it by ensuring that we always return '-1'
> > > > > for ID if the state is "SHUTOFF", even if def->id has a positive
> > > > > value ?
> > > > 
> > > > But we should somehow make it clear that the domain is actually there,
> > > > somehow, only not completely usable. That is, one may need to actually
> > > > call virsh destroy on such domain to get rid of the leftover process if
> > > > something goes wrong.
> > > 
> > > Hmm, if something goes wrong due virDomainStart though, we should be
> > > tearing down the QEMU process. IIRC we should even be kill -9'ing QEMU,
> > > so even if QEMU is stuck in an uninterruptable sleep and won't exit,
> > > once the (storage?) problem causing that sleep is resolved QEMU will
> > > exit without further intervention. Similarly calling 'destroy' more
> > > times won't make it any more likely to quit, once it has had a SIGKILL
> > 
> > You're right of course. However, I still feel we should distinguish
> > shutoff domain from a domain that is being started. Considering it
> > shutoff until we have a monitor connection may cause all sorts of
> > confusion. Except for shutoff transient domains, one can see a shutoff
> > domain that cannot be started because it is already running (or perhaps
> > because acquiring a job fails), it's impossible to distinguish between a
> > domain which was running previously and wasn't cleaned up for whatever
> > reason (bug in libvirt most likely) from a normal state when libvirt is
> > waiting for a monitor to show up...
> 
> It kind of feels like it merits a new state, but I fear that would cause
> more problems for existing apps which won't be expecting it. So perhaps
> using 'paused' during startup is the least worst option ?

Exactly, and that's basically what I did in the patch we are discussing
:-)

Jirka