> -----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.
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
|
Home