7:19 p.m.
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:
=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
> 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
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--