Re: Best choice for copy/clone/snapshot
Ross Boylan wrote: Thanks for all the info. I have one follow up. On Wed, 2009-05-13 at 10:07 +0300, Avi Kivity wrote: As I install software onto a system I want to preserve its state--just the disk state---at various points so I can go back. What is the best way to do this? LVM snapshots. Read up on the 'lvcreate -s' command and option. I may have been unclear. I meant as I install software on the VM. Since some of them are running Windows, they can't do LVM. I am running LVM on my host Linux system. Or are you suggesting that I put the image files on a snapshottable partition? Over time the snapshot seems likely to accumulate a lot of original sectors that don't involve the disk image I care about. Or do you mean I should back each virtual disk with an LVM volume? That does seem cleaner; I've just been following the docs and they use regular files. They say I can't just use a raw partition, but maybe kvm-img -f qcow2 /dev/MyVolumeGroup/Volume10 ? You can certainly use a raw partition, for example qemu-system-x86_64 -drive file=/dev/vg0/guest1,cache=none Does that give better performance? That is the highest performing option, especially with cache=none. The one drawback I see is that I'd have to really take the space I wanted, rather than having it only notionally reserved for a file. Yes, that's a drawback, and there's currently no way around it. I'm not sure how growing the logical volume would interact with qcow... It should work, but I wouldn't recommend it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Best choice for copy/clone/snapshot
Ross Boylan wrote: First, I have a feeling this might be a question I could ask on a qemu list. It is. Is there a way for me to tell which questions should go where? If the question is equally valid for qemu and qemu-kvm, then qemu-devel is the correct forum. Is it OK to ask here? Sure, we aren't sticklers for this sort of thing. As I install software onto a system I want to preserve its state--just the disk state---at various points so I can go back. What is the best way to do this? LVM snapshots. Read up on the 'lvcreate -s' command and option. First, I think I could just make a copy of the virtual disk, although I haven't seen this suggested anywhere. I assume this will work if the VM is off; Yes. are there other circumstances in which it is safe? You could suspend the guest, either by having it sleep, or externally using ctrl-Z. Since my original virtual disk file isn't really occupying its nominal space, I assume this will be true of the copy too. Second, kvm-img could create a copy on write image. There are several things I don't understand about this. Suppose I go kvm-img -b A.img B.img If I then go on and use A.img as I did before, changing what is on disk, have I screwed up B.img? Yes. If you use an image as a backing store, you promise not to change it. Use B.img instead. Do A.img or B.img have to be qcow2 format? I created a raw image for portability. Only B.img, though it works better if both are qcow2s. Suppose I work for awhile installing new stuff on B.img, and then want to preserve the state. Is kvm-img -b B.img C.img sensible, or is this kind of recursive operation (B.img is already the copy on write version of A.img) not OK? Should work. Does ‘commit [-f fmt] filename’, documented as Commit the changes recorded in filename in its base image. mean commit the recorded changes TO its base image? Yes. It was broken until recently, so use with caution. Here are some other things I think I don't want to do. Please let me know if I'm mistaken. -snapshot on the kvm command line: nothing persistent comes of this (maybe if you commit you update the original image, but you don't get 2). Right. snapshot in the monitor: this snapshots the non-disk state of the VM; further, that state is not guaranteed to work if you later change what is on the disk. I think kvm-img snapshot also accesses these facilities. It snapshots both the disk and non-disk state. You have to use qcow2 for this. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Best choice for copy/clone/snapshot
Thanks for all the info. I have one follow up. On Wed, 2009-05-13 at 10:07 +0300, Avi Kivity wrote: As I install software onto a system I want to preserve its state--just the disk state---at various points so I can go back. What is the best way to do this? LVM snapshots. Read up on the 'lvcreate -s' command and option. I may have been unclear. I meant as I install software on the VM. Since some of them are running Windows, they can't do LVM. I am running LVM on my host Linux system. Or are you suggesting that I put the image files on a snapshottable partition? Over time the snapshot seems likely to accumulate a lot of original sectors that don't involve the disk image I care about. Or do you mean I should back each virtual disk with an LVM volume? That does seem cleaner; I've just been following the docs and they use regular files. They say I can't just use a raw partition, but maybe kvm-img -f qcow2 /dev/MyVolumeGroup/Volume10 ? Does that give better performance? The one drawback I see is that I'd have to really take the space I wanted, rather than having it only notionally reserved for a file. I'm not sure how growing the logical volume would interact with qcow... Ross -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Best choice for copy/clone/snapshot
Ross Boylan wrote: Or do you mean I should back each virtual disk with an LVM volume? Yes, this option is what was meant. That does seem cleaner; I've just been following the docs and they use regular files. They say I can't just use a raw partition, but maybe kvm-img -f qcow2 /dev/MyVolumeGroup/Volume10 ? While new versions of qcow2 have some extensions that let the last-written sector be tracked for use on device-backed partitions, the expectation is that you'll (really) just use the raw partition; qcow2 more than takes back the performance gain from getting your host filesystem out of the loop. I'm not sure how growing the logical volume would interact with qcow... Right -- folks doing this route go raw rather than qcow, so it's just a matter of resizing the partitions / filesystems within the guest. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Best choice for copy/clone/snapshot
First, I have a feeling this might be a question I could ask on a qemu list. Is there a way for me to tell which questions should go where? Is it OK to ask here? As I install software onto a system I want to preserve its state--just the disk state---at various points so I can go back. What is the best way to do this? First, I think I could just make a copy of the virtual disk, although I haven't seen this suggested anywhere. I assume this will work if the VM is off; are there other circumstances in which it is safe? Since my original virtual disk file isn't really occupying its nominal space, I assume this will be true of the copy too. Second, kvm-img could create a copy on write image. There are several things I don't understand about this. Suppose I go kvm-img -b A.img B.img If I then go on and use A.img as I did before, changing what is on disk, have I screwed up B.img? Do A.img or B.img have to be qcow2 format? I created a raw image for portability. Suppose I work for awhile installing new stuff on B.img, and then want to preserve the state. Is kvm-img -b B.img C.img sensible, or is this kind of recursive operation (B.img is already the copy on write version of A.img) not OK? Does ‘commit [-f fmt] filename’, documented as Commit the changes recorded in filename in its base image. mean commit the recorded changes TO its base image? Here are some other things I think I don't want to do. Please let me know if I'm mistaken. -snapshot on the kvm command line: nothing persistent comes of this (maybe if you commit you update the original image, but you don't get 2). snapshot in the monitor: this snapshots the non-disk state of the VM; further, that state is not guaranteed to work if you later change what is on the disk. I think kvm-img snapshot also accesses these facilities. Yours in confusion :) Ross P.S. Please cc me. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 r...@biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
