Re: [Libguestfs] [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(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.
Why is the "rcaps" logic from before commit b28cd1dc not being brought
back?
Laszlo