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

[Matthew Booth]

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.

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

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