From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bALzY-0001VE-9D for qemu-devel@nongnu.org; Tue, 07 Jun 2016 14:44:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bALzT-00064y-6C for qemu-devel@nongnu.org; Tue, 07 Jun 2016 14:44:44 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:63725 helo=mx0b-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bALzS-00061W-UZ for qemu-devel@nongnu.org; Tue, 07 Jun 2016 14:44:39 -0400 Received: from pps.filterd (m0082756.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u57IgHnq037910 for ; Tue, 7 Jun 2016 14:44:32 -0400 Received: from e06smtp08.uk.ibm.com (e06smtp08.uk.ibm.com [195.75.94.104]) by mx0a-001b2d01.pphosted.com with ESMTP id 23e38a9df4-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 07 Jun 2016 14:44:32 -0400 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Jun 2016 19:44:29 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1FE882190046 for ; Tue, 7 Jun 2016 19:43:50 +0100 (BST) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u57IiH0R24183198 for ; Tue, 7 Jun 2016 18:44:17 GMT Received: from d06av09.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u57IiHDm029869 for ; Tue, 7 Jun 2016 12:44:17 -0600 From: Sascha Silbe In-Reply-To: <20160603083418.GB13827@redhat.com> References: <1464712247-11655-1-git-send-email-wexu@redhat.com> <20160531164448.GE21628@redhat.com> <574F0A7B.5030401@redhat.com> <01045d4a-f03d-9f0d-deeb-4927446bb894@redhat.com> <20160602082904.GD9481@redhat.com> <201606021927.u52JB3YU031760@mx0a-001b2d01.pphosted.com> <20160603083418.GB13827@redhat.com> Date: Tue, 07 Jun 2016 20:44:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <87inxkhm9q.fsf@oc4731375738.ibm.com> Subject: Re: [Qemu-devel] Channel paths List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Michal Privoznik , jasowang@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, Wei Xu , amit.shah@redhat.com, libvir-list@redhat.com Dear Daniel, [CC +=3D libvir-list, didn't notice before this thread is on qemu-devel only] "Daniel P. Berrange" writes: > On Thu, Jun 02, 2016 at 09:27:45PM +0200, Sascha Silbe wrote: >> Since 71408079 [qemu: Don't bother user with libvirt-internal paths], >> the path chosen by libvirt isn't included in the domain XML anymore. So >> now I need to choose the path inside the application. The only safe way >> to do that is by using something in an application-managed namespace >> (e.g. /var/lib/myapp/foo or /tmp/myapp/foo); I certainly wouldn't want >> to second guess what paths would be safe inside the libvirt namespace >> (/var/lib/libvirt/qemu). Except now I hear that anything outside >> /var/lib/libvirt/qemu is not guaranteed to work due to e.g. the SELinux >> policy configured by libvirt... > > IIUC that change 71408079 ought to only apply to the persistent XML > configuration on disk. When the guest is running the live XML ought > to still report the path libvirt chose, so you should still be able > to see it while running. If that isn't the case then please raise a > bug, because we certainly expect apps to be able to discover the > path libvirt picked for exactly the reason you describe OK, this makes a lot more sense now (persistent vs. live). Just tried it with current libvirt master and it works, thanks. It even worked with 71408079 itself. I'm pretty sure things were broken some time in between, but a few quick probes didn't turn up a faulty version and I'm not curious enough to do a linear search. Cannot completely rule out other effects having played a role, either. Sascha --=20 Softwareentwicklung Sascha Silbe, Niederhofenstra=C3=9Fe 5/1, 71229 Leonberg https://se-silbe.de/ USt-IdNr. DE281696641