Marc-Aurèle Brothier - Exoscale
2016-Mar-03 10:06 UTC
[libvirt-users] Live migration - backing file
Hi! I'm testing the live migration on libvirt + KVM, the VMs are using non-shared local storage only. If I run a live migration with --copy-storage-full, the final disk file on the remote host after the migration has a full blown size of the specified value (10G) in my case, instead of the few MB on the source host before the migration. Running qemu-img I can see that the ref for the backing file is gone. on source host: $ ls -lh 3129b8a8-eca4-4b05-878a-66c2771b501f gives me 18MB $ qemu-img info 3129b8a8-eca4-4b05-878a-66c2771b501f image: 3129b8a8-eca4-4b05-878a-66c2771b501f file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 17M cluster_size: 65536 backing file: /var/lib/libvirt/images/34fa65ce-483b-4ffa-88f8-75f6ebf670c1 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false>> I run a migration with --live --copy-storage-allon destination host: $ ls -lh 3129b8a8-eca4-4b05-878a-66c2771b501f gives me 11GB $ qemu-img info 3129b8a8-eca4-4b05-878a-66c2771b501f image: 3129b8a8-eca4-4b05-878a-66c2771b501f file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 817M cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 16 Is there a way to keep the backing file reference for live migration or planned development (if this file is also available on the destination host)? I also tried with --copy-storage-inc but the disk image on the destination is invalid as it lost the backing file and only copied the diff, so the base image files are gonne. Moreover, the file size on the disk is also of 10GB with that parameter. Regards, Marc-Aurèle Brothier Exoscale
Marc-Aurèle Brothier - Exoscale
2016-Mar-03 14:11 UTC
Re: [libvirt-users] Live migration - backing file
I forgot to say: I'm using libvirt 1.2.15> On 03 Mar 2016, at 11:06, Marc-Aurèle Brothier - Exoscale <marco@exoscale.ch> wrote: > > Hi! > > I'm testing the live migration on libvirt + KVM, the VMs are using non-shared local storage only. If I run a live migration with --copy-storage-full, the final disk file on the remote host after the migration has a full blown size of the specified value (10G) in my case, instead of the few MB on the source host before the migration. Running qemu-img I can see that the ref for the backing file is gone. > > on source host: > $ ls -lh 3129b8a8-eca4-4b05-878a-66c2771b501f gives me 18MB > $ qemu-img info 3129b8a8-eca4-4b05-878a-66c2771b501f > image: 3129b8a8-eca4-4b05-878a-66c2771b501f > file format: qcow2 > virtual size: 10G (10737418240 bytes) > disk size: 17M > cluster_size: 65536 > backing file: /var/lib/libvirt/images/34fa65ce-483b-4ffa-88f8-75f6ebf670c1 > Format specific information: > compat: 1.1 > lazy refcounts: false > refcount bits: 16 > corrupt: false > >>> I run a migration with --live --copy-storage-all > > on destination host: > $ ls -lh 3129b8a8-eca4-4b05-878a-66c2771b501f gives me 11GB > $ qemu-img info 3129b8a8-eca4-4b05-878a-66c2771b501f > image: 3129b8a8-eca4-4b05-878a-66c2771b501f > file format: qcow2 > virtual size: 10G (10737418240 bytes) > disk size: 817M > cluster_size: 65536 > Format specific information: > compat: 0.10 > refcount bits: 16 > > Is there a way to keep the backing file reference for live migration or planned development (if this file is also available on the destination host)? > > I also tried with --copy-storage-inc but the disk image on the destination is invalid as it lost the backing file and only copied the diff, so the base image files are gonne. Moreover, the file size on the disk is also of 10GB with that parameter. > > Regards, > > Marc-Aurèle Brothier > Exoscale > > _______________________________________________ > libvirt-users mailing list > libvirt-users@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users >
Apparently Analagous Threads
- Re: Migration problem - takes 5 minutes to start moving the memory
- Migration problem - takes 5 minutes to start moving the memory
- Re: Migration problem - takes 5 minutes to start moving the memory
- Re: Migration problem - takes 5 minutes to start moving the memory
- grep/sed help