lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100322135647.GA14201@elte.hu>
Date:	Mon, 22 Mar 2010 14:56:47 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Daniel P. Berrange" <berrange@...hat.com>,
	Richard Jones <rjones@...hat.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>, Avi Kivity <avi@...hat.com>,
	Antoine Martin <antoine@...afix.co.uk>,
	Olivier Galibert <galibert@...ox.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project


* Daniel P. Berrange <berrange@...hat.com> wrote:

> On Mon, Mar 22, 2010 at 01:54:40PM +0100, Ingo Molnar wrote:
> > 
> > * Daniel P. Berrange <berrange@...hat.com> wrote:
> > > 
> > > FYI, for offline guests, you can use libguestfs[1] to access & change files 
> > > inside the guest, and read-only access to running guests files. It provides 
> > > access via a interactive shell, APIs in all major languages, and also has a 
> > > FUSE mdule to expose it directly in the host VFS.  It could probably be made 
> > > to work read-write for running guests too if its agent were installed inside 
> > > the guest & leverage the new Virtio-Serial channel for comms (avoiding any 
> > > network setup requirements).
> > > 
> > > Regards,
> > > Daniel
> > > 
> > > [1] http://libguestfs.org/
> > 
> > Yes, this is the kind of functionality i'm suggesting.
> > 
> > I'd suggest a different implementation for live guests: to drive this from 
> > within the live guest side of KVM, i.e. basically a paravirt driver for 
> > guestfs. You'd pass file API guests to the guest directly, via the KVM ioctl 
> > or so - and get responses from the guest.
> > 
> > That will give true read-write access and completely coherent (and still 
> > transparent) VFS integration, with no host-side knowledge needed for the 
> > guest's low level (raw) filesystem structure. That's a big advantage.
> > 
> > Yes, it needs an 'aware' guest kernel - but that is a one-off transition 
> > overhead whose cost is zero in the long run. (i.e. all KVM kernels beyond a 
> > given version would have this ability - otherwise it's guest side distribution 
> > transparent)
> > 
> > Even 'offline' read-only access could be implemented by booting a minimal 
> > kernel via qemu -kernel and using a 'ro' boot option. That way you could 
> > eliminate all lowlevel filesystem knowledge from libguestfs. You could run 
> > ext4 or btrfs guest filesystems and FAT ones as well - with no restriction.
> > 
> > This would allow 'offline' access to Windows images as well: a FAT or ntfs 
> > enabled mini-kernel could be booted in read-only mode.
> 
> This is close to the way libguestfs already works. [...]

[ Oops, you are right - sorry for not looking more closely! I was confused by
  the 'read only' aspect. ]

> [...] 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.

Just curious: any plans to extend this to include live read/write access as 
well?

I.e. to have the 'agent' (guestfsd) running universally, so that tools such as 
perf and by users could rely on the VFS integration as well, not just disaster 
recovery tools?

Without universal access to this feature it's not adequate for instrumentation 
purposes.

One option to achieve that would be to extend Qemu to allow 'qemu daemons' to 
run on the (Linux) guest side. These would be statically linked binaries that 
can run on any Linux system, and which could provide various built-in Qemu 
functionality from the guest side to the host side.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ