[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v2 8/8] migration: add migration/dirty-bitma

From: John Snow
Subject: Re: [Qemu-devel] [PATCH RFC v2 8/8] migration: add migration/dirty-bitmap.c
Date: Tue, 17 Feb 2015 13:45:31 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 02/17/2015 03:54 AM, Vladimir Sementsov-Ogievskiy wrote:
On 16.02.2015 21:18, John Snow wrote:

On 02/16/2015 07:06 AM, Vladimir Sementsov-Ogievskiy wrote:
On 13.02.2015 23:22, John Snow wrote:

On 02/13/2015 03:19 AM, Vladimir Sementsov-Ogievskiy wrote:
On 11.02.2015 00:33, John Snow wrote:

So in summary:
using device names is probably fine for now, as it matches the current
use case of bitmaps as well as drive migration; but using node names
may give us more power and precision later.

I talked to Max about it, and he is leaning towards using device names
for now and switching to node names if we decide we want that power.

(...I wonder if we could use a flag, for now, that says we're
including DEVICE names. Later, we could add a flag that says we're
using NODE names and add an option to toggle as the usage case sees

Are you confused yet? :D
O, thanks for the explanation). Are we really need this flag? As Markus
wrote, nodes and devices are sharing namespaces.. We can use
bdrv_lookup_bs(name, name, errp)..

what 'name' are you using here, though? It looked to me like in your
backup routine we got a list of BDS entries and get the name *from*
the BDS, so we still have to think about how we want to /get/ the name.

Also, we can, for example, send bitmaps as follows:

if node has name - send bitmap with this name
if node is root, but hasn't name - send it with blk name
otherwise - don't send the bitmap

The node a bitmap is attached to should always have a name -- it would
not be possible via the existing interface to attach it to a node
without a name.

I *think* the root node should always have a name, but I am actually
less sure of that.

Hmm.. No? bitmap is attached using bdrv_lookup_bs(name, name, errp),
which can find device with this name. qemu option -drive
file=...,id=disk creates blk named 'disk' and attached node with no name.

Very good point -- We use the device name as a convenience shortcut to the first node. So the node a bitmap is attached to might in fact not have a name.

I see what you mean.

Hmm. So you propose, on the sending side:

(1) Use this node's name, if available
(2) Fall back to the backend/"device" name, if present,
(3) Do not send the bitmap if neither names are present (THIS scenario should be impossible to achieve and should trigger an error.)

What about on the receiving end? To which node(s) do we attach the bitmap? I assume:

(1) Try to find a node with this name and attach it there,
(2) Fall back to attaching it to the root node of a device/BB with this name
(3) If neither are present, abort.

Is that right? If so, it sounds serviceable to me, but keep in mind that bdrv_lookup_bs() on the receiving end will default to #2 first before #1.

Overall, this makes the migration very "fuzzy" in terms of which bitmaps will go where, and the onus is really on the user (or management tool) to keep trees compatibly similar for the purposes of bitmap migration.

I still wonder if making the exportation of names more explicit in terms of a flag ("this name is a node-name", "this name is a backend-name") might still be of use for providing more rigid and knowable migration semantics.

Might as well go ahead with your suggestion for now, and we'll see if anyone from migration or libvirt groups has a reason not to do it that way. I don't have any concrete reasons.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]