+++ This bug was initially created as a clone of Bug #1584678 +++ Description of problem: There is no rhev-apt serivce running by executing command "net start" in windows guest after v2v converting to rhv Version-Release number of selected component (if applicable): virt-v2v-1.38.2-3.el7.x86_64 libguestfs-1.38.2-3.el7.x86_64 libvirt-4.3.0-1.el7.x86_64 qemu-kvm-rhev-2.12.0-2.el7.x86_64 virtio-win-1.9.4-2.el7.noarch RHV:4.2.4-0.1.el7 How reproducible: 100% --- Additional comment from Lev Veyde on 2018-09-03 10:01:01 EDT --- (In reply to Richard W.M. Jones from comment #11) > What happens is very odd. > > The two commands we run as: > > rhev-apt /s /v /qn > net start rhev-apt > > The first command on Windows Server 2012 R2 opens an interactive > "InstallShield"-style window. However we asked for it to run > non-interactively, so this is a bug. > > The second command either fails or succeeds. If the InstallShield > thing hasn't finished running then it fails with the error described > previously. if the InstallShield thing has finished then the second > command succeeds. There are actually 2 issues here. First issue - you run it incorrectly. It supposed to be: /S /v/qn - note the big S in /S and that /v/qn options have no space between them. Second issue - the service start in silent RHEV-Apt installation seems to be broken (and looking at the code may never work), not sure how/why QA never noticed it, probably because it's only relevant in such edge cases, as after the reboot the service will be started normally, so it will be irrelevant. If/once the second issue is fixed you won't have to run manually the "net start" command, unless if that what you actually want (in which case please note this in the BZ). If you need the service start in silent mode to be fixed, please open BZ. Adding Sandro. --- Additional comment from Lev Veyde on 2018-09-03 10:16:48 EDT --- (In reply to Richard W.M. Jones from comment #14) > There shouldn't be any difference. The embedded copy of RHEV-APT > was last updated on 15 May 2018 which was before this bug was > reported, and both versions of virt-v2v have the same embedded > version. However we suspect the bug might not be 100% reproducible. Just one more note/clarification - the logic/flow is supposed to be same under all OS versions (and since you're not actually running it in silent mode due to the wrong options, the service should actually be started on all OS versions), so not sure why you only have issues under Windows 2K12R2, that needs to be further investigated. The fact that you get issue running "net start" before the setup finishes is OK - you can't really work with the service before it's installed. --- Additional comment from Red Hat Bugzilla Rules Engine on 2018-09-03 10:22:14 EDT --- Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone. --- Additional comment from Red Hat Bugzilla Rules Engine on 2018-09-03 10:22:24 EDT --- Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone. --- Additional comment from Richard W.M. Jones on 2018-09-03 10:22:51 EDT --- Actually comment 11 is slightly wrong. The actual command we are running now is: \rhev-apt.exe /S /v /qn I take it that the command we should be running is: \rhev-apt.exe /S /v/qn (ie. removing a single space). Is this correct? > If you need the service start in silent mode to be fixed, please open BZ. If I understand correct, there is a proposed change to make the service start up without needing an explicit "net start rhev-apt" command. Is it safe to leave the net start command there, so that we can handle rhev-apt before and after the future change?
Patch posted: https://www.redhat.com/archives/libguestfs/2018-September/msg00013.html
Upstream in e12c56176abcc2d970a35f83bffc95f7ad1b2aab
This bug will be fixed by the rebase scheduled for RHEL 7.7, see bug 1621895.
Try to verify this bug with build: virt-v2v-1.40.2-1.el7.x86_64 libguestfs-1.40.2-1.el7.x86_64 libvirt-4.5.0-10.el7_6.6.x86_64 qemu-kvm-rhev-2.12.0-18.el7_6.3.x86_64 virtio-win-1.9.6-1.el7.noarch Steps: 1. Convert a windows guest from ESXi6.7 to rhv 4.3 by virt-v2v # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win2016-x86_64 --password-file /tmp/passwd -o rhv -os 10.66.144.40:/home/nfs_export -on esx6.7-win2016-x86_64-bug1624902 [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win2016-x86_64 [ 2.1] Creating an overlay to protect the source from being modified [ 3.0] Opening the overlay [ 19.9] Inspecting the overlay [ 173.1] Checking for sufficient free disk space in the guest [ 173.1] Estimating space required on target for each disk [ 173.1] Converting Windows Server 2016 Standard to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: warning: there is no QXL driver for this version of Windows (10.0 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win/virtio-win.iso The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 202.3] Mapping filesystem data to avoid copying unused and blank areas [ 203.6] Closing the overlay [ 203.9] Assigning disks to buses [ 203.9] Checking if the guest needs BIOS or UEFI to boot [ 203.9] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [ 204.3] Copying disk 1/1 to /tmp/v2v.xES1rq/c980b640-cb59-47f7-a0fe-90312d33deae/images/98d034f7-4db7-446b-affa-4aba0ec02437/c500c9a0-4d64-4bd8-a36b-d5fcf5ad8da9 (raw) (100.00/100%) [1114.4] Creating output metadata [1115.0] Finishing off 2. Import the guest from export domain to data domain after v2v finishing conversion 3. Check rhev-apt command in the 0001-configure-rhev-apt.bat in the C:/Program Files/Guestfs/Firstboot/scripts-done directory of the guest. @echo off echo installing rhev-apt "\rhev-apt.exe" /S /v/qn echo starting rhev-apt net start rhev-apt Result: The rhev-apt command that virt-v2v runs in windows guests on first boot has been fixed.
I try to verify this bug with packages: libvirt-4.5.0-11.el7.x86_64 libguestfs-1.40.2-3.el7.x86_64 virt-v2v-1.40.2-3.el7.x86_64 qemu-kvm-rhev-2.12.0-26.el7.x86_64 python-ovirt-engine-sdk4-4.3.1-1.el7ev.x86_64 rhv-guest-tools-iso-4.3-6.el7ev.noarch kernel: 3.10.0-1018.el7.x86_64 rhv:4.3.0.1-0.1.el7 1. Convert a windows guest from ESXi6.7 to rhv 4.3 by virt-v2v # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-win2019-x86_64-efi --password-file /tmp/passwd -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -oo rhv-cluster=nfs -of raw -b ovirtmgmt Exception AttributeError: "'module' object has no attribute 'dump_plugin'" in <module 'threading' from '/usr/lib64/python2.7/threading.pyc'> ignored [ 0.2] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win2019-x86_64-efi -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 2.3] Creating an overlay to protect the source from being modified [ 6.2] Opening the overlay [ 12.8] Inspecting the overlay [ 18.1] Checking for sufficient free disk space in the guest [ 18.1] Estimating space required on target for each disk [ 18.1] Converting Windows Server 2019 Standard to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: warning: there is no QXL driver for this version of Windows (10.0 x86_64). virt-v2v looks for this driver in /usr/share/rhv-guest-tools-iso/rhv-tools-setup.iso The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 23.0] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda2 failed. Usually you can ignore this message. To find out more read "Trimming" in virt-v2v(1). Original message: fstrim: fstrim: /sysroot/: the discard operation is not supported [ 24.3] Closing the overlay [ 24.5] Assigning disks to buses [ 24.5] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 24.5] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data [ 26.3] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.NGaHKS/nbdkit0.sock", "file.export": "/" } (raw) (100.00/100%) [1378.6] Creating output metadata [1398.3] Finishing off 2. Start vm on rhv4.3 after v2v finishing conversion. 3. Check rhev-apt command in the 0001-configure-rhev-apt.bat in the C:/Program Files/Guestfs/Firstboot/scripts-done directory of the guest. @echo off echo installing rhev-apt "\rhev-apt.exe" /S /v/qn echo starting rhev-apt net start rhev-apt Result: The RHEV-apt command that virt-v2v runs in windows guests on first boot has been fixed, so i move this bug from ON_QA to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:2096