On Wed, Mar 07, 2007 at 02:20:11PM -0800, Hanks, Dan wrote:
On Wed, Mar 07, 2007 at 01:50:43PM -0800, Hanks, Dan wrote:
I've been able to kickstart a number of VMs using the virt-install
tool,
and so far have had pretty good success. One aspect of these
installs
has me a bit concerned, though. In most cases, anytime the kickstart needs to do intensive disk activity (such as formatting partitions,
or
installing all the rpms) there are noticible hangs, which I'm
guessing
come from some kind of IO wait. The result is that a kickstart which should take < 10 minutes ends up taking a half-hour or so.
What kind of virtual disk image are you using for the guest ? A
partition
or a file - if the latter is it sparse, or non-sparse. Basically
sparse
files will be horribly slow because every time the host OS has to
extend
the sparse file to allocate real blocks it needs to do a journal sync
on
the host FS. This destroys performance of I/O from the guest until the sparse file is fully-allocated.
I'm using files. I've been using a command-line such as this for the install:
virt-install -m "00:16:3e:00:00:01" -n hostname -r 500 --vcpus=2 -f /var/lib/xen/images/myhost.xen.img -s 4 --nographics -p -l ftp://host/fc6/distro/i386/os -x "ks=http://kshost/ks.cfg"
Adding --nonsparse into the args looks like it fixes the speed issues (albeit adds a bit of extra time right up front to allocate the entire disk image). I imagine using partitions instead of files would be faster altogether. I'll have to explore that option (files are just so nice to ship around when needed).
If pre-allocated, files should be within a few % of real partitions.
What does the "slower" here refer to? Slower up-front time to create the image file? Yes, but the actual install will be faster since it wont have to keep allocating more space for the disk image. Thoughts?
Yes, upfront time will be longer due to the need to pre-allocate the disk, this should be more than offset by the faster install time. So I'd use --nonsparse as a general rule.
Dan.