* Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Mon, Mar 22, 2010 at 01:54:40PM +0100, Ingo Molnar wrote: > > > > * Daniel P. Berrange <berrange@xxxxxxxxxx> 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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
