-----Original Message----- From: Daniel P. Berrange [mailto:berrange@redhat.com] Sent: Wednesday, March 07, 2007 2:54 PM To: Hanks, Dan Cc: fedora-xen@redhat.com Subject: Re: [Fedora-xen] Kickstart slowness with virt-install
On Wed, Mar 07, 2007 at 01:50:43PM -0800, Hanks, Dan wrote:
Hi folks,
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).
The verbiage for the virt-install command-line args is (to me) a bit confusing in this matter:
"-- nonsparse Don't use sparse files for disks. Note that this will be significantly slower for guest creation"
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?
Thanks for your help--this was exactly the piece of information I needed,
-- Dan
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.
On Wed, 7 Mar 2007, Daniel P. Berrange wrote:
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.
So why isn't that the default for virt-install? The other risk is the admin creating a truckload of sparse images, and the guests ending with really odd problems months later when it turns out there isn't enough diskspace, and no one can figure out this has happened after running so well before...
Paul
On Wed, Mar 07, 2007 at 11:50:16PM +0100, Paul Wouters wrote:
On Wed, 7 Mar 2007, Daniel P. Berrange wrote:
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.
So why isn't that the default for virt-install? The other risk is the admin creating a truckload of sparse images, and the guests ending with really odd problems months later when it turns out there isn't enough diskspace, and no one can figure out this has happened after running so well before...
If we were writing virt-install again today, we would make it the default, but we've had two Fedora release where virt-install defaulted to sparse files. Changing existing behaviour of a command isn't all that nice, even if there are potential benefits to be had. So we added the --nonsparse flag and left the existing behaviour unchanged.
Regards, Dan.
-
Daniel P. Berrange -
Hanks, Dan -
Paul Wouters