Fedora xen - Mar 2007 - RE: Kickstart slowness with virt-install

> -----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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|