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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
