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>