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

Re: [Xen-devel] Re: [PATCH] qemu-xen: Fix PV segfault



Ian Jackson schreef:
Stefan de Konink writes ("Re: [Xen-devel] Re: [PATCH] qemu-xen: Fix PV 
segfault"):
But this isn't the case now at all, is it? I name xenstored; is the move that Samuel with minios takes a way to solve this?

xenstored is not critical to the run-time operation of PV domains.
Without it you can't boot, add devices, etc. etc.  But you can (for
example) shut down a PV domain cleanly.

So the actual 'problem' is the storage of the domain properties, preferably in a 'process' that is not running, but an API that can query it. I think Libvirtd fails on that point too, everything gets fubar, once a daemon breaks. The reason for a running daemon providing domain specific information is not clear for me, storing it on disk will always give better recovery possibilities.

In any case, if anyone suggests that userspace processes are bad and fragile, then these persons will not like any processes that support hardware emulation, such as tapdisk.

You're quite right.

If tapdisk is a problem, then I'm happy to point at the breakage that will occur with loopback devices (NFS + loopback + highio = boom). But it is really interesting people talk about 'user-processes' as if they are broken by default. I disagree, even if a iscsi setup for each used disk a kernel process is running. So one way or the other, dom0 is needed to provide access to storage one way or the other. Migrating the 'storage providers' to DomS would be an interesting idea, but the need for it, I don't quite see.


Stefan

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