On 05/17/2012 05:10 AM, Pankaj Rawat wrote: > Hi all, > I am currently doing live migration task KVM/qemu based virtual machine > > I want to know what is exact difference between following: > copy-storage-all option and copy-storage-inc option copy-storage-all maps to qemu's 'blk' option, documented as: block migration, full disk copy [I think that means that qemu will copy the entire disk image onto the destination] copy-storage-inc maps to qemu's 'inc' option, documented as: incremental disk copy [I think that means that qemu will copy only the top file of a backing chain, and assume that all other base files in the backing chain are shared; but I could be wrong] You might get better information from the qemu list on what these options are supposed to do, and the difference between them. > what are necessary steps for doing both? Both options are relatively undertested at the moment, and patches are welcome to help improve the matter. In particular, copy-storage-all currently has the lousy drawback that you, the user, must pre-create the destination file with correct permissions and SELinux label (libvirt _really_ should be doing this itself). > > as per my knowledge 'copy-stoarage -all' migrates whole disk image to destination where 'copy-storage-inc' is when we use backing files for guest . > with copy-storage-inc we require backing image on both destination and source but I want to know how destination guest get its base image how they share base image? > Is there any link need to be created for this base image? or is there need for NFS ? > > How to set up both options ? what are necessary steps need to follow before starting migration ? > Please help me! This is the sort of question that if anyone has ever successfully done a non-shared migration (I personally have not tried it), then it would be nice to document the steps they used on the wiki, as you are not the first to ask about it. > > The contents of this e-mail and any attachment(s) are confidential and Unfortunately, you have posted to a publicly-archived list, where this disclaimer cannot be enforced. It is considered better netiquette to post from a personal account rather than forcing us to read your employer's legalese. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list