Re: [Libguestfs] [V2V PATCH 0/5] Bring support for virtio-scsi back to Windows
On Wed, Feb 22, 2023 at 08:20:43PM +0200, 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
So you're right that we ended up removing virtio-scsi support because
in-place conversion was temporarily removed, and it wasn't restored
when the new virt-v2v-in-place tool was added.
I looked at the patches, and I don't have any objection to 1-4.
Patch 5 is the tricky one because it changes the default, but we
(Red Hat) are likely to stick with virtio-blk for better or worse.
Could we make this configurable? We've traditionally shied away from
adding virt-v2v command line options which are purely for fine-tuning
conversions. The reason for this is that when you're doing bulk
conversions of hundreds of VMs from VMware, you want virt-v2v to do
"the best it can", and it's not really feasible to hand configure
every conversion. (There are some historical exceptions to this, like
--root, but don't look at those!) I know the bulk conversion case
doesn't apply to Virtuozzo, but it does matter for us.
It could be argued that this isn't the same, because if we're bulk
converting, you're not fine-tuning virtio-scsi vs virtio-blk per VM,
but per target hypervisor. So a command line option would be OK in
this case.
BTW previously we "configured" this preference through the input
libvirt XML. That was a terrible idea, so I'd prefer to avoid it this
time around.
Anyway if you can think of a better version of patch 5 then I think we
can accept this.
Thanks,
Rich.
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
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit