search for: source_other_n

So far v2v did not read the model of network interfaces, resulting in "virtio" as the model for such interfaces. Start reading the model, if available, mapping only E1000 for now. There are also other models, e.g. PCNet32 or VmxNet3, but they are ignored for now: reading them as Source_other_nic would result in v2v rejecting OVAs previously converted. --- v2v/parse_ovf_from_ova.ml | 7 ++++++- v2v/test-v2v-i-ova-formats.expected | 2 +- v2v/test-v2v-i-ova-gz.expected | 2 +- v2v/test-v2v-i-ova-subfolders.expected | 2 +- v2v/test-v2v-i-ova-subfolders.expected...

...on is useful and/or actionable for the user, which it isn't in this case. (I know we don't always obey that rule right now, but I think it's still a good rule ...) So I think a better way to do it would be: and s_nic_model = | Source_rtl8139 | Source_e1000 | Source_virtio_net | Source_other_nic of string and source_video = | Source_Cirrus | Source_QXL | Source_other_video of string and then change the match code to be something like: let model = match xpath_string "model/@type" with | None -> None | Some "virtio" -> Some Source_virtio_net...

...match xpath_string "model/@type" with + | None -> None + | Some "virtio" -> Some Source_virtio_net + | Some "e1000" -> Some Source_e1000 + | Some "rtl8139" -> Some Source_rtl8139 + | Some model -> Some (Source_other_nic model) in + let vnet_type = match xpath_string "@type" with | Some "network" -> Some Network @@ -340,6 +365,7 @@ let parse_libvirt_xml ?conn xml = let add_nic vnet = let nic = { s_mac = mac; + s_nic_mo...

...match xpath_string "model/@type" with + | None -> None + | Some "virtio" -> Some Source_virtio_net + | Some "e1000" -> Some Source_e1000 + | Some "rtl8139" -> Some Source_rtl8139 + | Some model -> Some (Source_other_nic model) in + let vnet_type = match xpath_string "@type" with | Some "network" -> Some Network @@ -340,6 +365,7 @@ let parse_libvirt_xml ?conn xml = let add_nic vnet = let nic = { s_mac = mac; + s_nic_mo...

...twork interfaces, resulting in > "virtio" as the model for such interfaces. > > Start reading the model, if available, mapping only E1000 for now. Looks sensible, ACK. > There are also other models, e.g. PCNet32 or VmxNet3, but they are > ignored for now: reading them as Source_other_nic would result in v2v > rejecting OVAs previously converted. -i vmx and -i libvirt(xml) does parse them as Source_other_nic. Apart from rcaps_from_source which is only used by --in-place conversions the NIC model is basically ignored everywhere. So I think it would be safe to modify this patc...

...r | actionable for the user, which it isn't in this case. (I know we | don't always obey that rule right now, but I think it's still a good | rule ...) | | So I think a better way to do it would be: | | and s_nic_model = | | Source_rtl8139 | Source_e1000 | Source_virtio_net | | Source_other_nic of string | | and source_video = | | Source_Cirrus | Source_QXL | | Source_other_video of string | | and then change the match code to be something like: | | let model = | match xpath_string "model/@type" with | | None -> None | | Some "virtio" ->...

...+88,7 @@ and source_nic = { s_vnet_orig : string; (** Original network (if we map it). *) s_vnet_type : vnet_type; (** Source network type. *) } -(** Network adapter models. *) +(** Network adapter models (in ascending order of preference). *) and s_nic_model = Source_other_nic of string | Source_rtl8139 | Source_e1000 | Source_virtio_net (** Network interfaces. *) @@ -108,7 +108,7 @@ and s_display_listen = | LAddress of string (** Listen address. *) | LNetwork of string (** Listen network. *) -(** Video adapter model....

...gt; s_vnet_orig : string; (** Original network (if we map it). *) > s_vnet_type : vnet_type; (** Source network type. *) > } > -(** Network adapter models. *) > +(** Network adapter models (in ascending order of preference). *) > and s_nic_model = Source_other_nic of string | > Source_rtl8139 | Source_e1000 | Source_virtio_net > (** Network interfaces. *) > @@ -108,7 +108,7 @@ and s_display_listen = > | LAddress of string (** Listen address. *) > | LNetwork of string (** Listen network. *) &g...

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

...> 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 > > + > > + { &gt...

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

Deep in the discussion of this bug, unfortunately mostly in private comments: https://bugzilla.redhat.com/show_bug.cgi?id=1594515 we decided it'd be more flexible for RHV if we had a way to map individual NICs to target networks and bridges. This can be done by adding a new --mac option so you can specify the exact mapping you need: $ virt-v2v [...] \ --mac

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

https://bugzilla.redhat.com/show_bug.cgi?id=1570407 This turned into quite an in-depth refactoring of how we handle OVAs. It also fixes a potential security issue. Rich.

https://bugzilla.redhat.com/show_bug.cgi?id=1441197