Migrate to a bigger disk possible?

[Peter Krempa]

On Mon, Apr 27, 2020 at 10:13:37 +0200, Paul van der Vlis wrote:
> Op 27-04-2020 om 09:02 schreef Peter Krempa:
> > On Sat, Apr 25, 2020 at 16:40:35 +0200, Paul van der Vlis wrote:
> >> Op 25-04-2020 om 16:00 schreef Paul van der Vlis:
> >>> Hello,
> >>>
> >>> I have a qcow2 disk what needs to become increased.
> >>>
> >>> I don't have space on the location where it is now to have it two time,
> >>> so I want to live-migrate it to another host.
> >>>
> >>> On the other host I have to create a qcow2 disk before I can migrate.
> >>>
> >>> What would happen when I would create there a bigger qcow2 disk then the
> >>> original one?  Can I resize the filesystem after the migration?
> >>
> >> Not sure why, but I thought it's not possible to encrease qcow2 disks
> >> without copying the disk. But now I find many manuals what say it's no
> >> problem. Sorry...
> > 
> > It definitely is possible. There are multiple options though and I
> > didn't quite get which one is your case:
> > 
> > 1) QCOW2 image is too small but theres unused space on the filesystem
> >    where the image is stored:
> > 
> >    - live:
> >    The image can be resized live via 'virsh blockresize'. You then must
> >    modify the partitions and enlarge filesystem.
> 
> Interesting, that would be better then what I did now.
> 
> >    - offline:
> >    'virt-resize' tool from the libguestfs package can be used to do it
> >    offline and it should be able to resize your partitions and
> >    filesystem as well.
> 
> What I did is this:
> 
> virsh shutdown kvm68
> qemu-img resize /data/kvm68.qcow2 +800G
> virsh start kvm68
> ssh root at kvm68.vandervlis.nl
>   lsblk
>   pvs
>   apt install cloud-guest-utils
>   growpart /dev/vda 1
>   pvresize /dev/vda1
>   lsblk
>   lvextend -rL +100G /dev/vg0/root
> 
> > 2) QCOW2 is too small and there isn't enough space on the filesystem,
> >    but there's enough space on a different filesystem on the same host:
> > 
> >    - live:
> >    'virsh blockcopy' can be used to copy the existing image to the new
> >    filesystem while the VM is running and then switch to it. You can
> >    then use same steps as in 1) to resize the filesystem.
> 
> I did not know this command. Thanks. Could be usefull.
> 
> >    - offline
> >    copying the image and using the steps from 1) is the best bet here
> > 
> > 3) QCOW2 is too small and there isn't enough storage on the same host,
> >    but there is a different host where I want to run it.
> > 
> >    -live
> >    You can use VM live migration to migrate the VM to the other host and
> >    then enlarge the disk using steps in 1). Please refer to the docs of
> >    live migration.
> 
> I use normally something like this, because in my case every fysical
> server has it's own storage:
> 
> virsh migrate --live --p2p --copy-storage-inc --persistent \
>   --undefinesource --verbose $vm qemu+ssh://$other/system
> 
> A point is that I have to create disk(s) on the other side with
> qemu-img, I did not found a way to do that automatically. My question

We are able to pre-create the storage given that a full copy is
requested (copy-storage-all, not copy-storage-inc) and the images reside
in a location covered by a libvirt 'directory' storage pool at least on
the destination of the migration. Unfortunately we can't do it for
incremental at this point.

> was what would happen when I would create a bigger disk there then the
> original one.

I'm not sure now whether the new size will be picked up, but nothing
should break, so you can give it a try. Certainly a shutdown and start
of the VM will fix it if it's not picked up or a blockresize.