On 08/04/2010 11:06 PM, David S. Ahern wrote:
On 08/04/10 11:34, Avi Kivity wrote:
And it's awesome for fast prototyping. Of course, once that fast
becomes dog slow, it's not useful anymore.
For the Nth time, it's only slow with 100MB initrds.
100MB is really not that large for an initrd.
Consider the deployment of stateless nodes - something that
virtualization allows the rapid deployment of. 1 kernel, 1 initrd with
the various binaries to be run. Create nodes as needed by launching a
shell command - be it for more capacity, isolation, etc. Why require an
iso or disk wrapper for a binary blob that is all to be run out of
memory?
It's inefficient. First qemu reads the initrd and stores it in memory
(where it is kept while the guest runs in case you migrate or reboot).
Then the guest copies it into temporary storage (where we currently have
the slowdown). Then the guest decompresses and extracts it to tmpfs
(initramfs model). Finally the guest runs init out of initrd, typically
using just a part of the 100MB+.
Whereas with a disk image, individual pages are copied to the guest on
demand without taking space in qemu. With cache=none, they don't even
affect host pagecache.
The -append argument allows boot parameters to be specified at
launch. That is a very powerful and simple design option.
Good point. You still have it with a small initrd that bootstraps a
larger image.
Note -append probably works even without -kernel, it's just that the
guest isn't tooled to look at it.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
