[Libguestfs] [V2V PATCH v3 5/6] v2v, in-place: introduce --block-driver command line option

[Laszlo Ersek]

On 3/14/23 15:06, Andrey Drobyshev wrote:
> On 3/14/23 14:59, Laszlo Ersek wrote:
>> On 3/10/23 18:54, Andrey Drobyshev wrote:
>>> From: "Richard W.M. Jones" <rjones at redhat.com>
>>>
>>> The option takes values of "virtio-scsi", "virtio-blk" (with the latter
>>> being the default).  It maps on the convert option with the same name
>>> introduced in the previous commits, thus allowing us to alter the order in
>>> which the VirtIO block drivers are going to be searched for.  This is
>>> useful if we want the virtio-scsi driver to be installed during
>>> conversion instead of the default virtio-blk.
>>>
>>> Also update the docs accordingly.
>>>
>>> Originally-by: Richard W.M. Jones <rjones at redhat.com>
>>> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com>
>>> ---
>>>  docs/virt-v2v-in-place.pod | 10 ++++++++++
>>>  docs/virt-v2v.pod          | 10 ++++++++++
>>>  in-place/in_place.ml       | 11 ++++++++++-
>>>  v2v/v2v.ml                 | 11 ++++++++++-
>>>  4 files changed, 40 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/docs/virt-v2v-in-place.pod b/docs/virt-v2v-in-place.pod
>>> index 6e1c5363..1e993e8c 100644
>>> --- a/docs/virt-v2v-in-place.pod
>>> +++ b/docs/virt-v2v-in-place.pod
>>> @@ -47,6 +47,16 @@ Display help.
>>>
>>>  See I<--network> below.
>>>
>>> +=item B<--block-driver virtio-blk>
>>> +
>>> +=item B<--block-driver virtio-scsi>
>>> +
>>> +When choosing a block driver for Windows guests, prefer C<virtio-blk> or
>>> +C<virtio-scsi>.  The default is C<virtio-blk>.
>>> +
>>> +Note this has no effect for Linux guests at the moment.  That may be
>>> +added in future.
>>> +
>>>  =item B<--colors>
>>>
>>>  =item B<--colours>
>>> diff --git a/docs/virt-v2v.pod b/docs/virt-v2v.pod
>>> index b458607d..e096418b 100644
>>> --- a/docs/virt-v2v.pod
>>> +++ b/docs/virt-v2v.pod
>>> @@ -207,6 +207,16 @@ The options are silently ignored for other input methods.
>>>
>>>  See I<--network> below.
>>>
>>> +=item B<--block-driver virtio-blk>
>>> +
>>> +=item B<--block-driver virtio-scsi>
>>> +
>>> +When choosing a block driver for Windows guests, prefer C<virtio-blk> or
>>> +C<virtio-scsi>.  The default is C<virtio-blk>.
>>> +
>>> +Note this has no effect for Linux guests at the moment.  That may be
>>> +added in future.
>>> +
>>>  =item B<--colors>
>>>
>>>  =item B<--colours>
>>
>> I needed to fix up the above two (documentation) hunks.
>>
>> Namely, in preparation for merging this series, I ran "make check", and
>> it failed. As written, the patch breaks "test-v2v-docs.sh"; the test
>> complains about the manuals not documenting the "--block-driver" option.
>>
>> The proper way to document the new options is to highlight the options
>> and the option-arguments separately:
>>
>>> diff --git a/docs/virt-v2v-in-place.pod b/docs/virt-v2v-in-place.pod
>>> index 1e993e8c7973..ce57e22969a3 100644
>>> --- a/docs/virt-v2v-in-place.pod
>>> +++ b/docs/virt-v2v-in-place.pod
>>> @@ -47,9 +47,9 @@ Display help.
>>>
>>>  See I<--network> below.
>>>
>>> -=item B<--block-driver virtio-blk>
>>> +=item B<--block-driver> B<virtio-blk>
>>>
>>> -=item B<--block-driver virtio-scsi>
>>> +=item B<--block-driver> B<virtio-scsi>
>>>
>>>  When choosing a block driver for Windows guests, prefer C<virtio-blk> or
>>>  C<virtio-scsi>.  The default is C<virtio-blk>.
>>> diff --git a/docs/virt-v2v.pod b/docs/virt-v2v.pod
>>> index e096418b2c25..4d2f241ad723 100644
>>> --- a/docs/virt-v2v.pod
>>> +++ b/docs/virt-v2v.pod
>>> @@ -207,9 +207,9 @@ The options are silently ignored for other input methods.
>>>
>>>  See I<--network> below.
>>>
>>> -=item B<--block-driver virtio-blk>
>>> +=item B<--block-driver> B<virtio-blk>
>>>
>>> -=item B<--block-driver virtio-scsi>
>>> +=item B<--block-driver> B<virtio-scsi>
>>>
>>>  When choosing a block driver for Windows guests, prefer C<virtio-blk> or
>>>  C<virtio-scsi>.  The default is C<virtio-blk>.
>>
>> Showcased by prior art such as
>>
>>> =item B<-i> B<disk>
>>
>> Andrey, please don't forget to re-run "make check" before posting.
> 
> My bad, thanks for the fixup!
> 
> Speaking of "make check": could you point out, for future reference,
> which particular sub-target you're referring to here?  I can see these:
> check-am, check-recursive, check-slow, check-TESTS, check-valgrind.  And
> none of them seems to refer to checking docs integrity.  Yet running
> entire "make check" might be quite time consuming.

I only use "make check" and "make check-valgrind". The first of these is
the normal test suite; it's quite fast. The second (= check-valgrind)
runs the same normal test suite, but under valgrind (checking for memory
safety violations etc). Finally, there's also "make check-slow", which
really is slow (it's extensive!), so I usually don't run it.

Laszlo