From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPdS7-0002I1-AG for qemu-devel@nongnu.org; Thu, 04 Sep 2014 16:16:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPdRy-0007jK-9q for qemu-devel@nongnu.org; Thu, 04 Sep 2014 16:16:19 -0400 Received: from mail-we0-x231.google.com ([2a00:1450:400c:c03::231]:50184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPdRy-0007iA-3M for qemu-devel@nongnu.org; Thu, 04 Sep 2014 16:16:10 -0400 Received: by mail-we0-f177.google.com with SMTP id u56so10616066wes.8 for ; Thu, 04 Sep 2014 13:16:06 -0700 (PDT) Date: Thu, 4 Sep 2014 21:16:01 +0100 From: Stefan Hajnoczi Message-ID: <20140904201601.GE25226@stefanha-thinkpad.redhat.com> References: <20140829172218.GD16755@irqsave.net> <20140902092510.GC29067@stefanha-thinkpad.redhat.com> <54065EE7.4080601@redhat.com> <20140903131159.GM28095@stefanha-thinkpad.redhat.com> <20140904132435.GA27852@irqsave.net> <5408821B.4070708@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a1QUDc0q7S3U7/Jg" Content-Disposition: inline In-Reply-To: <5408821B.4070708@redhat.com> Subject: Re: [Qemu-devel] tcmu-runner and QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andy Grover Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , kwolf@redhat.com, qemu-devel@nongnu.org, Stefan Hajnoczi , pbonzini@redhat.com --a1QUDc0q7S3U7/Jg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 04, 2014 at 08:15:39AM -0700, Andy Grover wrote: > But in the meantime, do you have a use case or user story for the QMP > support that might help me understand better how it might all fit togethe= r? =46rom my previous email: "administrator needs to migrate disk images to a new file system or storage devices without downtime." Here is some more detail about how that works: QEMU has a drive-mirror QMP command that copies the disk image to a new location while continuing to service I/O. In other words live storage migration, no downtime. A tool needs to connect to the QMP unix domain socket and issue the drive-mirror command. Then it needs to wait until the QMP events are raised signalling drive-mirror completion and it block-job-complete QMP command to atomically switch to the new image file (it is now safe to delete the old image file). Stefan --a1QUDc0q7S3U7/Jg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUCMiBAAoJEJykq7OBq3PIBtQIAJKTmtf0VQmLVtFRkpEeu9BI xqZ0jCFlqD5PaJrC9Mx7xhOsPINZrTEUl3SjyyeWnOeWTWgA2i+u4E+Q4oYqbaCV HXbRMa9bZkgKdAw0l8nyQd8FUj4hm7Qm3XqfO+YXeyKTw6Vi/XMzdnwNi7Y1hV72 dTLL+BpVf4pbavXWTVT5JhvFx+Bt6CyggqgPnRXy0mwsQ1GskoR12HeKXSpm+TTM Ea9lnfHteDxyvSxTnO+6M+Jk6a9pBZNbwQD9qfztoZZ82njZBxkdqqd0il+qqVUf KlESpLZvQ+OtN2rKaOlptO/P084qj2sjWDNN6mOmBnanK2g9xUpajjGXKpHv/64= =wHN4 -----END PGP SIGNATURE----- --a1QUDc0q7S3U7/Jg--