Messages in this thread | | | Date | Mon, 22 Mar 2010 03:18:26 +0700 | From | Antoine Martin <> | Subject | Re: [RFC] Unify KVM kernel-space and user-space code into a single project |
| |
On 03/22/2010 03:11 AM, Avi Kivity wrote: > On 03/21/2010 10:08 PM, Olivier Galibert wrote: >> 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. > > That includes the guest kernel. If you can deploy a new kernel in the > guest, presumably you can deploy a userspace package. That's not always true. The host admin can control the guest kernel via "kvm -kernel" easily enough, but he may or may not have access to the disk that is used in the guest. (think encrypted disks, service agreements, etc)
Antoine >> Deploying things in the >> host OTOH is business as usual. > > True. > >> And you're smart enough to know that. > > Thanks. >
| |