[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_field
From: |
Eric Blake |
Subject: |
Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields() |
Date: |
Fri, 4 Mar 2016 14:21:04 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
On 03/04/2016 12:53 PM, John Snow wrote:
>
> This is a good insight: If the user literally explicitly wants the root
> node (and not the drive), that's ambiguous and hard to do unless you
> know the name. If it's nameless, you're SOL.
>
> However, I can't think of a use case off the top of my head where you'd
> have a nameless root node (Which I will translate as "A node created
> automatically by QEMU during the construction of the graph and not one
> explicitly configured by the user for some purpose) that is meaningfully
> different from the concept of the "drive as a whole."
What about -transient? There, we create a BB with a known disk (and
BDS) as its read-only primary source, and qemu then creates yet another
BDS (the transient read-write wrapper) as the top of the BB. Do we have
a way to name that node? And I can definitely see wanting to get at the
dirty bitmap for that transient image (how dirty have I made my disk
since the guest started running, to decide whether to abandon or to
commit after all?).
>
> I think if there is ever any semantic meaning or worth to attaching to
> the root node explicitly, I think the user will (should?) always have a
> name for it.
Fortunately, libvirt doesn't use -transient; in part because it doesn't
migrate well or play nicely with sVirt restrictions. I've been meaning
to write patches to libvirt to emulate transient (libvirt creates the
temporary wrapper qcow2 image, which can then be migrated, and libvirt
feeds the fd to qemu so there are no sVirt problems) - so from libvirt's
point of view, the root BDS node can always be named.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), (continued)
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), John Snow, 2016/03/01
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Kevin Wolf, 2016/03/02
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), John Snow, 2016/03/02
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Markus Armbruster, 2016/03/03
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), John Snow, 2016/03/03
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Markus Armbruster, 2016/03/04
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Kevin Wolf, 2016/03/04
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), John Snow, 2016/03/04
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(),
Eric Blake <=
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Kevin Wolf, 2016/03/07
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Kevin Wolf, 2016/03/04
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Markus Armbruster, 2016/03/04
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), John Snow, 2016/03/04
- Re: [Qemu-block] block: Dirty bitmaps and COR in bdrv_move_feature_fields(), Max Reitz, 2016/03/05