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