This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RH6VeLgsV4aCdphWinrtX2PUWEbHMwDj6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/19/2014 12:10 PM, R P Herrold wrote:

...

And the following dependencies still open: Bug 1041569 - [NFR] libvirt: Returning the watermark for all=20 the images opened for writing =20 https://www.redhat.com/archives/libvir-list/2014-August/msg00207.html =20 wherein you refer to a 'watermark'. To me as a non-lingo=20 aware (as to libvirt / libguestfs) developer, a watermark is a=20

=20 I was running down the open ovirt bugs, and notice this one,=20 which has an outlink to a post by you (Eric) on a mailing lsit=20 last month =20 pattern overlaid onto an image (a pattern placed on the glue=20 side of a postage stamp, or a 'DRAFT" notice on a document) =20 I _think_ you are referring to a 'high water mark' limit=20 which, if exceeded would result in content being lost (there=20 is mention of ENOSPC) =20 Is this accurate? =20

Close. The terminology intended is indeed high water mark, but more as a measure of when the underlying storage must be enlarged to avoid pausing due to ENOSPC. There won't be actual content loss, as long as the guest is configured to pause on write errors, and the guest can be resumed after storage is enlarged whether or not the high water mark was used to attempt to pre-emptively grow the storage before actually running out of space. On the libvirt list, we decided to go with calling it 'allocation' reporting, rather than 'watermark', because of the confusion in the term watermark.

=20 If so, isn't this information filesystem specific and so=20 something which the outsider 'container' cannot and should be=20 expected to reliably know? (I am thinking here of inode=20 exhaustion even when a Linux type FS seemingly has space per:=20 du ; the problem is worse with a 'sparse' capable filesystem=20 in play; and seems wholly unanswerable with a Windows FS or=20 some other variant) =20 I don't see how the hypervisor could accurately ever know this=20 without 'cracking open' and asking the inside tenant .. and=20 for privacy and data integrity / security reasons, the=20 hypervisor should not ever be doing this

Dynamic storage is common with VDSM which tracks guest storage by using host LVM partitions formatted with qcow2. Qcow2 files can be sparse by nature, so, for example, you can allocate a backing chain base <- active, where base is 30G, and active starts out as a 10G partition. As the guest causes more and more COW to differ from base, qemu will report higher and higher allocation values, and if management is carefully tracking these values, it can resize the LVM volume to 15G prior to pausing the guest when qemu can't write more qcow2 metadata. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --RH6VeLgsV4aCdphWinrtX2PUWEbHMwDj6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUHLnsAAoJEKeha0olJ0NqE5UH/2FKwyJUgOaJCF3QU9Lq8lRh Pa+j+uImpoDIyVFIY4CXmzkf+g90uVJu92vtQU3KnbJ2rslccap8uxV7sOTXB7vZ UztFRKg80akhvPROoYQDSDyof8xksQsawW7y7BtMCZFMuKDrb++gng2TbtFYyLGd izSqqpj5eDM8uvlr4gN4/u/VZ9r+W61ZGiMKBL/TT99/CXRT7S0PsR48jIyMspG6 6a/T+YagN8uRz5C5YMYDS+peN/4bEmVpKdvHkbraRBzQuZaGhWXIUuw1sM2Afr3k Xm3vLWagqdg17DBE8m8O0vbeHVUAQuxivRXmyWfLHTN/Gywyy1HCLENtyz3Y5Ko= =x4Qc -----END PGP SIGNATURE----- --RH6VeLgsV4aCdphWinrtX2PUWEbHMwDj6--