[Xen-users] expanding Xen guest disk size

["Guido Hecken" <guido.hecken@xxxxxxxxxxxxx>]

> -----Ursprüngliche Nachricht-----
> Von: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-
> bounces@xxxxxxxxxxxxxxxxxxx] Im Auftrag von Fajar A. Nugraha
> Gesendet: Montag, 13. Juni 2011 09:49
> An: Xen User-List
> Betreff: Re: [Xen-users] expanding Xen guest disk size
> 
> On Mon, Jun 13, 2011 at 4:49 AM, Simon Hobson <linux@xxxxxxxxxxxxxxxx> wrote:
> > sylvan.dcunha@xxxxxxxxx wrote:
> >
> >> I have been using Xen on centos and its been working grt..
> >> I have 3 VM guest OS running on Xen under Centos 5.5
> >>  ...
> >> Now I recently ran into a problem that my centos guest VM and windows 2003
> >> and slowly running out of space.
> >
> > You don't state what type of storage you use for the guest volumes, but the
> > process is very similar for all of the options.
> >
> > 1) Enlarge the (virtual) block device. If it's a file based volume then you
> > need to extend the file, if it's a partition then it's going to be hard, if
> > it's on LVM then just do an lvextend on it.
> 
> Be VERY careful if you're using file-backed domU storage. Most howtos
> involve using dd. If you do it wrong, you might end up destroying the
> file image. So better have a copy of the disk image before doing
> anything. If you don't like using dd, try "man truncate"
> 
> Also, for reference, extending the file image is only possible if the
> image is raw (the default format on Centos' Xen). qemu and vhd format
> can't be resized easily, and the "resize" process for these type of
> images is basically create a new, larger, disk image and copy the old
> content.
> 
> >
> > 2) Signal the guest to notice the change in block size. I understand that
> > there is a process whereby you can tell the guest to re-read this, but I've
> > never done it.
> 
> IIRC this is only supported on newer versions of Xen, and only for PV
> Linux domUs. Centos doesn't have this feature.
> 
> > A sure way is to stop it and restart it - just restarting
> > isn't enough.
> 
> Yup.
> 
> >
> > 3) Resize the filesystem using the appropriate tools.
> >
> > There are quite a few variations, which is right for you depends on you you
> > have things set up. It may well be easier to just stop the guest, and resize
> > the filesystem in Dom0 - this has the advantage that you don't need to
> > persuade the guest to unmount the filesystem if online expand isn't
> > supported.
> >
> > Also, if you have partitioned the virtual device in the guest then you'll
> > need to fiddle with the partitions on the resized virtual device - that is
> > more work than just expanding a filesystem built straight on the device.
> 
> If you use HVM domU (e.g Windows), and domU OS is installed on a
> partition, it might be easier to boot using some kind of livecd with
> gparted (e.g. gparted live, systemrescuecd, etc.) and use the GUI to
> resize the partition.

Sorry for the missformated post, used the wrong formatting options in Outlook.
So, here we go one more time, hopefully more readable:

On XEN 3.3. as the Hypervisor I had a similiar task on a Windows 2011 SBS 
Installation with four virtual disks, all based on LVM, a few days ago.

Since none of the disks were system-disks, I stopped active processes like 
Databases on these disks and did the following:
# removed the disk from DOMU with
xm block-detach DOMID BLOCKDEV-ID

# resized the underlaying LVM
lvresize -L80G virt_vm_vg-w2k11_sbs_databases

# created a devicemapping of the Logical Volume (in DOM0) kpartx -a 
/dev/mapper/virt_vm_vg/w2k11_sbs_databases

# accessed the partition in the devicemap with fdisk fdisk 
/dev/mapper/virt_vm_vg-w2k11_sbs_databases
# made a note of the startsector
# deleted the partition 
# not really without some kind of exertion ;-) 
# created a new partition over the whole diskspace now available, 
# using the before noted startsector as the beginning of the new partition 
# and type=7 hpfs/ntfs

# using ntfsresize from ntfsprogs to resize the ntfs-partition ntfsresize 
/dev/mapper/virt_vm_vg/w2k11_sbs_databases

# removed the devicemapping
kpartx -d /dev/mapper/virt_vm_vg/w2k11_sbs_databases

# re-attached the disk to the DOMU
# xm block-attach DOM-ID phy:/dev/virt_vm_vg/w2k11_sbs_databases xvd[a-n] w
# Inside the DOMU it is normal, that the system want's to run chkdsk on the 
newly 
# extended filesystem

Before applying these modifications to a production system one should be 
prepared in terms of "wearing belt and suspenders" with a good backup and - 
what I did - with a "stupid" windows xp DOMU to test the above scenario.

Hints:
Within my tests on the windows xp DOMU (with two partitions in it), I had a 
problem with kpartx, removing the before created devicemaps. 
After some time of investigating I found the solution in using dmsetup to 
remove in a first step the second partition with:
dmsetup -f remove /dev/mapper/virt_vm_vg-xpp_sp3_corp2
and afterwards removing the first partition with dmsetup -f remove 
/dev/mapper/virt_vm_vg-xpp_sp3_corp

As Fajar mentioned, I also used an instance of SystemRescueCd as DOMU and tried 
to attache one of the above virtual disks inside this DOMU.
But the problem was, the virtual disk had to be already present at the creation 
of the DOMU. A later "block-attach statement" didn't made the disk visible in 
the DOMU.
So I decided to install the missing tools (ntfsprogs) in DOM0.

Hope, this helps others to save some time and headache

Regards, Guido

> 
> Note however that default Centos installation use LVM on domU side. In
> this case it's MUCH easier to simply add NEW disk image, and use LVM
> on domU (vgextend, lvextend) to grow the VG and LV.
> 
> --
> Fajar
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

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