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 <rjo...@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 <ler...@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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
