10:35 p.m.
10:45 p.m.
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
10:59 p.m.
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(a)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
11:03 p.m.
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
4:10 p.m.
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
3687
days inactive
3689
days old
4 comments
3 participants
participants (3)
-
Eric Blake -
Jianfeng Tang -
Richard W.M. Jones