[libvirt] RFC: exposing backing store allocation in domain xml

[Eric Blake]

[revisiting something that finally surfaced to the top of my todo list]

On 08/07/2014 03:57 AM, Peter Krempa wrote:
> On 08/06/14 18:36, Eric Blake wrote:
>> Adam Litke has been asking if I can expose watermark information from\
> 
> <bikeshedding>
> I'd be glad if we stopped calling this watermark. The wiki
> disambiguation article states:
> 
> <citation>
> A watermark is a recognizable image or pattern in paper used to identify
> authenticity.
> 
> Watermark or watermarking can also refer to:
> 
> In digital watermarks and digital security[edit]
> Watermark (data file), a method for ensuring data integrity which
> combines aspects of data hashing and digital watermarking
> Watermark (data synchronization), directory synchronization related
> programming terminology
> High-water mark (computer security),

We are using it in the sense of high-water mark.  Etymology-wise, it
goes back to the days of loading boats - you would paint a line called
the high watermark; as the boat was weighed down with more cargo, you
had to stop loading when that line touched the water, or risk sinking
the boat.  In the same vein, someone running on expandable underlying
storage can let the guest consume until it hits the watermark, at which
point the storage must be grown to avoid sinking the guest with an
out-of-space event.

But I'm open to the idea of any other terminology...  For now, calling
it allocation is good enough, since that is the term I will be putting
in the XML.

>>
>> The other idea I've had is to expand the <domain> XML to expose more
>> information about backing chains, including to make it expose details
>> that are redundant with virDomainBlockInfo() for the top level, or maybe
>> even what virDomainBlockStatsFlags() reports.  Here, we have a bit of a
>> choice - storage volume XML was inconsistent on which attributes were
>> siblings to <target> (such as <capacity>) vs. children (such as
>> <timestamps>); it might be nicer to stick all per-file elements at the
>> same level in <disk> XML (probably as siblings to <source>).  On the
>> other hand, I strongly feel that <compat> is a feature of the <format>,
>> so it should have been a child rather than a sibling.  So, as an example
>> of what the XML might look like:
>>
>>     <disk type='file' device='disk'>
>>       <driver name='qemu' type='qcow2'>
>>         <compat>1.1</compat>
>>         <features/>
>>       </driver>
>>       <source file='/tmp/snap2.img'/>
>>       <capacity unit='bytes'>12884901888</capacity>
>>       <allocation unit='bytes'>2503548928</allocation>
>>       <physical unit='bytes'>2503548928</allocation>
>>       <permissions>
>>         <mode>0600</mode>
>>         <owner>107</owner>
>>         <group>107</group>
>>         <label>system_u:object_r:virt_content_t:s0</label>
>>       </permissions>
>>       <timestamps>
>>         <atime>1407295598.623411816</atime>
>>         <mtime>1402005765.810488875</mtime>
>>         <ctime>1404318523.313955796</ctime>
>>       </timestamps>
> 
> Both <permissions> and <timestamps> are not entirely useful information
> in runtime.

Maybe not entirely useful, but fairly easy to learn and awfully similar
to storage volume XML.  But we can do this incrementally, the real
request I have is for allocation; and while I think permissions and
timestamps may be useful to shave off later API calls, I don't think it
is a showstopper if they are not present in the first cut that adds
allocation.


>>
>> Again, this is a lot of new information, so it may be wise to add a new
>> flag that must be turned on to request the information.  But adding this
> 
> This definitely needs a flag. We are polluting the XML enough by the
> backing chain now.

Okay, I'll be proposing a patch with the new flag shortly.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140912/74051ff5/attachment-0001.sig>