Thanks for your help! Paul Op 28-04-2020 om 07:39 schreef Peter Krempa: > 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/ >> > > -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
