External snapshots in general are not documented well enough.
Just extend the current disk, followed by redefining the root partition within the running VM.
From: libvirt-users-bounces@xxxxxxxxxx <libvirt-users-bounces@xxxxxxxxxx> on behalf of Peter Krempa <pkrempa@xxxxxxxxxx>
Sent: Tuesday, April 28, 2020 1:39:35 AM
To: Paul van der Vlis <paul@xxxxxxxxxxxxx>
Cc: libvirt-users@xxxxxxxxxx <libvirt-users@xxxxxxxxxx>
Subject: Re: Migrate to a bigger disk possible?
Sent: Tuesday, April 28, 2020 1:39:35 AM
To: Paul van der Vlis <paul@xxxxxxxxxxxxx>
Cc: libvirt-users@xxxxxxxxxx <libvirt-users@xxxxxxxxxx>
Subject: 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/
>
> 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/
>
