From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4U1R-0000WD-AQ for qemu-devel@nongnu.org; Fri, 16 Sep 2011 04:43:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4U1Q-0008MY-76 for qemu-devel@nongnu.org; Fri, 16 Sep 2011 04:43:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4U1P-0008MS-U9 for qemu-devel@nongnu.org; Fri, 16 Sep 2011 04:43:44 -0400 Message-ID: <4E730CEC.1090001@redhat.com> Date: Fri, 16 Sep 2011 10:46:36 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4E70DEE8.8090908@linux.vnet.ibm.com> <4E71E41B.9050906@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Design of the blobstore List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Markus Armbruster , Anthony Liguori , "Michael S. Tsirkin" , QEMU Developers , Stefan Berger Am 15.09.2011 13:58, schrieb Stefan Hajnoczi: >>> What about live migration? If each VM has a LUN assigned on a SAN >>> then these qcow2 files add a new requirement for a shared file system. >>> >>> Perhaps it makes sense to include the blobstore in the VM state data >>> instead? If you take that approach then the blobstore will get >>> snapshotted *into* the existing qcow2 images. Then you don't need a >>> shared file system for migration to work. >> >> But what happens if you don't do fancy things like snapshots or live >> migration, but just shut the VM down? Nothing will be saved then, so it >> must already be on disk. I think using a BlockDriverState for that makes >> sense, even though it is some additional work for migration. But you >> already deal with n disks, doing n+1 disks shouldn't be much harder. > > Sure, you need a file because the data needs to be persistent. I'm > not saying to keep it in memory only. > > My concern is that while QEMU block devices provide a convenient > wrapper for snapshot and encryption, we need to write the data layout > that goes inside that wrapper from scratch. We'll need to invent our > own key-value store when there are plenty of existing ones. I > explained that the snapshot feature is actually a misfeature, it would > be better to integrate with VM state data so that there is no > additional migration requirement. I'm not so sure if being able to integrate it in the VM state is a feature or a bug. There is no other persistent data that is included in VM state data. Kevin