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
