Libguestfs - Feb 2023 - [V2V PATCH 0/5] Bring support for virtio-scsi back to Windows

On 2/24/23 12:55, Denis V. Lunev wrote:
> On 2/24/23 05:56, Laszlo Ersek wrote:
>> I've got zero experience with in-place conversions. I've
skimmed
>> <https://libguestfs.org/virt-v2v-in-place.1.html> now, but the
use case
>> continues to elude me.
>>
>> What is in-place conversion good for? If you already have a libvirt
>> domain XML (i.e., one *not* output by virt-v2v as the result of a
>> conversion from a foreign hypervisor), what do you need
>> virt-v2v-in-place for?
>>
>> My understanding is that virt-v2v produces both an output disk (set)
and
>> a domain description (be it a QEMU cmdline, a libvirt domain XML, an
>> OVF, ...), *and* that these two kinds of output belong together, there
>> is not one without the other. What's the data flow with inplace
>> conversion?
>>
>> Laszlo
>>
> We use v2v as guest convertor engine and prepare VM configuration
> ourselves. This looks more appropriate for us as we have different
> constraints under different conditions.
>
> This makes sense outside of foreign hypervisor as we could change
> bus of the disk and then call v2v to teach the guest to boot from
> new location. This was revealed very useful to fix some strange
> issues on the customer's side.
>
> That is it.
>
> Den
>
> P.S. Resent (original mail was accidentally sent off-list)
>
So the use case is more or less "-i libvirtxml", with the domain XML
created from scratch (or liberally tweaked, starting from a "more
authentic" original domain XML).

The cover letter mentions the following commit:

commit b28cd1dcfeb40e7002e8d0b0ce9dcc4ce86beb6c
Author: Richard W.M. Jones <rjones at redhat.com>
Date:   Mon Nov 8 09:00:20 2021 +0000

    Remove requested_guestcaps / rcaps

    This was part of the old in-place support.  When we add new in-place
    support we'll do something else, but currently this is dead code so
    remove it completely.

    Note this removes the code for installing the virtio-scsi driver (only
    ever using virtio-blk).  This was also dead code in the current
    implementation of virt-v2v, but worth remembering in case we want to
    resurrect this feature in a future version.

    Acked-by: Laszlo Ersek <lersek at redhat.com>

So I guess that "something else" is what I'm missing here. Right
now the
proposed use case seems to be:

- tweak the domain XML in some way (or generate it in some "bespoke"
way
  from the outset)

- perform an in-place conversion with virt-v2v, making sure that
  virt-v2v prefers virtio-scsi as first priority. This will end up
  injecting the virtio-scsi guest driver into the guest.

This looks less than ideal to me. Even if we offer virtio-scsi, that
should be driven by a specific knob.

I initially thought that knob could be a new command line option.

Then, upon reading

    we could change bus of the disk and then call v2v to teach the guest
    to boot from new location

I thought that the contents of the tweaked domain XML would *steer* the
guest driver selection. (This seemed plausible, because we used to have
"source" domain properties, and I vaguely recalled that they once had
been relevant for in-place conversion.) But these patches don't do any
such steering, AFAICT.

Why is the "rcaps" logic from before commit b28cd1dc not being brought
back?

Laszlo

On 2/24/23 14:02, Laszlo Ersek wrote:
> On 2/24/23 12:55, Denis V. Lunev wrote:
>> On 2/24/23 05:56, Laszlo Ersek wrote:
> 
>>> I've got zero experience with in-place conversions. I've
skimmed
>>> <https://libguestfs.org/virt-v2v-in-place.1.html> now, but
the use case
>>> continues to elude me.
>>>
>>> What is in-place conversion good for? If you already have a libvirt
>>> domain XML (i.e., one *not* output by virt-v2v as the result of a
>>> conversion from a foreign hypervisor), what do you need
>>> virt-v2v-in-place for?
>>>
>>> My understanding is that virt-v2v produces both an output disk
(set) and
>>> a domain description (be it a QEMU cmdline, a libvirt domain XML,
an
>>> OVF, ...), *and* that these two kinds of output belong together,
there
>>> is not one without the other. What's the data flow with inplace
>>> conversion?
>>>
>>> Laszlo
>>>
>> We use v2v as guest convertor engine and prepare VM configuration
>> ourselves. This looks more appropriate for us as we have different
>> constraints under different conditions.
>>
>> This makes sense outside of foreign hypervisor as we could change
>> bus of the disk and then call v2v to teach the guest to boot from
>> new location. This was revealed very useful to fix some strange
>> issues on the customer's side.
>>
>> That is it.
>>
>> Den
>>
>> P.S. Resent (original mail was accidentally sent off-list)
>>
> 
> So the use case is more or less "-i libvirtxml", with the domain
XML
> created from scratch (or liberally tweaked, starting from a "more
> authentic" original domain XML).
> 
> The cover letter mentions the following commit:
> 
> commit b28cd1dcfeb40e7002e8d0b0ce9dcc4ce86beb6c
> Author: Richard W.M. Jones <rjones at redhat.com>
> Date:   Mon Nov 8 09:00:20 2021 +0000
> 
>     Remove requested_guestcaps / rcaps
> 
>     This was part of the old in-place support.  When we add new in-place
>     support we'll do something else, but currently this is dead code so
>     remove it completely.
> 
>     Note this removes the code for installing the virtio-scsi driver (only
>     ever using virtio-blk).  This was also dead code in the current
>     implementation of virt-v2v, but worth remembering in case we want to
>     resurrect this feature in a future version.
> 
>     Acked-by: Laszlo Ersek <lersek at redhat.com>
> 
> So I guess that "something else" is what I'm missing here.
Right now the
> proposed use case seems to be:
> 
> - tweak the domain XML in some way (or generate it in some
"bespoke" way
>   from the outset)
> 
> - perform an in-place conversion with virt-v2v, making sure that
>   virt-v2v prefers virtio-scsi as first priority. This will end up
>   injecting the virtio-scsi guest driver into the guest.
> 
> This looks less than ideal to me. Even if we offer virtio-scsi, that
> should be driven by a specific knob.
> 
> I initially thought that knob could be a new command line option.
> 
> Then, upon reading
> 
>     we could change bus of the disk and then call v2v to teach the guest
>     to boot from new location
> 
> I thought that the contents of the tweaked domain XML would *steer* the
> guest driver selection. (This seemed plausible, because we used to have
> "source" domain properties, and I vaguely recalled that they once
had
> been relevant for in-place conversion.) But these patches don't do any
> such steering, AFAICT.
Yes, I think you got the scenario right -- we need to be able to provide
the driver for the controller specified in the source domain XML.  I
agree that changing the default might not be the best solution here.

On the other hand, AFAICT right now the way default is being chosen is
rather strange: it's the 1st driver in the list of ["virtio_blk";
"vrtioblk"; "viostor"] which is present in the tools
directory.  What if
it doesn't match the actual disk controller in the source VM?  Doesn't
make much sense to me.
> 
> Why is the "rcaps" logic from before commit b28cd1dc not being
brought
> back?
My 5th patch actually includes bits of the b28cd1dc, namely adding
vioscsi pciid to the registry.  I'm not sure whether bringing back the
entire rcaps is a good idea, let's probably see what Richard has to say
about this.  Maybe we can come up with a simpler way to "forward" the
storage controller type when doing the initial inspection?
> Laszlo
>