Displaying 20 results from an estimated 600 matches similar to: "[PATCH v2] v2v: When picking a default kernel, favour non-debug kernels over debug kernels (RHBZ#1170073)."
2014 Dec 04
1
[PATCH] v2v: When picking a default kernel, favour non-debug kernels over debug kernels (RHBZ#1170073).
---
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..420aba5 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
2014 Dec 04
2
[PATCH v3 0/2] v2v: When picking a default kernel, favour non-debug
Since v2:
- Use string_suffix kernel_name "-debug" || string_suffix kernel_name "-dbg"
- This requires addition of the string_suffix function and some tests
2014 Dec 04
0
Re: [PATCH v2] v2v: When picking a default kernel, favour non-debug kernels over debug kernels (RHBZ#1170073).
On Thursday 04 December 2014 10:21:40 Richard W.M. Jones wrote:
> ---
> 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 = {
>
2016 Sep 09
2
[PATCH] v2v: linux: Move kernel detection to a separate module.
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.
2016 Sep 09
0
[PATCH] v2v: linux: Move kernel detection to a separate module.
Create a new module [Linux_kernels] which does all kernel detection,
and also provides a place to define the kernel_info data structure.
This is essentially just code motion.
---
v2v/Makefile.am | 2 +
v2v/convert_linux.ml | 219 +++--------------------------------------------
v2v/linux_kernels.ml | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++
v2v/linux_kernels.mli | 50
2017 Apr 06
9
[PATCH v3 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.
2017 Apr 06
12
[PATCH v4 0/9] 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
v3: https://www.redhat.com/archives/libguestfs/2017-April/msg00051.html
v3 -> v4:
- Properly fix Xen PV-only kernel detection, and test it.
Rich.
2017 Apr 05
7
[PATCH 0/6] v2v: Add drivers for virtio-rng, balloon, pvpanic.
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
2017 Apr 05
9
[PATCH v2 0/8] v2v: Add drivers for virtio-rng, balloon, pvpanic.
v1 was posted here:
https://www.redhat.com/archives/libguestfs/2017-April/msg00031.html
v1 -> v2:
- Add support for -o glance.
- Add support for -o qemu.
- Fix the -o libvirt support for balloon as pointed out by Dan.
- Fix a test failure caused by changing libvirt XML output.
Rich.
2017 Apr 06
0
[PATCH v3 2/8] v2v: linux: Fix Xen PV-only detection.
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
2017 Apr 06
0
[PATCH v4 2/9] v2v: linux: Fix Xen PV-only detection.
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
2017 Apr 06
0
[PATCH v4 3/9] v2v: linux: Replace 'ki_supports_virtio' field.
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
2016 Oct 03
4
[PATCH v2 0/3] v2v: further bits of Debian/Ubuntu guests supports
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
2017 Apr 06
1
Re: [PATCH v4 3/9] v2v: linux: Replace 'ki_supports_virtio' field.
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
2020 Sep 23
3
[v2v PATCH 1/3] linux: remove warning for packages with no files
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
+++
2020 Sep 23
0
[v2v PATCH 3/3] linux: remove special handling of packages with no files
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
2016 Sep 27
8
[PATCH 0/3] v2v: further bits of Debian/Ubuntu guests supports
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
2016 Sep 27
0
[PATCH 1/3] v2v: linux kernels: set type of 'g'
Make sure the type checker can detect the real type of 'g', even when
adding more code using it in detect_kernels.
---
v2v/linux_kernels.ml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml
index 3819d26..b292921 100644
--- a/v2v/linux_kernels.ml
+++ b/v2v/linux_kernels.ml
@@ -49,7 +49,7 @@ let string_of_kernel_info ki =
2016 Feb 20
0
[PATCH v2 3/4] v2v: take requested caps into account when converting
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
2016 Feb 09
0
[PATCH 3/4] v2v: take requested caps into account when converting
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