On Fri, Nov 28, 2014 at 04:28:57PM +0300, Vladimir Sementsov-Ogievskiy wrote:
On 21.11.2014 19:55, Stefan Hajnoczi wrote:
Active dirty bitmaps should migrate too. I'm thinking now that the
appropriate thing is to add live migration of dirty bitmaps to QEMU
(regardless of whether they are
On 21.11.2014 19:55, Stefan Hajnoczi wrote:
Active dirty bitmaps should migrate too. I'm thinking now that the
appropriate thing is to add live migration of dirty bitmaps to QEMU
(regardless of whether they are active or not).
I think, we should migrate named dirty bitmaps, which are not used
I'm thinking now that the
appropriate thing is to add live migration of dirty bitmaps to QEMU
(regardless of whether they are active or not).
Digging the code around, I've found this:
in mig_save_device_dirty which is actually an iteration of live block
migration, after sending a sector we
Active dirty bitmaps should migrate too. I'm thinking now that the
appropriate thing is to add live migration of dirty bitmaps to QEMU
(regardless of whether they are active or not).
Only for persistent bitmaps, or for all named bitmaps? If for all named
bitmaps, then this migration should not
There is a constraint if we want to get live migration for free: The
bitmap contents must be accessible with bdrv_read() and
bdrv_get_block_status() to skip zero regions.
Hm. I'm afraid, it still will not be free. If bitmap is active, it's
actual version is in memory. To migrate bitmap file like
The metadata (bitmap
name, granularity, etc) doesn't need to be stored in the image file
because management tools must be aware of it anyway.
What tools do you mean? In my opinion dirty bitmap should exist as a
separate object. If it exists, it should be loaded with it's drive image
and it
On Fri, Nov 21, 2014 at 01:27:40PM +0300, Vladimir Sementsov-Ogievskiy wrote:
There is a constraint if we want to get live migration for free: The
bitmap contents must be accessible with bdrv_read() and
bdrv_get_block_status() to skip zero regions.
Hm. I'm afraid, it still will not be free. If
QDB file is for storing dirty bitmap. The specification is based on
qcow2 specification.
Saving several bitmaps is necessary when server shutdowns during
backup. In this case 2 tables for each disk are available. One
collected for a previous period and one active. Though this feature
is
Also, it may be better to make this as qcow2 extension. And bitmap will
be saved in separate qcow2 file, which will contain only the bitmap(s)
and no other data (no disk, no snapshots).
Best regards,
Vladimir
On 20.11.2014 13:34, Vladimir Sementsov-Ogievskiy wrote:
QDB file is for storing
On Thu, Nov 20, 2014 at 01:41:14PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Also, it may be better to make this as qcow2 extension. And bitmap will be
saved in separate qcow2 file, which will contain only the bitmap(s) and no
other data (no disk, no snapshots).
I think you are on to
On 11/20/2014 03:34 AM, Vladimir Sementsov-Ogievskiy wrote:
QDB file is for storing dirty bitmap. The specification is based on
qcow2 specification.
Saving several bitmaps is necessary when server shutdowns during
backup. In this case 2 tables for each disk are available. One
collected for
11 matches
Mail list logo
