[Libvir] [for discussion only] virDomainBlockPeek preliminary implementation

[Richard W.M. Jones]

Daniel P. Berrange wrote:
> On Tue, Oct 16, 2007 at 03:42:50PM +0100, Richard W.M. Jones wrote:
>> The attached patch (for discussion only) adds a virDomainBlockPeek call, 
>> allowing callers to peek into the block devices of domains.
>>
>> +/**
>> + * virDomainBlockPeek:
>> + * @dom: pointer to the domain object
>> + * @path: path to the block device
>> + * @offset: offset within block device
>> + * @size: size to read
>> + * @buffer: return buffer (must be at least size bytes)
>> + *
>> + * This function allows you to read the contents of a domain's
>> + * disk device.
>> + *
>> + * Typical uses for this are to determine if the domain has
>> + * written a Master Boot Record (indicating that the domain
>> + * has completed installation), or to try to work out the state
>> + * of the domain's filesystems.
> 
> IMHO, if we had storage management APIs this use case could be better
> handled by simply having a piece of metadata associated with the volume.
> eg, you could just run    virVolumeDumpXML()  and look for an element
> 
>   <parttable type='mbr'/>
> 
> Lack of such an element would indicate it was not partitioned. It
> could also return 'gpt' for the new fangled EFI bios partitioning
> scheme, or whatever format BSD/Solaris/Sun uses. This would avoid 

It'd be a nice feature if we had it, but the implementation is surely 
very complicated.  virDomainBlockPeek punts the implementation off to 
the libvirt user, but ...

> the ned for every application caller to repeat the magic for sniffing
> partition table types.

... I would hope that we can use libparted with some sort of "virtual 
filesystem" concept built on top of fundamental operations like 
virDomainBlockPeek to handle this.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071016/2a0c15e0/attachment-0001.bin>