Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: [PATCH 11/12] md: convert cpu notifier to return encapsulate errno value
Next: [GIT PULL] vhost-net fixes for issues in 2.6.34-rc1
From: Olivier Galibert on 21 Mar 2010 16:10 On Sun, Mar 21, 2010 at 10:01:51PM +0200, Avi Kivity wrote: > On 03/21/2010 09:17 PM, Ingo Molnar wrote: > > > >Adding any new daemon to an existing guest is a deployment and usability > >nightmare. > > > > The logical conclusion of that is that everything should be built into > the kernel. Where a failure brings the system down or worse. Where you > have to bear the memory footprint whether you ever use the functionality > or not. Where to update the functionality you need to deploy a new > kernel (possibly introducing unrelated bugs) and reboot. > > If userspace daemons are such a deployment and usability nightmare, > maybe we should fix that instead. Which userspace? Deploying *anything* in the guest can be a nightmare, including paravirt drivers if you don't have a natively supported in the OS virtual hardware backoff. Deploying things in the host OTOH is business as usual. And you're smart enough to know that. OG. -- 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: Alexander Graf on 22 Mar 2010 07:30 On 22.03.2010, at 12:14, Ingo Molnar wrote: > > * Avi Kivity <avi(a)redhat.com> wrote: > >> On 03/21/2010 11:54 PM, Ingo Molnar wrote: >>> * Avi Kivity<avi(a)redhat.com> wrote: >>> >>>> On 03/21/2010 10:55 PM, Ingo Molnar wrote: >>>>> Of course you could say the following: >>>>> >>>>> ' Thanks, I'll mark this for v2.6.36 integration. Note that we are not >>>>> able to add this to the v2.6.35 kernel queue anymore as the ongoing >>>>> usability work already takes up all of the project's maintainer and >>>>> testing bandwidth. If you want the feature to be merged sooner than that >>>>> then please help us cut down on the TODO and BUGS list that can be found >>>>> at XYZ. There's quite a few low hanging fruits there. ' >>>> That would be shooting at my own foot as well as the contributor's since I >>>> badly want that RCU stuff, and while a GUI would be nice, that itch isn't on >>>> my back. >>> I think this sums up the root cause of all the problems i see with KVM pretty >>> well. >> >> 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. Alex -- 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: Daniel P. Berrange on 22 Mar 2010 08:40 On Mon, Mar 22, 2010 at 02:31:49PM +0200, Pekka Enberg wrote: > On Mon, Mar 22, 2010 at 1:48 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > >> What about line number information? �And the source? �Into the kernel with > >> them as well? > > > > Sigh. Please read the _very first_ suggestion i made, which solves all that. I > > rarely go into discussions without suggesting technical solutions - i'm not > > interested in flaming, i'm interested in real solutions. > > > > Here it is, repeated for the Nth time: > > > > Allow a guest to (optionally) integrate its VFS namespace with the host side > > as well. An example scheme would be: > > > > � /guests/Fedora-G1/ > > � /guests/Fedora-G1/proc/ > > � /guests/Fedora-G1/usr/ > > � /guests/Fedora-G1/.../ > > � /guests/OpenSuse-G2/ > > � /guests/OpenSuse-G2/proc/ > > � /guests/OpenSuse-G2/usr/ > > � /guests/OpenSuse-G2/.../ > > > > �( This feature would be configurable and would be default-off, to maintain > > � �the current status quo. ) > > Heh, funny. That would also solve my number one gripe with > virtualization these days: how to get files in and out of guests > without having to install extra packages on the guest side and > fiddling with mount points on every single guest image I want to play > with. 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/ -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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: Daniel P. Berrange on 22 Mar 2010 09:10 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. 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. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- 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: Frank Ch. Eigler on 22 Mar 2010 13:20
mingo wrote: > [...] >> No, the split-repository situation was the smallest problem after all. Its >> was a community thing. If the community doesn't work a single-repo project >> will also fail. [...] > > So, what do you think creates code communities and keeps them alive? > Developers and code. And the wellbeing of developers are primarily influenced > by the repository structure and by the development/maintenance process - i.e. > by the 'fun' aspect. (i'm simplifying things there but that's the crux of it.) > > So yes, i do claim that what stiffled and eventually killed off the Oprofile > community was the split repository. [...] In your very previous paragraphs, you enumerate two separate causes: "repository structure" and "development/maintenance process" as being sources of "fun". Please simply accept that the former is considered by many as absolutely trivial compared to the latter, and additional verbose repetition of your thesis will not change this. - FChE -- 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/ |