From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan de Konink Subject: Re: Re: [PATCH] qemu-xen: Fix PV segfault Date: Wed, 02 Jul 2008 17:28:45 +0200 Message-ID: <486B9EAD.4090009@xs4all.nl> References: <4863E1F6.60909@suse.de> <18538.27111.959001.890654@mariner.uk.xensource.com> <486B3428.5000006@suse.de> <486B3E88.1020904@redhat.com> <20080702141917.GD23929@totally.trollied.org.uk> <18539.37231.372982.478747@mariner.uk.xensource.com> <20080702143813.GG23929@totally.trollied.org.uk> <18539.38311.54023.618715@mariner.uk.xensource.com> <486B97D9.1010305@xs4all.nl> <18539.39783.262893.291098@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18539.39783.262893.291098@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: John Levon , xen-devel@lists.xensource.com, Gerd Hoffmann , Kevin Wolf , Samuel Thibault List-Id: xen-devel@lists.xenproject.org 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