From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55972 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PVO2i-0006cY-QT for qemu-devel@nongnu.org; Wed, 22 Dec 2010 07:43:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PVO2h-0008Qj-HU for qemu-devel@nongnu.org; Wed, 22 Dec 2010 07:43:44 -0500 Received: from mail-qy0-f180.google.com ([209.85.216.180]:35113) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PVO2h-0008QX-Dl for qemu-devel@nongnu.org; Wed, 22 Dec 2010 07:43:43 -0500 Received: by qyk29 with SMTP id 29so5316887qyk.4 for ; Wed, 22 Dec 2010 04:43:41 -0800 (PST) MIME-Version: 1.0 From: Tomer Margalit Date: Wed, 22 Dec 2010 14:43:21 +0200 Message-ID: Content-Type: multipart/alternative; boundary=00163642707e5e39370497ff1a6c Subject: [Qemu-devel] Asynchronously Mirroring a Virtual Machine List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: scipioenterprises@yahoo.com, "Zaidenberg, Nezer" , Nezer Zaidenberg --00163642707e5e39370497ff1a6c Content-Type: text/plain; charset=ISO-8859-1 Hi, I am a grad. student in Tel-Aviv university, and my theses is focused on asynchronous mirroring. I have already built asynchronous mirror software (which is composed of a driver and a daemon), which works by setting up a virtual block device over an existing one, and thus mirroring the existing one (asynchronously) to the network using a window. What I would like to add to it is the ability to asynchronously mirror a (QEMU) VM as well, so that if the primary site crashes, the VM can be restored (to the last stable point) immediately. Since I want it to be as general as possible, I will not rely on my mirror, but only on there being a virtual block device that is mirroring me (and that has consistent writes (that is, if write A succeeded, and afterwards write B succeeded, then if B is on the secondary site, then A must be there too)), and that there is some kind of marking mechanism (so that I can mark the last consistent state). The reason I want to do this using QEMU is that it has live migration - which is almost what I need. Right now my plan is to treat the memory as a file, and put it and all the vm images on the same mirroring block device. Then, every minute or so, I will (stop the vm) sync the memory and disks, and put a mark (where during the minute I will continue to write what I can). This sounds to me like doing a continuous "live migration", but never actually moving the machine, and after finishing the migration on the side that initiated it, not throwing away the dirty/clean pages (so that the memory does not have to be moved completely again). I would appreciate any direction and/or suggestions in this matter. Also, I wondered where can I find some documentation about the whole migration process - should I just read the code, or is there any document about it? Thanks, Tomer --00163642707e5e39370497ff1a6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I am a grad. student in Tel-Aviv un= iversity, and my theses is focused on asynchronous mirroring.
I h= ave already built asynchronous mirror software (which is composed of a driv= er and a daemon), which works by setting up a virtual block device over an = existing one, and thus mirroring the existing one (asynchronously) to the n= etwork using a window.

What I would like to add to it is the ability to asynch= ronously mirror a (QEMU) VM as well, so that if the primary site crashes, t= he VM can be restored (to the last stable point) immediately.

Since I want it to be as general as possible, I will not rel= y on my mirror, but only on there being a virtual block device that is mirr= oring me (and that has consistent writes (that is, if write A succeeded, an= d afterwards write B succeeded, then if B is on the secondary site, then A = must be there too)), and that there is some kind of marking mechanism (so t= hat I can mark the last consistent state).

The reason I want to do this using QEMU is that it has = live migration - which is almost what I need.
Right now my plan i= s to treat the memory as a file, and put it and all the vm images on the sa= me mirroring block device.=A0
Then, every minute or so, I will (stop the vm) sync the memory and dis= ks, and put a mark (where during the minute I will continue to write what I= can).

This sounds to me like doing a continuous &= quot;live migration", but never actually moving the machine, and after= finishing the migration on the side that initiated it, not throwing away t= he dirty/clean pages (so that the memory does not have to be moved complete= ly again).

I would appreciate any direction and/or suggestions in = this matter.

Also, I wondered where can I find som= e documentation about the whole migration process - should I just read the = code, or is there any document about it?

Thanks,
=A0=A0 =A0Tomer
--00163642707e5e39370497ff1a6c--