[libvirt-users] Does libvirt have API to detect image format
I am using backing store when I create my volume. However, the backing store file is from another team, which can be either in raw or in qcow2 format. Is there a libvirt API to detect image format by given an image file? Or I have to run qemu-img?
On 08/11/2014 02:35 PM, Jianfeng Tang wrote:
I am using backing store when I create my volume. However, the backing store file is from another team, which can be either in raw or in qcow2 format.
Is there a libvirt API to detect image format by given an image file? Or I have to run qemu-img?
virStorageVolGetXMLDesc() in the C code ('virsh vol-dumpxml' from the command line), if your volume resides within a storage pool. Furthermore, if there is ANY possibility that the file might be raw but that the volume has been in use by a possibly malicious guest, you CANNOT blindly trust a file probe that says qcow2, because a guest can write header information into a raw disk in order to make probes return qcow2. So take the output with a grain of salt (it is safe to blindly trust a claim of 'raw', but blindly trusting a claim of 'qcow2' is risky if you don't know the history behind the image). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Unfortunately my backing store file is not in a volume. So I guess I cannot use that method. On 8/11/14 3:45 PM, "Eric Blake" <eblake@redhat.com> wrote:
On 08/11/2014 02:35 PM, Jianfeng Tang wrote:
I am using backing store when I create my volume. However, the backing store file is from another team, which can be either in raw or in qcow2 format.
Is there a libvirt API to detect image format by given an image file? Or I have to run qemu-img?
virStorageVolGetXMLDesc() in the C code ('virsh vol-dumpxml' from the command line), if your volume resides within a storage pool. Furthermore, if there is ANY possibility that the file might be raw but that the volume has been in use by a possibly malicious guest, you CANNOT blindly trust a file probe that says qcow2, because a guest can write header information into a raw disk in order to make probes return qcow2. So take the output with a grain of salt (it is safe to blindly trust a claim of 'raw', but blindly trusting a claim of 'qcow2' is risky if you don't know the history behind the image).
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 08/11/2014 02:59 PM, Jianfeng Tang wrote: [please don't top-post on technical lists]
Unfortunately my backing store file is not in a volume. So I guess I cannot use that method.
It's very easy to create a storage pool for an arbitrary directory, at which point you can then use the virStorageVol* API on that file. The only reason we make you go through the virStoragePool* hoop rather than acting directly on files is so that we can support remote connections sanely (a volume name in relation to a pool is unambiguous, whereas a file name is ambiguous on whether it is on the client's machine or the server's machine). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Mon, Aug 11, 2014 at 08:35:46PM +0000, Jianfeng Tang wrote:
I am using backing store when I create my volume. However, the backing store file is from another team, which can be either in raw or in qcow2 format.
Is there a libvirt API to detect image format by given an image file? Or I have to run qemu-img?
Nothing wrong with running `qemu-img info' IMHO. Libguestfs has some disk detection features, including format, backing file, virtual size. And of course it can go a lot deeper into the disk content itself using libguestfs inspection. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
participants (3)
-
Eric Blake -
Jianfeng Tang -
Richard W.M. Jones