[lkml]   [2010]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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)

    >> Deploying things in the
    >> host OTOH is business as usual.
    > True.
    >> And you're smart enough to know that.
    > Thanks.

     \ /
      Last update: 2010-03-21 21:21    [W:0.021 / U:56.620 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site