[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] SHUTDOWN_crash and vcpu deferrals



John Levon writes ("Re: [Xen-devel] SHUTDOWN_crash and vcpu deferrals"):
>         # ideally we would like to forcibly crash the domain with
>         # something like
>         #    xc.domain_shutdown(self.vm.getDomid(), DOMAIN_CRASH)
>         # but this can easily lead to very rapid restart loops against
>         # which we currently have no protection
> 
> (The comment being completely incorrect), but then the crash doesn't
> work because of the bug I pointed out.

I wrote that comment.  I haven't been following this bit of xend.  Do
you mean that nowadays if you say
   on_crash = 'restart'
and the domain immediately crashes on boot, you don't get an infinite
restart loop ?  One of the most common causes of qemu `crashing' is
that it wasn't able to open the dom0 device corresponding to some
emulated device for the guest's benefit and that obviously happens at
startup.

> All I want to do is mark a domain without a qemu process as crashed. Is
> that clearer?

I think that would be good, provided that we can prevent it restarting
rapidly.

> And yes, it's pretty trivial to make qemu break. Most typically by
> passing bogus parameters (say, a broken kernel image, an incorrect NIC,
> etc.)

As you say.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.