[libvirt] [PATCH 0/2] qemu: Enable -blockdev support (blockdev-add saga)

[Martin Kletzander]

On Sat, Sep 14, 2019 at 10:55:59AM +0200, Peter Krempa wrote:
>On Fri, Sep 13, 2019 at 23:35:47 +0200, Martin Kletzander wrote:
>> On Fri, Sep 13, 2019 at 02:43:53PM +0200, Peter Krempa wrote:
>> > To my knowledge, everything in libvirt is now prepared to fully use
>> > -blockdev way to configure disks in qemu.
>> >
>> > There is one known qemu bug though: Internal snapshots don't work with
>> > -blockdev:
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1658981
>> >
>> > Since I can't in good faith ask for merging this patchset yet I'd like
>> > to give it some more testing I'm suggesting that we push it and revert
>> > it during freeze or add a capability check once qemu is fixed.
>> >
>>
>> I am very much in favour of getting some testing before releasing such big
>> changes.  Any way of not including this in release tarballs is fine, but we
>> should also not completely give up on non-blockdev approach until we do actually
>> release it, if only because by having this in for the whole development period
>> only to disable it for release would mean that we are releasing something we did
>> not test at all for a whole cycle.
>
>At this point it would be more like half of a cycle. Also once we enable
>it anyways (even for some future-qemu-only) the testing given will
>decrease by time into the almost-bitrot region.
>
>To facilitate some deliberate testing I've added the possibility to
>control the qemu capability bits from the qemu namespace:
>
>https://libvirt.org/drvqemu.html#xmlnsfeatures
>

Still, without enabling it, how many people will actually enable it for their
domains to try it out before we release it.  Maybe when setting it we could do
something along the lines of:

    if (virRandom() < .5 || we_are_in_tests) {
        if (!we_are_in_tests) {
            VIR_INFO("You are a lucky winner! This domain (%s) "
                     "will now use blockdev if possible!",
                     vm->def->name);
        }
        virQEMUCapsSet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV);
    }


And then revert this particular part before releasing.  Or is that way too
crazy?  I mean the `.5` constant can be changed, but it is closest to gradual
testing as you can get with projects like libvirt.

>That allows developers and uses who wish to experiment to deliberately
>disable any feature. (Obviously resulting breakage may be considered
>unsupported)

does that mark the domain as tainted?  Probably no because it is already visible
from the XML, right?  I'm asking purely from curiosity.

Have a nice weekend!

>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190914/079a244e/attachment-0001.sig>