Re: [libvirt PATCH] qemu: Support vmpvscsi controller model
On Tue, May 12, 2020 at 04:51:20PM +0200, Peter Krempa wrote:
On Tue, May 12, 2020 at 10:26:46 -0400, Chris Jester-Young wrote:
> As Daniel P. Berrangé mentioned, this can be configured out via Kconfig.
> Plus there are actually some files in tests/qemucapabilitiesdata that do
> not advertise that device (e.g., *.s390x.replies).
Yes, thus we need the capability. I'd slightly prefer if the capability
is added in a separate commit but that's not strictly required.
Yep, it'll be the first commit in the series that I'll post shortly.
Currently just finishing up `make syntax-check`.
We prefer if new tests use DO_TEST_CAPS_LATEST, or the
version-locked
variants of the test macro so that we are testing a "real" situation. It
also simplifies addition of the test.
Thank you, that's a very helpful tip! I ended up editing disk-scsi.xml,
which is already DO_TEST_CAPS_LATEST for qemuxml2argvtest but not for
qemuxml2xmltest, so you'll see a commit for the latter too. I found
commit 4150f944f9f3f68077aa91e91af259755d4dc568 very helpful for seeing
how one goes about such a conversion.
Note that you can use VIR_TEST_REGENERATE_OUTPUT=1 env variable when
running the qemuxml2argvtest to force creation of the output file and
then just verify that it's as expected.
Thanks, that's very helpful too, knowing I don't have to manually add
`<flag name='pvscsi'/>` by hand!
Too bad, in the case of the qemuxml2argvtest data changes, the block
device node names are numbered backwards compared to the controller
bus IDs, which made the diff larger than it had to be. (I manually
renamed the node names before and after the change to verify that the
actual diff, minus the node name differences, makes sense.)
Well, CI is already there, but the main libvirt project still works
on
the mail based workflow
Okay, then I'll email out the next patch series right after I send this
message, and not wait around.
Thanks so much for your help!
Chris.