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