I had similar problem recently, when my 6GB root ran out of inodes during `emerge -uDN world` and... well, here we go:

1) if you have root on partition (not on lvm volume) you can't resize it online. You must boot from another medium and then carry on.
2) you need some free space after partition you want to extend. If it's virtual image it's probably the only partition there, so this should not be a problem
3) do the job: Run fdisk , or whatever partitioner you like. If your partition doesn't start from the first possible block, write down where it starts. Delete partition you want to expand. Create new partition. It must start exacly at the same spot deleted one used to. When you're done with fdisk, expand filesystem to match the size of new partition and boot it.

In case of LVM it's much easier: simply resize volume and then resize filesystem. Many filesystems can be resized while mounted
Ofcourse, it's easy to make a mistake when deletinig and re-creating partition, so either make a copy of image or make sure nothing interrupts you and focus.

Last edited by szatox on Tue May 27, 2014 10:28 pm; edited 1 time in total

It's got an MBR partition, /boot is /dev/sda1, swap is /dev/sda2 and / is /dev/sda5.

I don't know why the guy put / on an extended partition.

I really would rather change disks and have something rational. Keeping this one would mean resizing the extended partition and then resizing the partition inside it. Too much chance of something going horribly wrong IMO.

Is it really that much of a problem to do a copy on mounted partitions?

Ideally, I would make a new disk with GPT partition table, set up LVM and copy partitions over afterward, but I think this is just too many things to go wrong.

you can copy it onto LVM volume, it seems to be a good idea when facing such a mess. I don't know what's the point of GPT under LVM as it's LVM that does the hard job anyway.
You can mount root readonly and copy the whole partition onto LVM (And then resize it). If you want to change filesystem too, it would still be a better idea to boot from external medium and run for example `rsync -a` . With cp I'm not always sure what I get.

If you boot from external medium, there will be nothing mounted on top of directory tree you want to copy, so you can easyly copy it with either rsync or cp or whatever you like most.
Now, since both, /dev/mapper/* and /sd*N are an interface/abstraction layer for block devices containing filesystem, whateer is behind it should not matter. You can even dump your partition to file and use the result with your VM telling it it's a raw image. This means
dd if=/dev/sda5 of=/dev/hddvg1/myvm_root bs=4096
should do the job just fine as long as there are no writes to /dev/sda5 until it completes. Unmount filesystem if possible, mount readonly if not. Anything mounted on top of this readonly filesystem is not a part of cloned fileesystem so will not be read.
Oh, it's probably a better idea to use block size close to hdd disk cache, as it tells dd how much data you want to move in a single shot rather than what kind of disk you have.