4:43 a.m.
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