9:10 a.m.
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.
10:35 a.m.
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(a)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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2:18 p.m.
> 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
2:51 p.m.
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.
http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots
Thanks for the pointer; I'm updating that page now.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4:08 p.m.
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.
:)
9:24 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
9:27 p.m.
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.
12:55 a.m.
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
9:27 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
6:23 p.m.
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
4394
days inactive
4396
days old
9 comments
2 participants
participants (2)
-
Abbas -
Eric Blake