[libvirt-users] Questions and a blockpull issue
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. 2. Should not virt-manager show the sparsed disk size instead of actual reserved size of a vm? 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. 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@KVM libvirt]# virsh snapshot-create-as CO1 capture1 "CO1s first snapshot test" --disk-only --atomic [root@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 [root@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 Best, Abbas.
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@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@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@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@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@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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. Hm. I did find old bash_completion files here in mailing list archive. Gonna borrow from there.
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.
Thanks. That does make sense. I was trying to pull from the backing image but wanted to flat down snapshot image and backing image. Not specifying --base exactly does what I want. Two more quick questions though. 1. "virsh blockcommit" would be opposite to blockpull, right? But sing it with latest stable kvm 1.2.0 tells that this feature is not yet supported. Is it still being developed? 2. I assume that there is no need to quiesce the image while creating a snapshot or after a blockpull since the pull function works at block level to avoid fs corruption. Please correct me if I am wrong. I am gonna be testing with a few kvm domains running database servers which usually are highly vulnerable to db corruption issues if image files are manhandled while data is being accessed.
[root@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?
The Fedora wiki currently shows the reverse argument order. http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots /Abbas
On 10/22/2012 01:18 PM, Abbas wrote:
Thanks. That does make sense. I was trying to pull from the backing image but wanted to flat down snapshot image and backing image. Not specifying --base exactly does what I want.
Good to hear. Remember, with blockpull, --base is the point in the chain that becomes the new backing image of the active layer, omitting --base says no backing image at all.
Two more quick questions though.
1. "virsh blockcommit" would be opposite to blockpull, right? But sing it with latest stable kvm 1.2.0 tells that this feature is not yet supported. Is it still being developed?
The qemu side is in qemu.git, and will be released in December as part of qemu 1.3. The libvirt side is in libvirt.git, and will be released in November as part of libvirt 1.0.0. But you are correct that there are no released versions that support blockcommit yet.
2. I assume that there is no need to quiesce the image while creating a snapshot or after a blockpull since the pull function works at block level to avoid fs corruption. Please correct me if I am wrong.
For snapshots, that all depends on what you want to do with the snapshot - if you want to ever revert to the snapshot (and boot from that state), then quiescing makes sense; but if snapshots is only an intermediate step as part of a larger sequence of operations and you will then remove the intermediate files via blockpull and/or blockcommit, then quiescing is not necessary.
I am gonna be testing with a few kvm domains running database servers which usually are highly vulnerable to db corruption issues if image files are manhandled while data is being accessed.
Thankfully, live snapshot, live block pull, and live block commit have all been designed to avoid image corruption while qemu continues to run.
The Fedora wiki currently shows the reverse argument order.
Thanks for the pointer; I'm updating that page now. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 10/23/2012 12:51 AM, Eric Blake wrote:
The qemu side is in qemu.git, and will be released in December as part of qemu 1.3. The libvirt side is in libvirt.git, and will be released in November as part of libvirt 1.0.0. But you are correct that there are no released versions that support blockcommit yet. I think I can survive with blockpull for now. Thanks for confirming :)
For snapshots, that all depends on what you want to do with the snapshot - if you want to ever revert to the snapshot (and boot from that state), then quiescing makes sense; but if snapshots is only an intermediate step as part of a larger sequence of operations and you will then remove the intermediate files via blockpull and/or blockcommit, then quiescing is not necessary. Gotcha! Thankfully, live snapshot, live block pull, and live block commit have all been designed to avoid image corruption while qemu continues to run. This is really awesome. Been waiting for something like this since ages. Gives libvirt+kvm quite a good competitive edge over its counterparts.
The Fedora wiki currently shows the reverse argument order.
http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots Thanks for the pointer; I'm updating that page now. :)
On 10/22/2012 03:08 PM, Abbas wrote:
On 10/23/2012 12:51 AM, Eric Blake wrote:
The qemu side is in qemu.git, and will be released in December as part of qemu 1.3. The libvirt side is in libvirt.git, and will be released in November as part of libvirt 1.0.0. But you are correct that there are no released versions that support blockcommit yet. I think I can survive with blockpull for now. Thanks for confirming :)
blockpull is already supported with qemu 0.10.0 and qemu 1.2. blockcommit is the new feature for libvirt 1.0.0 and qemu 1.3. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Thanks for the heads up. qemu 1.3 definitely looks exciting.. ! On 10/23/2012 07:24 AM, Eric Blake wrote:
On 10/22/2012 03:08 PM, Abbas wrote:
On 10/23/2012 12:51 AM, Eric Blake wrote:
The qemu side is in qemu.git, and will be released in December as part of qemu 1.3. The libvirt side is in libvirt.git, and will be released in November as part of libvirt 1.0.0. But you are correct that there are no released versions that support blockcommit yet. I think I can survive with blockpull for now. Thanks for confirming :) blockpull is already supported with qemu 0.10.0 and qemu 1.2. blockcommit is the new feature for libvirt 1.0.0 and qemu 1.3.
On 10/23/2012 12:51 AM, Eric Blake wrote:
For snapshots, that all depends on what you want to do with the snapshot - if you want to ever revert to the snapshot (and boot from that state), then quiescing makes sense; but if snapshots is only an intermediate step as part of a larger sequence of operations and you will then remove the intermediate files via blockpull and/or blockcommit, then quiescing is not necessary.
Oh and one last question. Since qemu-ga does not support quiescing Windows domains, what do you suggest in that case. I know this is not a libvirt specific question but I shall appreciate any ideas. /Abbas
On 10/22/2012 11:55 PM, Abbas wrote:
On 10/23/2012 12:51 AM, Eric Blake wrote:
For snapshots, that all depends on what you want to do with the snapshot - if you want to ever revert to the snapshot (and boot from that state), then quiescing makes sense; but if snapshots is only an intermediate step as part of a larger sequence of operations and you will then remove the intermediate files via blockpull and/or blockcommit, then quiescing is not necessary.
Oh and one last question. Since qemu-ga does not support quiescing Windows domains,
What gives you that impression? That's actually one of the things that qemu-ga is SUPPOSED to be able to do, if you install it into your Windows guest.
what do you suggest in that case. I know this is not a libvirt specific question but I shall appreciate any ideas.
Questions and bug reports about what qemu-ga can or can't do on Windows are probably better directed to the qemu mailing lists. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 10/23/2012 07:27 PM, Eric Blake wrote:
What gives you that impression? That's actually one of the things that qemu-ga is SUPPOSED to be able to do, if you install it into your Windows guest.
Compiled the latest qemu-ga.exe with mingw32from git, installed it as a service on a VM but snapshotting with quiesce is failing. error: internal error unable to execute QEMU command 'guest-fsfreeze-freeze': this feature or command is not currently supported
Questions and bug reports about what qemu-ga can or can't do on Windows are probably better directed to the qemu mailing lists.
Already did! - - abbas
participants (2)
-
Abbas -
Eric Blake