On 03/21/2010 10:31 PM, Antoine Martin wrote:
On 03/22/2010 03:24 AM, Avi Kivity wrote:
On 03/21/2010 10:18 PM, Antoine Martin wrote:
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)
There is a matching -initrd argument that you can use to launch a
daemon.
I thought this discussion was about making it easy to deploy... and
generating a custom initrd isn't easy by any means, and it requires
access to the guest filesystem (and its mkinitrd tools).
That's true. You need to run mkinitrd anyway, though, unless your guest
is non-modular and non-lvm.
I believe that -kernel use will be rare, though. It's a lot easier
to keep everything in one filesystem.
Well, for what it's worth, I rarely ever use anything else. My virtual
disks are raw so I can loop mount them easily, and I can also switch
my guest kernels from outside... without ever needing to mount those
disks.
Curious, what do you use them for?
btw, if you build your kernel outside the guest, then you already have
access to all its symbols, without needing anything further.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
