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@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 questionWe 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.
Op 27-04-2020 om 10:41 schreef Peter Krempa:> On Mon, Apr 27, 2020 at 10:13:37 +0200, Paul van der Vlis wrote:>> 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.Really interesting. I see an option "--migrate-disks" and I guess this will do this. Something like: virsh migrate --live --p2p --copy-storage-all --persistent \ --undefinesource --verbose ----migrate-disks vda \ $vm qemu+ssh://$other/system Is there a way to simply migrate all writeable disks without specifying them?> Unfortunately we can't do it for incremental at this point.So far I understand it, incremental means something like a synchronisation like rsync does. So parts what are allready there, don't have to be copied again. Please correct me when I am wrong. When the disks are not there at the other side, an incremental backup would be the same as a full copy.>> 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.Again thanks for your help! With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
On Mon, Apr 27, 2020 at 20:58:19 +0200, Paul van der Vlis wrote:> Op 27-04-2020 om 10:41 schreef Peter Krempa: > > On Mon, Apr 27, 2020 at 10:13:37 +0200, Paul van der Vlis wrote: > > >> 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. > > Really interesting. I see an option "--migrate-disks" and I guess this > will do this. Something like: > > virsh migrate --live --p2p --copy-storage-all --persistent \ > --undefinesource --verbose ----migrate-disks vda \ > $vm qemu+ssh://$other/system > > Is there a way to simply migrate all writeable disks without specifying > them?Yes. --copy-storage-all without actually using --migrate-disks. In the end --migrate-disks even requires you to specify either --copy-storage-all or --copy-storage-inc.> > > Unfortunately we can't do it for incremental at this point. > > So far I understand it, incremental means something like a > synchronisation like rsync does. So parts what are allready there, don't > have to be copied again. Please correct me when I am wrong.If you have a backing chain, that means an overlay image on top of the original base image e.g. a snapshot, then --copy-storage-inc copies only the overlay image, not all data. Obviously if you have only one/base image then everything is copied. So if you meant to use a full copy, but got it just accidentally I suggest you use --copy-storage-all.> When the disks are not there at the other side, an incremental backup > would be the same as a full copy.No, that is not entirely so. This unfortunately has to do with external snapshots and it's most probably not documented clear enough.> > >> 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. > > Again thanks for your help! > > With regards, > Paul > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://www.vandervlis.nl/ >