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