From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43521 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phkov-0003vm-Ui for qemu-devel@nongnu.org; Tue, 25 Jan 2011 10:28:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Phkou-0006GO-D9 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 10:28:37 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:43731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Phkou-0006G8-Am for qemu-devel@nongnu.org; Tue, 25 Jan 2011 10:28:36 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0PFAwXL023900 for ; Tue, 25 Jan 2011 10:10:58 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id E3D28729AFB for ; Tue, 25 Jan 2011 10:12:41 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0PFCfLN182440 for ; Tue, 25 Jan 2011 10:12:41 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0PFCecV005455 for ; Tue, 25 Jan 2011 13:12:41 -0200 Message-ID: <4D3EE84F.60701@linux.vnet.ibm.com> Date: Tue, 25 Jan 2011 09:12:15 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <1295270117-24760-9-git-send-email-mdroth@linux.vnet.ibm.com> <4D39B716.1010400@redhat.com> <20110121172026.GK12589@redhat.com> <4D39CF2C.1000407@linux.vnet.ibm.com> <20110124220809.GA4254@amd.home.annexia.org> <20110124222019.GA4602@amd.home.annexia.org> <4D3DFC81.4010807@linux.vnet.ibm.com> <20110124224808.GF25174@amd.home.annexia.org> <4D3E0DD5.8070408@linux.vnet.ibm.com> <20110125092113.GG25174@amd.home.annexia.org> In-Reply-To: <20110125092113.GG25174@amd.home.annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, Jes Sorensen , marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org, Michael Roth , ryanh@us.ibm.com, markus_mueller@de.ibm.com, abeekhof@redhat.com On 01/25/2011 03:21 AM, Richard W.M. Jones wrote: > On Mon, Jan 24, 2011 at 05:40:05PM -0600, Anthony Liguori wrote: > >> BTW, how dependent is guestfsd on the guest that libguestfs uses? I >> wasn't even aware that it could be used outside of that context. >> > The daemon is compiled separately -- separate ./configure, make, etc. > You can run it on its own. > > On the other hand, it does need to talk to something on the other end > of the virtio-serial guestfsd socket, and that other thing would > usually be the libguestfs library ... > > One thing that Dan Berrange did was to patch[1] libguestfs so it could > talk to any existing guestfsd (you pointed it at a Unix domain > socket). He was using this to write test regression tests for > 'virt-install': ie. install a guest, put guestfsd inside it, then boot > up the guest and check that everything was installed correctly by > querying it from an external libguestfs. > > For various unrelated reasons these patches weren't quite ready to go > upstream, but it's on our ROADMAP[2] to add something like this. > > In which case what you would do would be: > > (a) put guestfsd into existing guests > How much infrastructure does guestfd depend on within the guest? Do you need a full install with all of the bells and whistles or does it degrade cleanly when certain tools aren't available? Regards, Anthony Liguori > (b) add a nice option to guestfish to attach to existing VMs, eg: > > guestfish --attach Fedora14 > [guestfish live attached to Fedora 14's virtio-serial guestfsd socket] > > copy-in ./dirs /tmp/ > > "copy-in" would be dangerous currently if used on a live VM, but > in this case it would be quite safe > > (c) do the work of porting guestfsd to Windows, FreeBSD etc > > Rich. > > [1] https://www.redhat.com/archives/libguestfs/2010-July/msg00010.html > refined a bit more later on. > > [2] http://libguestfs.org/ROADMAP.txt > "* Allow alternate methods to start the appliance, including through > libvirt and by connecting to an existing appliance. This was > originally planned for 1.8 but we didn't get patches in time." > >