From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754838Ab0CVOUL (ORCPT ); Mon, 22 Mar 2010 10:20:11 -0400 Received: from 8bytes.org ([88.198.83.132]:37341 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754693Ab0CVOUJ (ORCPT ); Mon, 22 Mar 2010 10:20:09 -0400 Date: Mon, 22 Mar 2010 15:20:08 +0100 From: oerg Roedel To: "Richard W.M. Jones" Cc: "Daniel P. Berrange" , Ingo Molnar , Pekka Enberg , Avi Kivity , Antoine Martin , Olivier Galibert , Anthony Liguori , "Zhang, Yanmin" , Peter Zijlstra , Sheng Yang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Marcelo Tosatti , Jes Sorensen , Gleb Natapov , Zachary Amsden , ziteng.huang@intel.com, Arnaldo Carvalho de Melo , Fr?d?ric Weisbecker Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single project Message-ID: <20100322142008.GE1940@8bytes.org> References: <4BA68234.1060804@nagafix.co.uk> <4BA68997.60406@redhat.com> <20100321212009.GE30194@elte.hu> <4BA70F9A.8030304@redhat.com> <20100322114824.GF3483@elte.hu> <84144f021003220531p391975f2p5a2e0cfd3a2af6d@mail.gmail.com> <20100322123726.GH21874@redhat.com> <20100322125440.GB12475@elte.hu> <20100322130513.GJ21874@redhat.com> <20100322132326.GA15923@amd.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100322132326.GA15923@amd.home.annexia.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 22, 2010 at 01:23:26PM +0000, Richard W.M. Jones wrote: > On Mon, Mar 22, 2010 at 01:05:13PM +0000, Daniel P. Berrange wrote: > > This is close to the way libguestfs already works. It boots QEMU/KVM pointing > > to a minimal stripped down appliance linux OS image, containing a small agent > > it talks to over some form of vmchannel/serial/virtio-serial device. Thus the > > kernel in the appliance it runs is the only thing that needs to know about the > > filesystem/lvm/dm on-disk formats - libguestfs definitely does not want to be > > duplicating this detailed knowledge of on disk format itself. It is doing > > full read-write access to the guest filesystem in offline mode - one of the > > major use cases is disaster recovery from a unbootable guest OS image. > > As Dan said, the 'daemon' part is separate and could be run as a > standard part of a guest install, talking over vmchannel to the host. > The only real issue I can see is adding access control to the daemon > (currently it doesn't need it and doesn't do any). Doing it this way > you'd be leveraging the ~250,000 lines of existing libguestfs code, > bindings in multiple languages, tools etc. I think we don't need per-guest-file access control. Probably we could apply the image-file permissions to all guestfs files. This would cover the usecases: * perf for reading symbol information (needs ro-access only anyway) * Desktop like host<->guest file copy I have not looked into libguestfs yet but I guess this approach is easier to achieve. Joerg