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-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
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 >
Maybe Matching 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