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

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