Re: [Libguestfs] [PATCH v2 4/4] v2v: in-place: request caps based on source config
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.
>
> For that, the source configuration is used to populate requested caps
> object which is then passed to the convert routine.
[...]
> +and rcaps_from_source source =
> + (* Request guest caps based on source configuration. *)
> +
> + (* rely on s_controller enum being in ascending preference order, and None
> + * being smaller than Some anything *)
> + let best_block_type =
> + List.fold_left max None
> + (List.map (fun sd -> sd.s_controller) source.s_disks) in
> + let block_type =
> + match best_block_type with
> + | Some Source_virtio_blk -> Some Virtio_blk
> + | Some Source_SCSI -> None
> + | Some Source_IDE -> Some IDE
> + | None -> None in
> +
> + (* rely on s_nic_model enum being in ascending preference order, and None
> + * being smaller than Some anything *)
> + let best_net_type =
> + List.fold_left max None
> + (List.map (fun nic -> nic.s_nic_model) source.s_nics) in
> + let net_type =
> + match best_net_type with
> + | Some Source_virtio_net -> Some Virtio_net
> + | Some Source_e1000 -> Some E1000
> + | Some Source_rtl8139 -> Some RTL8139
> + | Some Source_other_nic _ | None -> None in
> +
> + let video =
> + match source.s_video with
> + | Some Source_QXL -> Some QXL
> + | Some Source_Cirrus -> Some Cirrus
> + | Some Source_other_video _ | None -> None in
> +
> + {
> + rcaps_block_bus = block_type;
> + rcaps_net_bus = net_type;
> + rcaps_video = video;
> + }
> +
> let () = run_main_and_handle_errors main
It's a bit surprising, because I thought that you'd want to pass in
the requested preferences on the command line?
Passing that on the command line makes sense for the copying mode,
because in that mode there's no other place where to affect the choices.
In the in-place mode virt-v2v is given a VM with the configuration
already converted and the choices made (with or without user
interaction); v2v is only expected to tune the guest to work in that
configuration. So in that case rcaps are based on the source (==
target) VM properties.
About the specific issue of ordering, although what you've
written
works, you could find a few surprises. eg:
I suspected that, but failed to come up with a cleaner approach like the
one you suggested. Thanks, I'll rework the patch and resubmit.
Roman.