[libvirt-users] Questions and a blockpull issue

[Eric Blake]

On 10/21/2012 08:10 AM, Abbas wrote:
> Coming off of xen environment; still testing with kvm, just a few 
> questions:
> 
> 1. What is the roadmap for release of qemu-kvm 1.1 and libvirt 0.10.2 for 
> el6, cause I had to compile from upstream to get the latest stuff.

RHEL-related questions are best asked to Red Hat, via your support
contract - upstream doesn't particularly know or care which
versions+backports RHEL will choose to use.

> 2. Should not virt-manager show the sparsed disk size instead of actual 
> reserved size of a vm? 

Maybe, but virt-manager questions go to virt-tools-list at redhat.com, as
libvirt does not control virt-manager (although there may also be some
libvirt patches needed, if virt-manager needs enough API enhancements to
get at that information).

> 3. Where is the virsh bash_completion conf.d file from upstream; since el6 
> rpm for it seems have tab completion built right into virsh shell.

Sadly, we do not yet have a bash_completion file for virsh yet.  It's
been on my back-burner of things that would be nice to write, if I ever
had time, and I even think there have been some proposed patches, but
none upstream yet.

> 4. Created a disk-only snapshot of a vm CO1 called capture1 but the syntax 
> of blockpulling seems to be opposite from what has been advertised on 
> Fedora and other relative wikis. Check below and the error with first 
> blockpull command.
> 
> [root at KVM libvirt]# virsh snapshot-create-as CO1 capture1 "CO1s first 
> snapshot test" --disk-only --atomic

I'm guessing that your original disk was named col.img, and so this
snapshot creates the chain:

col.img <- col.capture1

where col.img is now the backing image, and where the domain XML now
shows col.capture1 as the active disk.

> 
> [root at KVM libvirt]# virsh -d 0 blockpull CO1 --path /home/vms/co1.img 
> --bandwidth 500 --base /home/vms/co1.capture1 
> blockpull: domain(optdata): CO1
> blockpull: path(optdata): /home/vms/co1.img
> blockpull: bandwidth(optdata): 500
> blockpull: base(optdata): /home/vms/co1.capture1
> blockpull: found option <domain>: CO1
> blockpull: <domain> trying as domain NAME
> error: invalid argument: No device found for specified path

What does: 'virsh domblklist CO1' show?  Only the names in that table
are acceptable for the --path argument of 'blockpull'.  If my above
analysis about your backing chain is correct, then you want to use
/home/vms/co1.capture1 as the --path argument (you can also use the
simpler 'vda' if that is the device name that owns the
/home/vms/co1.capture1 disk image).

Also, what are you trying to pull?  If you are starting with the chain:

co1.img <- co1.capture1

then pulling with a --base of co1.img is a no-op (co1.img is ALREADY the
backing file of co1.capture1); the only other alternative is to pull
without a --base argument, which moves all of co1.img contents into
co1.capture1 and leaves co1.capture1 without a backing image.  Partial
pull (where --base is specified) only makes sense when you have a chain
longer than 2 files.

> 
> [root at KVM libvirt]# virsh -d 0 blockpull --domain CO1 --path 
> /home/vms/co1.capture1  --base /home/vms/co1.img --verbose --wait
> blockpull: domain(optdata): CO1
> blockpull: path(optdata): /home/vms/co1.capture1
> blockpull: base(optdata): /home/vms/co1.img
> blockpull: verbose(bool): (none)
> blockpull: wait(bool): (none)
> blockpull: found option <domain>: CO1
> blockpull: <domain> trying as domain NAME
> Block Pull: [100 %]
> Pull complete

That is correct (no-op) usage.  What wikis are you referring to that led
you to the assumption that this is reversed argument order?

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20121022/97c4456d/attachment.sig>