Hi Eric,
Thanks for the mail. I tried all possibilities without changing the libvirt's library.
I tried editing the xml in statefile. But It never worked as we expect. It doesnt resume
from the state, it boots the OS from scratch. I am not sure about the exact issue. I
checked the code, I think libvirt (qemu-driver) saves the length of the xml file along
with its header, I didnt check the restore part, but I think they do a validation check
before restoring to make sure the length of the xml stored(its just a char*) is the same
as mentioned in the header. Please let me know your views. I will be happy if there is
anything I can do via implementation to make it work according to my specification. I am
thinking of passing the new xml file as another argument and editing the libvirt code to
consider that xml. Please let me know whether it is viable and whether it will fix the
problem. Thanks a lot!
-
Regards,
Sethuraman Subbiah
Graduate Student - NC state University
M.S in Computer Science
On Jul 5, 2011, at 12:50 PM, Eric Blake wrote:
On 07/02/2011 09:59 AM, sethuraman subbiah wrote:
> Hi ,
>
> I am trying to perform offline migration (i.e) Create an incremental image using the
qcow format, transfer the vm memory state to a state fie.Use the image and statefile
together as a template. Now create a new vm using the template. I can successfully do it
using the following commands :
>
> Save phase :
> stop
> migrate "exec:gzip -c > STATEFILE.gz"
> qemu-img
> qemu-img create -b BASE_img -f qcow2 INCRE_img
>
> Restore phase :
> qemu-kvm -m 1024 -hda INCRE_img -incoming "exec: gzip -c -d STATEFILE.gz"
>
> And it works fine. But I am not able to find the vm with virt-manager or other
libvirt based tools.
>
> If I use :
> virsh save <dom_id> STATEFILE
>
> I can restore using "virsh restore STATEFILE" but I want to associate this
with the incremental image that I created, but I dont know how. I think it saves the
existing vm's xml file along with the STATEFILE, thus I am not able to change the disk
image to the incremental image.
>
> Thus ,
> 1. Either I should find a way to make vms created using qemu-kvm appear in
libvirt-based tools.
There is a patch series pending to teach libvirt how to attach to a vm
created by raw invocation of qemu-kvm:
https://www.redhat.com/archives/libvir-list/2011-July/msg00111.html
But ultimately, our preference is to do everything through libvirt, to
isolate you from incompatible changes in qemu-kvm or to ease the
transition to any other type of hypervisor that supports similar
functionality.
>
> OR
>
> 2. Find a way to associate the virsh save STATEFILE with a incremental image.
Oh, I see what you mean. Right now, the 'virsh save' statefile, _as
part of its saved state_, includes a verbatim copy of the XML in use at
the time the snapshot was created. So even if you do 'virsh save', then
manually use 'qemu-img' to create incremental snapshots on top of those
images (or even my proposed RFC for virStorageVolSnapshot APIs for
managing incremental images from virsh rather than having to use
qemu-img:
https://www.redhat.com/archives/libvir-list/2011-June/msg00761.html),
you are still constrained in how to get those new disk images injected
back into the state file. You can't just do 'virsh edit dom' to change
the name of the files that are backing each disk device, because 'virsh
restore' will _undo_ those changes as part of reverting back to the XML
that was stored verbatim in the statefile.
Your only recourse at the moment is to actually edit the XML embedded
within the statefiles, which is not appealing (text-editing a binary
file is dangerous).
This sounds like something worth working into the existing
virDomainSnapshot APIs; right now, when invoked on an inactive domain,
those APIs create _internal_ qcow2 snapshots (using qemu-img under the
hood for all disks tied to the domain); but as you are pointing out, it
is the _external_ incremental snapshot layout (a new file with the old
file serving as the backing image) that may better suit your needs.
Furthermore, that fits in with the fact that I'm trying to extend
virDomainSnapshot APIs to support an upcoming qemu monitor command for
online disk snapshots, and that monitor command will only support
external snapshots, so I already have to figure out how to make that
command manage the aspect of changing the file name associated with a
disk to swap over to the new incremental image. Therefore, it seems
like whether online (new qemu monitor command) or offline, it makes
sense to enhance the virDomainSnapshot behavior to support external
images, at which point you will have the behavior of properly
associating a statefile with new file names for incremental images.
Meanwhile, it may mean that it might be worth adding some APIs to make
it easier to edit the XML embedded within a statefile image. We
recently introduced the virDomainMigrate2 API, which takes an optional
XML rendition to use on the destination, and which is validated against
the original XML as being guest-compatible (that is, items related to
the host, such as a file name used as the backing image for a disk, can
be altered, while items related to the guest, such as the fact that the
guest expects a virtual disk in the first place, must not be altered).
So a new API that lets you provide an alternate XML for use with an
existing state file could use the same XML compatibility checking, to
ensure that the XML being injected into the state file is safe; this
would allow you to change the name of a host file to use for the guest
disk on the next 'virsh restore'. Certainly some food for thought that
I'll keep in mind as I work on snapshot code.
>
> Any help or hint with respect to these will be very helpful.
It's a work under progress, so keep your thoughts coming to make sure we
are not precluding useful modes of operation as we introduce new APIs or
new flags to existing APIs.
> I am try to do cloning with minimal cost. This takes only 25 seconds ( to create
STATEFILE) and creating incremental image is instantatenous . But I want to use the vm
monitoring code based on libvirt. And it makes life difficult.
>
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org