WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Resize a VM disk image

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Resize a VM disk image
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 22 Jan 2008 15:17:07 +0000
Cc: kieran JOYEUX <kjoyeux@xxxxxxxxxxxx>
Delivery-date: Tue, 22 Jan 2008 07:17:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <479601BA.2010205@xxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <479601BA.2010205@xxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)
> I have Xen 3.0.3 installed with yum on Centos 5.1.

OK.  By the way, the Xen included with CentOS 5.1 is actually Xen 3.1.  The 
package name says Xen 3.0.3 but that's not actually true :-)

> I'am facing an issue trying to resize the disk image of a centos 4.5 VM.
> The VM disk size is 50Go and i need to add 150Go.

OK.  So you want it to be 200GB in size?

> I tried two methods so far :
>
> -------------1st method-----------------------
> dd if=/dev/zero of=<image file> bs=1M conv=notrunc count=1 seek=2500

With a block size of 1M and a seek of 2500, won't that put you 2500MB = 2.5GB 
into the file?  And then you're writing 1MB of zeros?  That's not going to 
make your 50GB disk bigger, and it may well corrupt your filesystem.

Are you backing up your virtual disk before trying this?  It's good practice, 
especially until you have a good solution worked out that works for you.  You 
may want to check that you haven't lost data or corrupted anything by trying 
this command; ideally you'd restore from backup if you have one.

<more output snipped>

> -------------2nd method-----------------------
> dd if=/dev/zero of=/tmp/temp_expand bs=1024k count=1000

With a block size of 1024KB == 1MB and a count of 1000, you're creating 
something the size of a gigabyte, which is less than you wanted?

> cp -a /xen-images/youki.img /xen-images/youki.img.back
> cat /tmp/temp_expand >> /xen-images/youki.img

OK.

> resize2fs -f /xen-images/youki.img

Does that give any errors?

> None of these are actually working.

I'd have thought the second one ought to work, although it won't expand your 
filesystem by very much because you're only adding a gigabyte.

> Is there a simplest way or just 
> another way to extend a vm disk or i have to reinstall a new os from
> scratch?

I think a variation on your first attempt ought to work:

BACKUP YOUR IMAGE FILE FIRST

dd if=/dev/zero of=<image file> count=1 seek=200G

Using seek in this way will cause a sparse file to be created and should give 
you a virtual disk with an apparent size of around 200GB.  Because it's 
sparse, the extra space will only be allocated from the host disk as the 
guest writes to it.  That can make things more space efficient but remember 
that space *must* be available for the virtual disk to grow into.

If the host runs out of space for the guest's disk to grow into then the guest 
will experience filesystem corruption and data loss.

If you want to pre-allocate the file rather than making it sparse, then your 
second solution with cat >> (having created a large non-sparse file of zeros 
using dd to really write the data, instead of using seek) should work, I 
think.

Remember that resizing the disk in this way will not work while the guest is 
running (and you should *never ever* run any utilities against a FS from 
outside the guest whilst it has that FS mounted - that would be guaranteed to 
fry your filesystem).  Suspending the guest is not enough, it needs to have 
the filesystems unmounted fully or be properly shut down.

You can use the -s flag to ls (e.g. do ls -sl) to view the real disk usage as 
well as the logical size.  For a sparse file, the real disk usage may be 
lower than the logical size; the logical size may be larger than the disk 
actually has room for.

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>