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