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 ar
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 no
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 need
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 b
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 fr
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 shoul
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
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
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 someth
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 dir
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 discussabl
11 matches
Mail list logo
