[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PATCH] Don't use libvirt for volume information when converting with libvirtxml

On 26/01/11 15:00, Richard W.M. Jones wrote:
On Wed, Jan 26, 2011 at 02:34:49PM +0000, Matthew Booth wrote:
Unless you're lucky, the target volumes won't be in a storage pool, so libvirt
will return an error. For libvirtxml we know that the storage is local, so we
can inspect it directly. We use qemu-img to determine format and file size.
+    # Use the output of qemu-img to inspect the path
+    open(my $qemuimg, '-|', 'env', 'LANG=C', 'qemu-img', 'info', $path)
+        or die("Unable to execute qemu-img: $!");

You need to make sure qemu-img is an explicit Requires in the
spec file, ie:

   Requires: /usr/bin/qemu-img

Good point, I'll make sure it goes in.

and it should be mentioned in the README file too for other distros.
Also other distros name this differently, eg: 'kvm-qemu-img' and maybe
other variations.

Not sure how I'd handle this for the moment. I think I'll file this under 'fix when it happens'.

+    # For $usage, $is_sparse and $is_block, we need to know if it's a block
+    # device
+    # N.B. qemu-img's 'disk size' output isn't useful here
+    my ($usage, $is_sparse, $is_block);
+    if (-b $path) {
+        $is_block = 1;
+        $usage = $size;
+        $is_sparse = 0;
+    } else {
+        $is_block = 0;
+        my $st = stat($path);
+        $usage = $st->blocks * 512;
+        $is_sparse = $usage<  $size ? 1 : 0;
+    }
+    die("size ($size)<  usage ($usage)") if $size<  $usage;

Agreed that qemu-img gets it wrong:

# qemu-img info /dev/vg_pin/CentOS5x64
image: /dev/vg_pin/CentOS5x64
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 0

*but* I'm not sure your code is correct.  I don't know if $st->blocks
is always valid, and you can't assume 512-sized blocks.

I suggest calling 'blockdev --getsize64', with the caveats above about
dependencies and README file.

I observed that qemu-img *does* get the correct 'virtual size' for both block devices and regular files. I don't want to use more external tools than required, so I'd prefer not to call blockdev. Why wouldn't you trust qemu-img here? Incidentally, its 'disk size' value is correct for regular files, but it isn't output in bytes. This is the principal reason I ignore it. I could update the comment to reflect that.

As for $st->blocks, any idea when it wouldn't be valid? As it happens, you can assume that this is in units of 512 (see man 2 stat). Although block sizes have moved on, I guess this value has been grandfathered for compatibility.

Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]