From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDuqk-0006x8-Ch for qemu-devel@nongnu.org; Fri, 08 Mar 2013 05:48:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDuqi-0005Hd-ON for qemu-devel@nongnu.org; Fri, 08 Mar 2013 05:48:30 -0500 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:32813) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDuqi-0005HQ-Al for qemu-devel@nongnu.org; Fri, 08 Mar 2013 05:48:28 -0500 Received: by mail-we0-f170.google.com with SMTP id z53so833832wey.29 for ; Fri, 08 Mar 2013 02:48:27 -0800 (PST) Date: Fri, 8 Mar 2013 11:48:24 +0100 From: Stefan Hajnoczi Message-ID: <20130308104824.GB32107@stefanha-thinkpad.redhat.com> References: <20130228144920.GD18389@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B12DDC@lisa.maurer-it.com> <20130304125806.GA18476@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B277AE@lisa.maurer-it.com> <20130304135537.GC3929@dhcp-200-207.str.redhat.com> <24E144B8C0207547AD09C467A8259F7557B278C1@lisa.maurer-it.com> <20130306124424.GE1954@stefanha-thinkpad.muc.redhat.com> <24E144B8C0207547AD09C467A8259F7557B2C525@lisa.maurer-it.com> <20130307090541.GA13854@stefanha-thinkpad.redhat.com> <24E144B8C0207547AD09C467A8259F7557B2D551@lisa.maurer-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24E144B8C0207547AD09C467A8259F7557B2D551@lisa.maurer-it.com> Subject: Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: Kevin Wolf , "qemu-devel@nongnu.org" On Thu, Mar 07, 2013 at 09:28:40AM +0000, Dietmar Maurer wrote: > > > When we run backup, we need to read such block on every write from the > > guest. > > > So if we increase block size we get additional delays. > > > > Don't increase the bitmap block size. > > > > Just let the block job do larger reads. This is the bulk of the I/O workload. You > > can use large reads here independently of the bitmap block size. > > > > That way guest writes still only have a 64 KB read overhead but you reduce the > > overhead of doing so many 64 KB writes from the backup block job. > > If there are many writes from the guest, you still get many 64KB block. In the common case the backup block job does significantly more I/O than the guest, unless your workload is dd if=/dev/vda of=/dev/null. Remember the block job is reading the *entire* disk! > Anyways, and additional RPC layer always adds overhead, and It can be completely avoided. > Maybe not much, but I want to make backup as efficient as possible. The drawbacks outweight the performance advantage: 1. QEMU can neither backup nor restore without help from the management tool. This is a strong indicator that the backup archive code should live outside QEMU. I doesn't make sense for proxmox, oVirt, OpenStack, and others to each maintain their backup archive code inside qemu.git, tied to QEMU's C codebase, release cycle, and license. 2. QEMU already has interfaces to export the vmstate and block device snapshots: migration/savevm and BlockDriverState (NBD for IPC or raw/qcow2/vmdk for file). It is not necessary to add a special-purpose interface just for backup. 3. The backup block job can be composed together with other QMP commands to achieve scenarios besides just VMA backup. It's more flexible to add simple primitives that can be combined instead of adding a monolithic backup command. For these reasons, I'm against putting backup archive code into QEMU. If performance is key, please look into incremental backups. Taking a full copy of the disk image every time affects guest performance much more than IPC overhead. Plus there'll be less IPC if only dirty blocks are backed up :). Stefan