Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Lukas Kolbe on 22 Mar 2010 09:00 Am Montag, den 22.03.2010, 12:23 +0100 schrieb Alexander Graf: > >> I think we agree at last. Neither I nor my employer are interested in > >> running qemu as a desktop-on-desktop tool, therefore I don't invest any > >> effort in that direction, or require it from volunteers. > > > > Obviously your employer at least in part defers to you when it comes to KVM > > priorities. > > > > So, just to make this really clear, _you_ are not interested in running qemu > > as a desktop-on-desktop tool, subsequently this kind of > > disinterest-for-desktop-usability trickled through the whole KVM stack and > > poisoned your attitude and your contributor's attitude. > > > > Too sad really and it's doubly sad that you dont feel anything wrong about > > that. > > Please, don't jump to unjust conclusions. > > The whole point is that there's no money behind desktop-on-desktop > virtualization. Thus nobody pays people to work on it. Thus nothing > significant happens in that space. > > If there was someone standing up to create a really decent desktop > qemu front-end I'm confident we'd even officially suggest using that. > In fact, that whole discussion did come up in the weekly Qemu/KVM > community call and everybody agreed heavily that we do need a desktop > client. > > The problem is just that there is nobody standing up. And I hope you > don't expect Avi to be the one creating a GUI. Besides, Ingo could just go ahead and use libvirt together with virt-manager. It solves a few of the usability issues he came up with somewhere in this thread, is available even in every current distribution, and *actually* works quite well for the desktop usecase. It just desparatly needs more brainpower and manpower to make it a competitor to VirtualBox & Co, because its not as polished and featurecomplete yet. But I bet virt-managers maintainers welcome patches to fix and enhance usability. Most of the needed fixes probably wouldn't touch qemu at all, let alone kvm. Sorry to chime in with my opinion, but this whole thread is incredibly boring and full of non-arguments yet really highly amusing. -- Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 10:00 * Daniel P. Berrange <berrange(a)redhat.com> wrote: > On Mon, Mar 22, 2010 at 01:54:40PM +0100, Ingo Molnar wrote: > > > > * Daniel P. Berrange <berrange(a)redhat.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 10:10 * Richard W.M. Jones <rjones(a)redhat.com> wrote: > On Mon, Mar 22, 2010 at 02:56:47PM +0100, Ingo Molnar wrote: > > 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? > > Totally. That's not to say there is a definite plan, but we're very open to > doing this. We already wrote the daemon in such a way that it doesn't > require the appliance part, but could run inside any existing guest (we've > even ported bits of it to Windoze ...). > > The only remaining issue is how access control would be handled. You > obviously wouldn't want anything in the host that can get access to the > vmchannel socket to start sending destructive write commands into guests. By default i'd suggest to put it into a maximally restricted mount point. I.e. restrict access to only the security context running libguestfs or so. ( Which in practice will be the user starting the guest, so there will be proper protection from other users while still allowing easy access to the user that has access already. ) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 10:10 * Richard W.M. Jones <rjones(a)redhat.com> 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 it would be a nice option to allow such guest-side "daemon's" to be executed in the guest context without _any_ guest-side support. This would be possible by building such minimal daemons that use vmchannel, and which are built for generic x86 (maybe even built for 32-bit x86 so that they can run on any x86 distro). They could execute as the init task of any guest kernel - Qemu could 'blend in / replace' the binary as the init task of the guest temporarily - and some simple bootstrap code could then start the daemon and start the real init binary (and turn off the 'blending' of the init task). That way any guest could be extended via such Qemu functionality - even without any kernel changes. Has anyone thought about (or coded) such a solution perhaps? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 10:40
* Avi Kivity <avi(a)redhat.com> wrote: > On 03/22/2010 02:44 PM, Ingo Molnar wrote: > >This is why i consider that line of argument rather dishonest ... > > I am not going to reply to any more email from you on this thread. Because i pointed out that i consider a line of argument intellectually dishonest? I did not say _you_ as a person are dishonest - doing that would be an ad honimen attack against your person. (In fact i dont think you are, to the contrary) An argument can certainly be labeled dishonest in a fair discussion and it is not a personal attack against you to express my opinion about that. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |