[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: Eric Blake
Subject: Re: [Qemu-devel] [PATCH RFC v2 8/8] migration: add migration/dirty-bitmap.c
Date: Tue, 17 Feb 2015 12:12:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 02/17/2015 11:45 AM, John Snow wrote:

>> 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.

Or, if we revisit Jeff's proposal to always auto-name every node, then
you'd never have a node without a name.  Ultimately, libvirt should be
using named nodes, but we're not there yet.

> 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.)

Seems okay to me.

> 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.

That would also work. Since node names and device names share the same
namespace, it should always resolve to the correct node.

> 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.

Except that if a device is named "foo", then no node has that name, so
it is unambiguous that you meant the node attached to device "foo".

> 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.
> --js

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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