From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsQnp-0004rx-Ki for qemu-devel@nongnu.org; Fri, 07 Oct 2016 04:46:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsQnj-0006he-I3 for qemu-devel@nongnu.org; Fri, 07 Oct 2016 04:46:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsQnj-0006hT-9J for qemu-devel@nongnu.org; Fri, 07 Oct 2016 04:46:43 -0400 Date: Fri, 7 Oct 2016 10:46:40 +0200 From: Kevin Wolf Message-ID: <20161007084640.GB4589@noname.redhat.com> References: <42B37FE3-87E1-42CA-A089-B090F37FF7D5@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Adding Save States menu items List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Programmingkid , Peter Maydell , qemu-devel qemu-devel --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Am 06.10.2016 um 21:59 hat Eric Blake geschrieben: > Libvirt also learned that the qemu 'migrate-to-disk' format (used by > 'savevm' or 'migrate') is NOT self-descriptive - in order to fully and > safely revert to an earlier state, you HAVE to store the command line > (or a way to regenerate the command line) that was associated with the > qemu whose state you saved, along with tracking all hotplugs. Since a > mere 'savevm' REQUIRES external information to safely be restored, you > would have to figure out a way to store this additional information > alongside whatever save files you plan on creating (and please don't > change the qcow2 file format to become a dumping grounds for this > additional information). Have we made any progress regarding this in the past few years? I know we once intended to get to a state where the migration stream could include information about which devices exist in the first place. I guess that's somehow linked to the idea of starting with an empty machine and then creating all devices and backends with QMP rather than the command line before actually starting the VM. Kevin --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJX92DwAAoJEH8JsnLIjy/W0yUQALcL+AOLudWFIU7jsAsXkQkP 3ZKxXhth2XwGGiVPH1C9JLeYp5U5fOgbzum7ch6VEkK7VHPbYXZcb+1qbSWTzgbE QjDxa5Q4Tie7IFP+gYTyEtPt3ulPiv2f9V7bLoRxt0vMGBGs6ZbOu8P7TxfR5VjP 7us50Yq0XpY/MZv474++salQns534iJrR33b6i8Gjs7U1Bf2lmTIdTL9tpAu6I29 9wL06jEx40+XUaDcJDb+PDLmpGLLL2V1VXV9zR1+X7jPPbPYe2NQAzWlu28rIwr6 qhFqk4l3A/N+d1q7+UUaOiGh+wX3psGmTQYLZ7YHrzxiGIW2F+wUhpV8HMkNkJNL OAYRBb0jpcyqdR3mgtT3P65nwgLnwMSsrRz+qkooZsLnslImntmGrVpbKU4pKZEw 0k0r/6tEYeKPxv4ybcCxZ/yT+uTG8VGAKxdT1KWrp1uLgjgxypRo3szKi9oPxX+m RX3HPVekjApN1ygxMrM5rOD6rwtFexWJI65RxA0l23TEKBShe6klNtbYzVx4jk2D w11iutMqs1sGXKoFKDjNAzbB2f6YynOstrwDWVYlP4QZNbig7VlcWNvUCs3FZ1ay JkLGSp2NY2JxurWRzmTxwUmBR+s8ymXCupxVUXcLLdcpnBJsod3XCNX6Evak/YCV kGwsTFX3aXOgRGAHskJz =pe3k -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ--