we need to reflect the virtio-rng device generated in v2v's OVF when we create the oVirt VM entity. Actually, this may not be needed if we make it enabled by default by adding to Blank template(this is currently unplanned) +++ This bug was initially created as a clone of Bug #1438794 +++ Description of problem: I don't think today we install the driver for virtio-rng on Windows VMs. We should install it on supported OSes automatically.
Also be helpful to get a definition of exactly what XML fragment we should add to the OVF output.
We need this for memory balloon device: <Item> <rasd:ResourceType>0</rasd:ResourceType> <Type>balloon</Type> <Device>memballoon</Device> </Item> And this for RNG device <Item> <rasd:ResourceType>0</rasd:ResourceType> <Type>rng</Type> <Device>virtio</Device> </Item> I've already sent a patch for virt-v2v https://www.redhat.com/archives/libguestfs/2017-April/msg00092.html
A patch was merged in virt-v2v, the commit is: dac5fc53acdd1e51be2957c67e1e063e2132e680 The final version of the patch is: https://www.redhat.com/archives/libguestfs/2017-April/msg00103.html
Update: there still isn't any stable release of libguestfs with this patch
We missed this patch for RHEL 7.5 because there isn't any RHEL/libguestfs bug for it. Do we need this in RHEL 7.5? It's probably too late unfortunately.
Michal, could you take care of a downstream bug for v2v for RHEL 7.7 if this is still needed? Thanks! Martin
Still(!) no bug for libguestfs. However this patch was included anyway in virt-v2v 1.38 which is what we rebased to, so we're good for RHEL *7.6*.
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
this seems to be already in libguestfs, should be only tested
looks good to me
Verification version: rhvm-4.3.3.3-0.1.el7 libvirt-4.5.0-10.el7_6.7.x86_64 vdsm-4.30.13-1.el7ev.x86_64 sanlock-3.6.0-1.el7.x86_64 qemu-kvm-rhev-2.12.0-21.el7.x86_64 virt-v2v-1.38.2-12.29.lp.el7ev.x86_64 Verification scenario: Polarion test case added to external trackers.
This bugzilla is included in oVirt 4.3.1 release, published on February 28th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.