[Libvir] [for discussion only] virDomainBlockPeek preliminary implementation

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. + * + * (Note that in the local case you might try to open the + * block device or file directly, but that won't work in the + * remote case, nor if you don't have sufficient permission. + * Hence the need for this call). + * + * 'path' must be a device or file corresponding to the domain. + * In other words it must be the precise string returned in + * a <disk><source dev='...'/></disk> from + * virDomainGetXMLDesc. + * + * 'offset' and 'size' represent an area which must lie entirely + * within the device or file. 'size' may be 0 to test if the + * call would succeed. + * + * 'buffer' is the return buffer and must be at least 'size' bytes. + * + * Returns: 0 in case of success or -1 in case of failure. + */ +int +virDomainBlockPeek (virDomainPtr dom, + const char *path, + long long offset /* really 64 bits */, + size_t size, + void *buffer) The patch doesn't include: - remote - qemu - Xen < 3.0.3 inactive domains I will add these if I get favourable feedback. 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

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 the ned for every application caller to repeat the magic for sniffing partition table types. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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

Jim Meyering's been sending me private emails all afternoon about this and that wrong in this patch, so here's an update :-) It fixes: - unnecessary initialisations removed - changed the dumb for(;;) putchar into an fwrite call - cure multiple memory leaks in virsh - fixed const-correctness of the callback function - use a wrapper around strtoll - replaced some !strcmp with STREQ (etc) - use AC_SYS_LARGEFILE to get portable support for 64-bit file offsets 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
participants (2)
-
Daniel P. Berrange
-
Richard W.M. Jones