8:45 p.m.
On Sat, Feb 22, 2020, 13:02 Alan G <alan+ovirt(a)griff.me.uk> wrote:
I'm not really concerned about the reporting aspect, I can look in the storage vendor
UI to see that. My concern is: will oVirt stop provisioning storage in the domain because
it *thinks* the domain is full. De-dup is currently running at about 2.5:1 so I'm
concerned that oVirt will think the domain is full way before it actually is.
Not clear if this is handled natively in oVirt or by the underlying lvs?
Because oVirt does not know about deduplication or actual allocation
on the storage side,
it will let you allocate up the size of the LUNs that you added to the
storage domain, minus
the size oVirt uses for its own metadata.
oVirt uses about 5G for its own metadata on the first LUN in a storage
domain. The rest of
the space can be used by user disks. Disks are LVM logical volumes
created in the VG created
from the LUN.
If you create a storage domain with 4T LUN, you will be able to
allocate about 4091G on this
storage domain. If you use preallocated disks, oVirt will stop when
you allocated all the space
in the VG. Actually it will stop earlier based on the minimal amount
of free space configured for
the storage domain when creating the storage domain.
If you use thin disks, oVirt will allocate only 1G per disk (by
default), so you can allocate
more storage than you actually have, but when VMs will write to the
disk, oVirt will extend
the disks. Once you use all the available space in this VG, you will
not be able to allocate
more without extending the storage domain with new LUN, or resizing
the LUN on storage.
If you use Managed Block Storage (cinderlib) every disk is a LUN with
the exact size you
ask when you create the disk. The actual allocation of this LUN
depends on your storage.
Nir
---- On Fri, 21 Feb 2020 21:35:06 +0000 Nir Soffer
<nsoffer(a)redhat.com> wrote ----
On Fri, Feb 21, 2020, 17:14 Alan G <alan+ovirt(a)griff.me.uk> wrote:
Hi,
I have an oVirt cluster with a storage domain hosted on a FC storage array that utilises
block de-duplication technology. oVirt reports the capacity of the domain as though the
de-duplication factor was 1:1, which of course is not the case. So what I would like to
understand is the likely behavior of oVirt when the used space approaches the reported
capacity. Particularly around the critical action space blocker.
oVirt does not know about the underlying block storage thin provisioning implemention so
it cannot help with this.
You will have to use the underlying storage separately to learn about the actual
allocation.
This is unlikely to change for legacy storage, but for Managed Block Storage (conderlib)
we may have a way to access such info.
Gorka, do we have any support in cinderlib for getting info about storage alllocation and
deduplication?
Nir
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BKCQYELRW5X...