<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> </head> <body> <div style="color: rgb(33, 33, 33); background-color: rgb(255, 255, 255); text-align: left;" dir="auto"> External snapshots in general are not documented well enough.</div> <div style="color: rgb(33, 33, 33); background-color: rgb(255, 255, 255); text-align: left;" dir="auto"> </div> <div style="color: rgb(33, 33, 33); background-color: rgb(255, 255, 255); text-align: left;" dir="auto"> Just extend the current disk, followed by redefining the root partition within the running VM.</div> <hr style="display:inline-block;width:98%" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr">From: libvirt-users-bounces@redhat.com <libvirt-users-bounces@redhat.com> on behalf of Peter Krempa <pkrempa@redhat.com> Sent: Tuesday, April 28, 2020 1:39:35 AM To: Paul van der Vlis <paul@vandervlis.nl> Cc: libvirt-users@redhat.com <libvirt-users@redhat.com> Subject: Re: Migrate to a bigger disk possible? <div> </div> </div> <div class="BodyFragment"> <div class="PlainText">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 > <a href="https://www.vandervlis.nl/">https://www.vandervlis.nl/</a> > </div> </div> </body> </html>