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
>
>
> v2v:
>
> Andrey Drobyshev (2):
> Revert "Remove guestcaps_block_type Virtio_SCSI"
> convert_windows: add Inject_virtio_win.Virtio_SCSI as a possible block
> type
>
> convert/convert.ml | 2 +-
> convert/convert_linux.ml | 9 +++++++--
> convert/convert_windows.ml | 1 +
> convert/target_bus_assignment.ml | 1 +
> lib/create_ovf.ml | 1 +
> lib/types.ml | 3 ++-
> lib/types.mli | 2 +-
> output/openstack_image_properties.ml | 7 +++++++
> 9 files changed, 22 insertions(+), 6 deletions(-)
>
> common:
>
> Andrey Drobyshev (2):
> inject_virtio_win: add Virtio_SCSI to block_type
> inject_virtio_win: make virtio-scsi the default block driver
>
> Roman Kagan (1):
> inject_virtio_win: match only vendor/device
>
> mlcustomize/inject_virtio_win.ml | 25 ++++++++++++++++---------
> mlcustomize/inject_virtio_win.mli | 2 +-
> 2 files changed, 17 insertions(+), 10 deletions(-)
>
> --
> 2.31.1
>
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
