search for: rebuild_initrd

...sed 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 > 'rebuild_initrd' function. Instead of making the module list > conditional on whether virtio-net is available and using the old > (probably wrong) fallback if it happens to be unavailable, this now > tries to enable the common virtio kernel modules (just the ones needed > for virtio-blk and virtio...

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

...el 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 'rebuild_initrd' function. Instead of making the module list conditional on whether virtio-net is available and using the old (probably wrong) fallback if it happens to be unavailable, this now tries to enable the common virtio kernel modules (just the ones needed for virtio-blk and virtio-net to work). The...

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.

...s_net_bus with + | None -> if virtio then Virtio_net else E1000 + | Some net_type -> net_type in + configure_display_driver video; - remap_block_devices virtio; - configure_kernel_modules virtio; + remap_block_devices block_type; + configure_kernel_modules block_type net_type; rebuild_initrd kernel; let guestcaps = { - gcaps_block_bus = if virtio then Virtio_blk else IDE; - gcaps_net_bus = if virtio then Virtio_net else E1000; + gcaps_block_bus = block_type; + gcaps_net_bus = net_type; gcaps_video = video; gcaps_arch = Utils.kvm_arch inspect.i_arch; gcap...

...s_net_bus with + | None -> if virtio then Virtio_net else E1000 + | Some net_type -> net_type in + configure_display_driver video; - remap_block_devices virtio; - configure_kernel_modules virtio; + remap_block_devices block_type; + configure_kernel_modules block_type net_type; rebuild_initrd kernel; let guestcaps = { - gcaps_block_bus = if virtio then Virtio_blk else IDE; - gcaps_net_bus = if virtio then Virtio_net else E1000; + gcaps_block_bus = block_type; + gcaps_net_bus = net_type; gcaps_video = video; gcaps_arch = Utils.kvm_arch inspect.i_arch; gcap...

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 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.

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.

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

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

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

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

v1 -> v2: - Add simple test of the setfiles API. - Use SELinux_relabel module in virt-v2v (instead of touch /.autorelabel). - Small fixes. Rich.