similar to: [PATCH v3] v2v: add support for virtio-scsi

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

Virtio-SCSI offers a number of advantages over virtio-blk, in particular, it supports SCSI UNMAP (aka trim) which is crucial for keeping the virtual drive from wasting host disk space. This patch adds support for virtio-scsi as the virtual disk connection type both on input and on output of v2v. Virtio-blk remains the default, so for now virtio-scsi-based guests can only be produced in

On Sat, Feb 20, 2016 at 11:26:10AM +0300, Roman Kagan wrote: > In in-place mode, the decisions on which interfaces to use are made and > the source configuration is created by the outside entity. So in that > case v2v needs to look it up in the source configuraion, and try to > follow. > > For that, the source configuration is used to populate requested caps > object which

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

On Mon, Feb 22, 2016 at 03:04:57PM +0000, Richard W.M. Jones wrote: > On Sat, Feb 20, 2016 at 11:26:10AM +0300, Roman Kagan wrote: > > In in-place mode, the decisions on which interfaces to use are made and > > the source configuration is created by the outside entity. So in that > > case v2v needs to look it up in the source configuraion, and try to > > follow. >

The previous code treated floppy disks and CD-ROMs as the same kind of thing, resulting in malformed libvirt XML. You would see the following error when importing a guest into libvirt: error: Failed to define domain from /tmp/v2vlibvirt063486.xml error: internal error: Invalid floppy device name: hdb because we incorrectly generated this bogus libvirt XML fragment: <disk

The target VM will have several buses to which disks can be attached. Commonly it will have an IDE bus, and possibly a virtio-blk "bus" (not really a bus) and/or a SCSI bus. Virt-v2v does not model this at the moment. Disks are just added to the output XML in the order that we write them, and so they can move around with respect to the target VM. This commit introduces the idea that

https://bugzilla.redhat.com/show_bug.cgi?id=1508874 Also avoids a warning. Rich.

The decision on which device type to use for disks, network and video cards on output used to be taken deep inside the converting functions. This is not always desirable. In particular, there are scenarios when this decision is made before the convertion takes place. E.g. in in-place mode, the decisions are taken and the output VM configuration is created outside of v2v tool. This patchset

Introduce a type to contain the guestcaps that are to be put in effect in the converted VM: options of the block type, net type, and video. It'll be populated by the caller and passed into convert function to affect its choice of of devices and drivers. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/types.ml | 47 +++++++++++++++++++++++++++++++++++++----------

Introduce a type to contain the guestcaps that are to be put in effect in the converted VM: options of the block type, net type, and video. It'll be populated by the caller and passed into convert function to affect its choice of devices and drivers. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/types.ml | 47 +++++++++++++++++++++++++++++++++++++---------- v2v/types.mli

QEMU for x86 supports two machine types, "pc" (emulating the ancient Intel i440FX chipset originally used by the Pentium Pro), and "q35" (https://wiki.qemu.org/Features/Q35). Currently virt-v2v does not set any machine type, so libvirt or the target hypervisor will choose some default, probably i440fx. The latest advice from the QEMU and libvirt communities is not to rely on

On Tue, Jun 19, 2018 at 11:37:46AM +0100, Richard W.M. Jones wrote: > QEMU for x86 supports two machine types, "pc" (emulating the ancient > Intel i440FX chipset originally used by the Pentium Pro), and "q35" > (https://wiki.qemu.org/Features/Q35). > > Currently virt-v2v does not set any machine type, so libvirt or the > target hypervisor will choose some

Give the caller certain control over what kind of interface to use for virtual disks, network and video cards upon conversion. For that, make convert functions accept additional rcaps parameter containing an object with optional capabilities similar to the ones produced on output, with None indicating that the decision is left to the convert function itself. To facilicate review, this patch

Give the caller certain control over what kind of interface to use for virtual disks, network and video cards upon conversion. For that, make convert functions accept additional rcaps parameter containing an object with optional capabilities similar to the ones produced on output, with None indicating that the decision is left to the convert function itself. To facilicate review, this patch

QEMU for x86 supports two machine types, "pc" (emulating the ancient Intel i440FX chipset originally used by the Pentium Pro), and "q35" (https://wiki.qemu.org/Features/Q35). Currently virt-v2v does not set any machine type, so libvirt or the target hypervisor will choose some default, probably i440fx. Newer versions of libvirt and QEMU will probably switch over to defaulting

This code is needed to check whether virtio-scsi driver was installed. This reverts commit f0afc439524853508938b2bfc758896f053462e3. --- convert/convert.ml | 2 +- convert/convert_linux.ml | 9 +++++++-- convert/target_bus_assignment.ml | 1 + lib/create_ovf.ml | 1 + lib/types.ml | 3 ++- lib/types.mli

This code is needed to check whether virtio-scsi driver was installed. This reverts commit f0afc439524853508938b2bfc758896f053462e3. --- convert/convert.ml | 2 +- convert/convert_linux.ml | 9 +++++++-- convert/target_bus_assignment.ml | 1 + lib/create_ovf.ml | 1 + lib/types.ml | 3 ++- lib/types.mli