Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 01/24/2011 05:40 PM, Anthony Liguori wrote:
> On 01/24/2011 04:48 PM, Richard W.M. Jones wrote:
>> On Mon, Jan 24, 2011 at 04:26:09PM -0600, Anthony Liguori wrote:
>>> On 01/24/2011 04:20 PM, Richard W.M. Jones wrote:
>>>> On Mon, Jan 24, 2011 at 10:08:09PM +0000, Richard W.M. Jones wrote:
>>>>> You might as well reuse the libguestfs API here because you get the
>>>>> benefit of all the code that's been written, all the tools on top, and
>>>>> a far more comprehensive API that would take you another 2 years to
>>>>> implement.
>>>> To put it in some perspective, libguestfs is just shy of 500K lines of
>>>> code now, not including the tools built on top. 150 page manual just
>>>> for the core API.
>>> Yeah, but I think that's the reason that it might not be a good
>>> candidate for this use-case.
>>>
>>> We need a *simple* interface that we can convince everyone to
>>> install by default and run in their guests. It needs to be flexible
>>> enough that we can do lots of fun things but simple enough that a
>>> reasonable person can audit the code in a short period of time.
>>>
>>> It will never replace something as sophisticated as guestfs but
>>> that's not it's point. It's point is to let you do simple things
>>> like execute a command in the guest or peek at /proc/meminfo. You
>>> don't need 500k LOCs for that.
>> I don't really want to argue over this, since I think accessing live
>> VMs like this is a really useful feature, and it complements
>> libguestfs (image editing) very nicely.
>>
>> I'll just say that you might not think you need it to start off with
>> (and we didn't either), but when you notice that "simple"
>> open/read/write/close
>
> Oh I don't think there should be an open/read/write/close interface. I'm
> quite happy with the current copyfile interface.

Actually, copyfile is the proposed open/read/write/close interface. 
getfile is the current interface, and it seems to be a contentious one. 
I've discussed it quite a bit with Jes here and in the last couple RFCs. 
I think the current course is that we'll end up ditching 
viewfile/viewdmesg in favor of copyfile, and that we should do it now 
rather than later.

The upshot is that "viewfile <remote>" is basically equivalent to:
copyfile_open <remote> /dev/stdout -> fd_handle;
copyfile_read fd <offset=0> <count=<MAX_CHUNK_SIZE>;
copyfile_close fd_handle".

Or we can output to a file and potentially introduce a monitor command 
that wraps these to provide simple oneliner like we have now, though 
there may be some reluctance there as well. But at least it'll be 
possible either way.

>
>> in fact has terrible performance so you need to
>> specialize many operations, and then someone wants to create a
>> filesystem, and someone else wants a FUSE interface, suddenly you'll
>> be reimplementing large parts of libguestfs.
>
> Nope. If you want to do fancy things, use libguestfs :-)
>
> 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.
>
> Regards,
>
> Anthony Liguori
>
>> The daemon (guestfsd) is 36106 LoC.
>>
>> Rich.
>>
>