Re: Migrate to a bigger disk possible?

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/ >