On 2/24/23 17:11, Andrey Drobyshev wrote:
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@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@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.
My understanding is that these are different driver names, but these drivers are all for the virtio-block device. IIUC the names had changed over time, for the same thing.
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?
Yes, let's hear what Rich thinks. Laszlo