qemu-block
[Top][All Lists]
Advanced

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

Re: block-dirty-bitmap-add fails with "Operation not supported" in 4.2 r


From: Kevin Wolf
Subject: Re: block-dirty-bitmap-add fails with "Operation not supported" in 4.2 rc5 (worked in 4.1)
Date: Mon, 16 Dec 2019 12:23:11 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

Am 13.12.2019 um 21:39 hat Nir Soffer geschrieben:
> > > > so try using #block126 instead of 'ide0-hd0' if the transaction remains
> > > > in this order.  But yes, better yet is to match what libvirt will do and
> > > > use -blockdev everywhere (upstream libvirt will refuse to use bitmaps
> > > > with any qemu older than 4.2).
> > >
> > > Thank you for the detailed answer!
> > >
> > > I'm sure blockdev is the greatest thing since sliced bread but it
> > > looks like overkill for our use case.
> >
> > If you care about more than the top layer, you need to control the block
> > graph. And -blockdev is the best way to be sure that the graph looks
> > what you want it to look, and to assign node names everywhere.
> >
> > > I'm happy to use the node name generated by qemu.
> >
> > You're not supposed to. That's why they contain a random element and are
> > unpredictable. If you do this against all warnings,
> 
> Using "#block126" is a warning? Looks just like /dev/dm-42 or /dev/sdx
> to me.
> 
> > don't blame us for
> > any pain you'll incur. The assumption in QEMU is that if you use node
> > names, you take responsibility to manage the graph.
> 
> So qemu may behave differently if I added the disk using blockdev-add
> with my own node-name or if qemu assigned the node-name?

No, the addition of the node won't be different.

The problem when you mix -drive (and the accompanying device-level QMP
commands) with things that require you to know what the graph looks like
is that you can't relly tell what it looks like because you don't know
how the device-level operation was implemented on the node level.

For example, you could get a filter node inserted on top by some
operation, and then your method to reverse engineer the node name will
return the wrong node.

So the thing I'm afraid of is that in the common case it will look like
it works, but when it's used in more complex situations, it may fail.
That's why I strongly recommend managing the node names yourself instead
of trying to figure out after the fact what QEMU did automatically.

> > If you absolutely can't see yourself using -blockdev for now, you can
> > still set explicit node names with -drive at least.
> 
> it sounds better than looking up the node name.

Yes, and it should be more reliable.

Kevin




reply via email to

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