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

RE: [Xen-devel] determining if a backend device is not working


  • To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Tue, 10 Mar 2009 20:21:19 +1100
  • Cc:
  • Delivery-date: Tue, 10 Mar 2009 02:21:49 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcmhIgybbc5MxlDyS1KuqiEOxhybGAAN3qkJAAHVfyA=
  • Thread-topic: [Xen-devel] determining if a backend device is not working

> On 10/03/2009 01:46, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
wrote:
> 
> > In my gplpv drivers, the best I have come up with to determine if
the
> > backend is not working is to wait for a few seconds (30 currently),
and
> > if the backend state hasn't changed by then then I assume that it's
> > broken.
> >
> > Is there a better way? The situation where this comes up is when
> > something like ',hdc:cdrom,r' is specified in the config file.
> >
> > Even though I set all of the frontend up, the backend just stays at
> > state 2 instead of transitioning to 4.
> 
> I think we expect backends to always be responsive. So we have no
model
> for
> what to do if that assumption breaks. Your particular example above
sounds
> like a weird backend bug?
> 

A block device definition of ',hdc:cdrom,r' appears to be valid on the
qemu side of things. You just 'xm block-configure' it when you want to
'insert' a cdrom image into it.

Blkback appears to not handle such things though, so it would have been
nice to quickly detect that blkback wasn't doing anything useful and
just move on...

Oh well.

James

_______________________________________________
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®.