similar to: [PATCH v2 0/8] v2v: Add drivers for virtio-rng, balloon, pvpanic.

v1: https://www.redhat.com/archives/libguestfs/2017-April/msg00031.html v2: https://www.redhat.com/archives/libguestfs/2017-April/msg00040.html v2 -> v3: - Fix Xen PV-only kernel detection. Rich.

Yaniv pointed out in https://bugzilla.redhat.com/show_bug.cgi?id=1438794 that virt-v2v both doesn't install the virtio-rng driver for Windows, and doesn't give the guest a virtio-rng PCI device either. There are two problems here: Firstly the Windows virtio-rng driver isn't included in the exploded tree (/usr/share/virtio-win) so it doesn't get copied into the guest. The solution

v1: https://www.redhat.com/archives/libguestfs/2017-April/msg00031.html v2: https://www.redhat.com/archives/libguestfs/2017-April/msg00040.html v3: https://www.redhat.com/archives/libguestfs/2017-April/msg00051.html v3 -> v4: - Properly fix Xen PV-only kernel detection, and test it. Rich.

Metapackages are valid packages with no files, used to easily install something without manually installing bits. This is the case of the "kernel" package in Fedora/RHEL/etc in the last couple of years. --- v2v/linux_kernels.ml | 1 - 1 file changed, 1 deletion(-) diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml index 9a41225a..78c1ee59 100644 --- a/v2v/linux_kernels.ml +++

Hi, this series adds a couple bits more in v2v to convert Debian/Ubuntu (and derived) guests. The series does not complete the support (see known issues below), but all the patches here should be fit for review and inclusion. The series does not enable the conversion, yet. Known issues: * currently tested with simple local guest images, hence needs testing with real guests on

This is a sort of follow-up to the Linux_bootloaders patch. It turns out all the kernel detection code is nicely self- contained and can therefore be moved to its own module. Rich.

Hi, this series adds a couple bits more in v2v to convert Debian/Ubuntu (and derived) guests. The series does not complete the support (see known issues below), but all the patches here should be fit for review and inclusion. The series does not enable the conversion, yet. Known issues: * currently tested with simple local guest images, hence needs testing with real guests on

On Thursday, 6 April 2017 12:04:21 CEST Richard W.M. Jones wrote: > Previously the kernel_info field 'ki_supports_virtio' really meant > that the kernel supports virtio-net. That was used as a proxy to mean > the kernel supports virtio in general. > > This change splits the field so we explicitly test for both virtio-blk > and virtio-net drivers, and store the results

--- v2v/convert_linux.ml | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml index f670812..39a520c 100644 --- a/v2v/convert_linux.ml +++ b/v2v/convert_linux.ml @@ -49,13 +49,14 @@ type kernel_info = { ki_modules : string list; (* The list of module names. *) ki_supports_virtio : bool; (* Kernel has

Since v2: - Use string_suffix kernel_name "-debug" || string_suffix kernel_name "-dbg" - This requires addition of the string_suffix function and some tests

Previously the kernel_info field 'ki_supports_virtio' really meant that the kernel supports virtio-net. That was used as a proxy to mean the kernel supports virtio in general. This change splits the field so we explicitly test for both virtio-blk and virtio-net drivers, and store the results as separate fields. The patch is straightforward, except for the change to the

We check for /boot/vmlinuz-* files in packages with files, and List.find will raise Not_found if there are none. Iterating on an empty list gives the same result, so there is no need to handle empty packages in a special way. --- v2v/linux_kernels.ml | 321 +++++++++++++++++++++---------------------- 1 file changed, 158 insertions(+), 163 deletions(-) diff --git a/v2v/linux_kernels.ml

Actually I have another comment about this patch .. On Tue, Sep 27, 2016 at 05:58:11PM +0200, Pino Toscano wrote: > diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml > index b292921..c197f78 100644 > --- a/v2v/linux_kernels.ml > +++ b/v2v/linux_kernels.ml > @@ -53,6 +53,21 @@ let detect_kernels (g : G.guestfs) inspect family bootloader = > (* What kernel/kernel-like

Hi, I was trying to migrate some VM's to Virtio-SCSI block devices, as this gives some advantages. While checking the virt-v2v code, I found out that it supported Virtio-SCSI, but some bits were missing. In attachment a small patch that adds the missing bits :) Best regards Jean-Louis

On 15/09/2020 21:08, Richard W.M. Jones wrote: > On Tue, Sep 15, 2020 at 09:54:32AM +0200, Jean-Louis Dupond wrote: >> Hi, >> >> I was trying to migrate some VM's to Virtio-SCSI block devices, as >> this gives some advantages. >> >> While checking the virt-v2v code, I found out that it supported >> Virtio-SCSI, but some bits were missing. >>

On Fri, Aug 26, 2016 at 11:02:07AM +0200, Pino Toscano wrote: > When checking whether a kernel supports virtio or it is Xen-based, it is > assumed that the feature has the kernel module for it; this will fail if > the feature is built-in in the kernel, misrepresenting it. > > The solution is to check the kernel configuration (/boot/config-$kver) > whether the feature is

We want to detect if a Linux kernel is Xen PV only ("PV-only"). Such a kernel will not boot on KVM, and if a guest has only PV-only kernels, it will not be able to boot at all on the target. Our previous test was wrong. It tested whether the xennet.ko module exists. This module was renamed in more recent kernels (to xen-netfront.ko), so it happened to not detect modern kernels as

Hi, this series implements the first bits in v2v to convert Debian/Ubuntu (and derived) guests. The series does not complete the support (see known issues below), but all the patches here should be fit for review and inclusion. The series does not enable the conversion, yet. Known issues: * there is no grubby nor Bootloader::Tools Perl module available in Debian, so there is no way to know

We want to detect if a Linux kernel is Xen PV only ("PV-only"). Such a kernel will not boot on KVM, and if a guest has only PV-only kernels, it will not be able to boot at all on the target. Our previous test was wrong. It tested whether the xennet.ko module exists. This module was renamed in more recent kernels (to xen-netfront.ko), so it happened to not detect modern kernels as

The current detection code for Linux kernels assumes that a kernel package contains everything in it, i.e. the kernel itself, its modules, and its configuration. However, since recent Ubuntu versions (e.g. starting from 18.04) modules & config (with few more files) are split in an own package, thus not detecting the modpath from installed vmlinuz files. To overcome this situation, rework