10:11 a.m.
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(a)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(a)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