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? With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
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... With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
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. - 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. 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. - 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. - offline Copying the image and VM XML config is the best bet here.
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 question was what would happen when I would create a bigger disk there then the original one.
- offline Copying the image and VM XML config is the best bet here.
Thanks for your story! With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
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 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. 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/
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@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? 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/
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/
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.
What I see here, is that this migrates a qcow2 image to it's theoretical size. So if it's a 1000G disk with 200G on it, it creates an 1000G file on the other host. Is it possible to copy the image(s) in the "growable way" like a qcow2 image normally is? With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
participants (3)
-
Brandon Doyle -
Paul van der Vlis -
Peter Krempa