[ovirt-users] Re: storage use after storage live migration
Hi,
On 3/19/20 5:29 PM, Strahil Nikolov wrote:
On March 19, 2020 2:34:16 PM GMT+02:00, Rik Theys
<Rik.Theys(a)esat.kuleuven.be> wrote:
> Hi,
>
> We are in the process of migrating our VM's from one storage domain to
> another. Both domains are FC storage.
>
> There are VM's with thin provisioned disks of 16G that currently only
> occupy 3G according to the interface. When we live migrate the disks
> (with the VM running), I can see that a snapshot is being taken and
> removed afterwards.
>
> After the storage migration, the occupied disk space on the new storage
> domain is 6G. Even for a VM that hardly has any writes. How can I
> reclaim this space? I've powered down the VM and did a sparsify on the
> disk but this doesn't seem to have any effect.
>
> When I do a storage migration of a VM with a thin provisioned disk that
> is down during the migration, the used disk space does not increase.
>
> VM's with fully allocated disks also don't seem to exhibit this
> behavior.
>
> My storage domain now also contains VM with more occupied storage space
> and the size of the disk?? There are no snapshots listed for those
> disks. Is there a way to clean up this situation?
>
> Regards,
>
> Rik
Are you sure that you zeroed out the empty space?
I would enable the trim option for the VMs' disks, then run fstrim from the vm and
last try to sparsify ?
I've enabled lvm discards and ran fstrim. It indicates
blocks where
freed, but the disk size in oVirt has not reduced.
If it's linux, you can do storage migration from the OS.
You mean add a disk from the new storage domain and use pvmove?
I'm not sure I've explained my issue well enough.
1. If I have a running VM with a 16G disk, of which oVirt tells me the
actual size is now 3G, and I live migrate it to my new storage domain,
the actual size grows to 7G.
2. If I do the same with a similar VM that is down, there is no increase
in size.
3. If I live migrate a VM with a preallocated disk, I notice that the
"actual size" increases during the migration (and the type switched to
thin provisioned), but the additional space is reduced again (and the
type switched back) after the migration finishes.
My question is how do I reduce the actual size of the disk again in
scenario 1? If the additional used space can be freed in scenario 3, why
not in scenario 1?
Regards,
Rik
Best Regards,
Strahil Nikolov
--
Rik Theys
System Engineer
KU Leuven - Dept. Elektrotechniek (ESAT)
Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee
+32(0)16/32.11.07
----------------------------------------------------------------
<<Any errors in spelling, tact or fact are transmission errors>>