Re: [Qemu-devel] Stalls on Live Migration of VMs with a lot of memory
On 2012-1-4 2:04, Peter Lieven wrote: Hi all, is there any known issue when migrating VMs with a lot of (e.g. 32GB) of memory. It seems that there is some portion in the migration code which takes too much time when the number of memory pages is large. Symptoms are: Irresponsive VNC connection, VM stalls and also irresponsive QEMU Monitor (via TCP). The problem seems to be worse on 10G connections between 2 Nodes (i already tried limiting the bandwidth with the migrate_set_speed command) than on 1G connections. Is the migration accomplished finally? How long will that be? I did a test on VM with 4G and it took me about two seconds. The problem also seems to be worse in qemu-kvm-1.0 than in qemu-kvm-0.12.5. Any hints? Thanks, Peter -- Shu Ming IBM China Systems and Technology Laboratory -- 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: [Qemu-devel] [RFC] Consistent Snapshots Idea
On 2011-11-21 20:31, Avi Kivity wrote: On 11/21/2011 02:01 PM, Richard Laager wrote: I'm not an expert on the architecture of KVM, so perhaps this is a QEMU question. If so, please let me know and I'll ask on a different list. It is a qemu question, yes (though fork()ing a guest also relates to kvm). Background: Assuming the block layer can make instantaneous snapshots of a guest's disk (e.g. lvcreate -s), one can get "crash consistent" (i.e. as if the guest crashed) snapshots. To get a "fully consistent" snapshot, you need to shutdown the guest. For production VMs, this is obviously not ideal. Idea: What if KVM/QEMU was to fork() the guest and shutdown one copy? KVM/QEMU would momentarily halt the execution of the guest and take a writable, instantaneous snapshot of each block device. Then it would fork(). The parent would resume execution as normal. The child would redirect disk writes to the snapshot(s). The RAM should have copy-on-write behavior as with any other fork()ed process. Other resources like the network, display, sound, serial, etc. would simply be disconnected/bit-bucketed. Finally, the child would resume guest execution and send the guest an ACPI power button press event. This would cause the guest OS to perform an orderly shutdown. I believe this would provide consistent snapshots in the vast majority of real-world scenarios in a guest OS and application-independent way. Interesting idea. Will the guest actually shut down nicely without a network? Things like NFS mounts will break. Does the child and parent process run in parallel? What will happen if the parent process try to access the block device? It looks like that the child process will write to a snapshot file, but where will the parent process write to? Implementation Nits: * A timeout on the child process would likely be a good idea. * It'd probably be best to disconnect the network (i.e. tell the guest the cable is unplugged) to avoid long timeouts. Likewise for the hardware flow-control lines on the serial port. This is actually critical, otherwise the guest will shutdown(2) all sockets and confuse the clients. * For correctness, fdatasync()ing or similar might be necessary after halting execution and before creating the snapshots. Microsoft guests have an API to quiesce storage prior to a snapshot, and I think there is work to bring this to Linux guests. So it should be possible to get consistent snapshots even without this, but it takes more integration. -- 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: More work on Livebackup for qemu/qemu-kvm
Jagane, we are testing and reviewing the livebackup workspace from git://github.com/jagane/qemu-livebackup.git Several questions are coming from us. 1) It seems that the workspace has not been updated for a while. Is there any new update for this project? 2) It looks like that the support is hightly bounded with qcow2 image format. Is there any plan to support other formats? Like raw, qed streaming? 3) Can we add some checksum method to check if the backup image is correct in the process of image transfering? For example, a checksum is made before the snapshot is transfered and then is compared with the checksum of the backup image after the backup is done. Jagane Sundar: Hello All, I have made more progress on the proposed Livebackup feature for qemu and qemu-kvm. Based on Jes' feedback, I have switched over to using command line parameters instead of specific named files. So, a typical command line looks like this: # ./x86_64-softmmu/qemu-system-x86_64 -drive \ file=/dev/kvm_vol_group/kvm_root_part,boot=on,if=virtio,livebackup=on \ -drive file=/dev/kvm_vol_group/kvm_disk1,if=virtio,livebackup=on \ -m 512 -net nic,model=virtio,macaddr=52:54:00:00:00:01 \ -net tap,ifname=tap0,script=no,downscript=no \ -vnc 0.0.0.0:1000 -usb -usbdevice tablet \ -livebackup_dir /root/kvm/livebackup -livebackup_port 7900 Note the new option livebackup=on in the drive parameters, and the two new parameters -livebackup_dir and -livebackup_port Here's my strategy for rigorous testing of this new code: I have created two virtual disks in LVM logical volumes, and added code in qemu livebackup to create a LVM snapshot as soon as livebackup_client connects to qemu and creates a livebackup snapshot. Then I binary compare the livebackup backed up version of the virtual disk image with the LVM snapshot that was created by using 'cmp'. The backup images are a bit for bit match! As always, all information is available at: http://wiki.qemu.org/Features/Livebackup I have also sent in my application to make a presentation at the qemu forum 2011. In the meantime, I invite feedback on livebackup. Specifically, I am interested in scrutiny of my testing methodology. Also, I plan to add encryption (probably SSL) to the livebackup TCP connection, and some form of authentication. Any thoughts, feedback? Thanks, Jagane -- 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 -- 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
