From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEdpl-0000a9-7C for qemu-devel@nongnu.org; Sun, 10 Mar 2013 06:50:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEdgu-00009F-Kb for qemu-devel@nongnu.org; Sun, 10 Mar 2013 06:41:37 -0400 Received: from mail-qa0-f47.google.com ([209.85.216.47]:58150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEdgu-000098-ED for qemu-devel@nongnu.org; Sun, 10 Mar 2013 06:41:20 -0400 Received: by mail-qa0-f47.google.com with SMTP id j8so516840qah.20 for ; Sun, 10 Mar 2013 03:41:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <24E144B8C0207547AD09C467A8259F7557B301F0@lisa.maurer-it.com> References: <1362867748-30528-1-git-send-email-stefanha@redhat.com> <24E144B8C0207547AD09C467A8259F7557B301F0@lisa.maurer-it.com> Date: Sun, 10 Mar 2013 11:41:19 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC 0/8] block: Live backup prototype List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: Kevin Wolf , "qemu-devel@nongnu.org" , Stefan Hajnoczi , Markus Armbruster On Sun, Mar 10, 2013 at 10:57 AM, Dietmar Maurer wrote: >> The difference between this approach and Dietmar's series is that the backup >> archive format is implemented outside QEMU and runs as a separate program. >> >> This way, management tools like proxmox, oVirt, OpenStack, and others can >> provide their preferred backup archive formats without modifying QEMU. > > So you propose that everyone should use another backup format - this is a bad thing because > it lead to interoperability problems (vendor lock-in?) No, they can use a common format (OVF?). It's up to them. >> This has many advantages: >> >> * 'block-backup' composes with 'migration' and other commands, unlike the >> monolithic 'backup' command designed just for writing backup archives > > Yes, but you can add that easily on top of my patches. True, it can be added on top but it's simpler to have just the key primitive rather than adding it on top. >> * Backup code can be updated or added outside the QEMU release cycle >> >> * Choice of language, coding style, and license for backup code >> >> * Less QEMU code to test and maintain > > The question is why you would want to write and maintain your own backup solution? > This is an disadvantage, not an advantage. If we have working code inside qemu, everybody > can use it. This will lead to better testing, more stable code, and finally we can even try > to make backup/restore work across different management frameworks. > > So while you have "Less QEMU code to test and maintain", it will lead to more code > you have to test and maintain - not inside qemu, but outside qemu ;-) QEMU is not the only component that can be shared. If you want to put VMA into a common component, try libvirt. QEMU does not have enough information to create a full backup archive or restore it. Therefore QEMU is the wrong place for backup archive code. Stefan