search for: configure_display_driv

...less defined($desc); - die("configure_kernel_modules called without virtio argument") - unless defined($virtio); # Get a list of all old-hypervisor specific kernel modules which need to be # replaced or removed @@ -235,10 +221,6 @@ sub _configure_kernel_modules sub _configure_display_driver { my ($guestos, $virtio) = @_; - die("configure_display_driver called without guestos argument") - unless defined($guestos); - die("configure_display_driver called without virtio argument") - unless defined($virtio); $guestos->update_display...

...      | None -> get_display_driver () +      | None -> QLX        | Some video -> video in        let block_type = @@ -771,9 +771,6 @@ let convert (g : G.guestfs) inspect sour      else        true   -  and get_display_driver () = -    if family = `SUSE_family then Cirrus else QXL -    and configure_display_driver video =      let video_driver = match video with QXL -> "qxl" | Cirrus -> "cirrus" in I'd be happy to submit this as an official patch, or just let you do it with some of your planned changes. Thanks! Mike

Hi Mike, in 2013 you added the support for SUSE guests in the old virt-v2v (the one written in Perl); the commit doing it is attached, since the old virt-v2v was hosted on fedorahosted.org, which is no more. As part of that change, the default graphics driver was changed to be cirrus for SUSE guests, and qxl (as before) for any other. When Rich Jones rewrote virt-v2v in 2014 in OCaml, he kept

...hen Virtio_blk else IDE | Some block_type -> block_type in let net_type = match rcaps.rcaps_net_bus with - | None -> if virtio then Virtio_net else E1000 + | None -> if kernel.ki_supports_virtio_net then Virtio_net else E1000 | Some net_type -> net_type in configure_display_driver video; diff --git a/v2v/linux_kernels.ml b/v2v/linux_kernels.ml index 312d6d1c0..725bd03c2 100644 --- a/v2v/linux_kernels.ml +++ b/v2v/linux_kernels.ml @@ -38,18 +38,25 @@ type kernel_info = { ki_initrd : string option; ki_modpath : string; ki_modules : string list; - ki_supports_virtio...

...ock_type = + match rcaps.rcaps_block_bus with + | None -> if virtio then Virtio_blk else IDE + | Some block_type -> block_type in + + let net_type = + match rcaps.rcaps_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...

...ock_type = + match rcaps.rcaps_block_bus with + | None -> if virtio then Virtio_blk else IDE + | Some block_type -> block_type in + + let net_type = + match rcaps.rcaps_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...

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.

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.

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