On Wed, Jul 02, 2008 at 05:05:06PM +0100, John Levon wrote: > > I didn't go the "qemu-info" route (yet), as it only produces > human-readable output: I didn't see a way to get it to print just the > file format. Yes that kinda sucks. When I added the storage pool/volume APis to libvirt I basically re-implemented the file magic checks directly rather than parse qemu-info. Having looked this, I'm wondering whether we need to add some more storage APIs which just work on ad-hoc file paths, rather than the higher level pool/volume objects, to let us query metdata about them without using qemu-info. Not that we should wait for this before adding the virt-convert command. Once we have an impl decided upon it'll give a better picture of what we need to address in the libvirt APIs Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
