On 19 mrt 2010, at 19:00, Richard W.M. Jones wrote: Cool :) I did some testing, but I was unable to resize my test image. Is this stuff actually functional? I applied the patch to the git repository (latest commit 50d2af4f8541a81d047753d7d300804ff649230c) Input image looks like this: Device Boot Start End Blocks Id System fedora-12-kvm.img1 * 1 261 2096451 83 Linux I used 'virt-resize --expand /dev/vda1 fedora-12-kvm.img test.img' to resize it. The resulting image had no partitions at all. Thanks -- Dennis Krul <dennis(a)tilaa.nl&gt;

On 21 mrt 2010, at 12:01, Richard W.M. Jones wrote: Ah ok, no problem. I was just curious to see how far you got :) I don't have further remarks on your proposal. It looks solid indeed. If you have something that needs testing with various images, I'd be more than willing to help. I'm not very proficient in perl though, so I doubt I could be of any help with the actual implementation, except perhaps the occasional bugfix. (Just wondering: Why didn't you use python to write the virt-tools? Personal preference or because of technical reasons (bindings et al)?) Thanks and good luck -- Dennis Krul <dennis(a)tilaa.nl&gt;

Expanding on this topic: If virt-resize is given a disk image that looks like this: filesystem | LV | +-------- VG ------+ PV 100% full PV 100% full /dev/sda1 /dev/sda2 If asked to expand 'filesystem', which we assume fills up 100% of its container, then obviously the expansion has to "cascade down" so that eventually we need to expand one or both of the partitions. Which partition is arbitrary (but this is a rather atypical case). Now imagine that virt-resize is given this disk image and asked to increase the size of 'filesystem': filesystem | LV | VG | PV 80% full /dev/sda1 If the requested increase is smaller than the remaining free space in the PV, this could be done without resizing the partition at all. However the user would hardly need to use virt-resize for this, since they could just do exactly the same thing within the guest (or even from the host, using guestfish). It seems to me that if the user is using virt-resize at all, then any request to resize a filesystem must translate into a request to change the size of a partition. So we might say that a requested increase of 1GB of 'filesystem' cascades down so the LV and PV are also increased by 1GB, even if there was space in the PV to start with. It's trickier when we consider shrinking. filesystem | LV | VG | PV 100% full /dev/sda1 If the user requests that 'filesystem' is shrunk by 20%, we could end up either with: filesystem | LV | VG | PV 80% full /dev/sda1 (same size as before) or with: filesystem | LV | VG | PV 100% full /dev/sda1 (shrunk to 80% of previous size) If the user is using virt-resize at all, then obviously only the second scenario makes sense. And how about this situation: fs1 fs2 | | LV1---LV2 | VG | PV 100% full /dev/sda1 User requests that /dev/sda1 is shrunk by some amount. We need to take that space from fs1 and fs2 (assuming they have free space). Potentially there could be many different ways to achieve this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

On Sun, Mar 21, 2010 at 07:08:26PM +0100, Dennis Krul wrote: Yup, I think I agree, especially in the expand case. Shrinking _is_ more complex (but much rarer in practice) because in that case we have to check that the PV is small enough already. They can do this offline with guestfish, although it's all horribly manual. I think there's some case for not concentrating too hard at the moment on the shrink case, since I'm betting that is rare. I'll wait for users to request it before doing a more thorough implementation. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw