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