On Sat, Feb 22, 2020, 13:02 Alan G <alan+ov...@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 <nsof...@redhat.com> wrote > ---- > > > > On Fri, Feb 21, 2020, 17:14 Alan G <alan+ov...@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@ovirt.org > To unsubscribe send an email to users-le...@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/BKCQYELRW5XP5BVDPSJJ76YZD3N37LVF/ > > > _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/NVBOY24VWN6TKWJKRN345WOGJRF55XJB/
