Re: [Libguestfs] [V2V PATCH 0/5] Bring support for virtio-scsi back to Windows

On 2/23/23 12:48, Denis V. Lunev wrote: > On 2/23/23 11:43, Laszlo Ersek wrote: >> On 2/22/23 19:20, Andrey Drobyshev wrote: >>> Since commits b28cd1dc ("Remove requested_guestcaps / rcaps"), f0afc439 >>> ("Remove guestcaps_block_type Virtio_SCSI") support for installing >>> virtio-scsi driver is missing in virt-v2v.  AFAIU plans and demands for >>> bringing this feature back have been out there for a while.  E.g. I've >>> found a corresponding issue which is still open [1]. >>> >>> The code in b28cd1dc, f0afc439 was removed due to removing the old >>> in-place >>> support.  However, having the new in-place support present and bringing >>> this same code (partially) back with several additions and improvements, >>> I'm able to successfully convert and boot a Win guest with a virtio-scsi >>> disk controller.  So please consider the following implementation of >>> this feature. >>> >>> [1] https://github.com/libguestfs/virt-v2v/issues/12 >> (Preamble: I'm 100% deferring to Rich on this, so take my comments for >> what they are worth.) >> >> In my opinion, the argument made is weak. This cover letter does not say >> "why" -- it does not explain why virtio-blk is insufficient for >> *Virtuozzo*. >> >> Second, reference [1] -- issue #12 -- doesn't sound too convincing. It >> writes, "opinionated qemu-based VMs that exclusively use UEFI and only >> virtio devices". "Opinionated" is the key word there. They're entitled >> to an opinion, they're not entitled to others conforming to their >> opinion. I happen to be opinionated as well, and I hold the opposite >> view. >> >> (BTW even if they insist on UEFI + virtio, which I do sympathize with, >> requiring virtio-scsi exclusively is hard to sell. In particular, >> virtio-blk nowadays has support for trim/discard, so the main killer >> feature of virtio-scsi is no longer unique to virtio-scsi. Virtio-blk is >> also simpler code and arguably faster. Note: I don't want to convince >> anyone about what *they* support, just pointing out that virt-v2v >> outputting solely virtio-blk disks is entirely fine, as far as >> virt-v2v's mission is concerned -- "salvage 'pet' (not 'cattle') VMs >> from proprietary hypervisors, and make sure they boot". Virtio-blk is >> sufficient for booting, further tweaks are up to the admin (again, >> virt-v2v is not for mass/cattle conversions). The "Hetzner Cloud" is not >> a particular output module of virt-v2v, so I don't know why virt-v2v's >> mission should extend to making the converted VM bootable on "Hetzner >> Cloud".) >> >> Rich has recently added tools for working with the virtio devices in >> windows guests; maybe those can be employed as extra (manual) steps >> before or after the conversion. >> >> Third, the last patch in the series is overreaching IMO; it switches the >> default. That causes a behavior change for such conversions that have >> been working well, and have been thoroughly tested. It doesn't just add >> a new use case, it throws away an existent use case for the new one's >> sake, IIUC. I don't like that. >> >> Again -- fully deferring to Rich on the final verdict (and the review). >> >> Laszlo > OK. Let me clarify the situation a bit. > > These patches (for sure) originates from good old 2017 year, when > VirtIO BLK was completely unacceptable to us due to missed > discard feature which is now in. > > Thus you are completely right about the default and default > changing (if that will happen) should be in the separate patch. > Anyway, from the first glance it should not be needed. > > Normally, in inplace mode, which we are mostly worrying > about v2v should bring the guest configuration in sync > with what is written in domain.xml and that does not involve > any defaults. > > VirtIO SCSI should be supported as users should have > a freedom to choose between VirtIO SCSI and VirtIO BLK > even after the guest installation. > > Does this sounds acceptable? 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