Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1624902 - Fix rhev-apt command that virt-v2v runs in Windows guests on first boot
Summary: Fix rhev-apt command that virt-v2v runs in Windows guests on first boot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.6
Hardware: x86_64
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard: V2V
Depends On: 1621895
Blocks: 1625216
TreeView+ depends on / blocked
 
Reported: 2018-09-03 14:27 UTC by Richard W.M. Jones
Modified: 2019-08-06 12:45 UTC (History)
13 users (show)

Fixed In Version: libguestfs-1.40.1-1.el7
Doc Type: Bug Fix
Doc Text:
After converting a Windows virtual machine (VM) to RHV using the virt-v2v utility, the RHV Application Provisioning Tool (RHEV APT) service failed to start on that VM. This update fixes the invocation of the "RHEV APT" command, which enables RHV APT to start as expected in the converted VMs.
Clone Of: 1584678
: 1625216 1644277 (view as bug list)
Environment:
Last Closed: 2019-08-06 12:44:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1644277 1 None None None 2022-05-16 11:32:56 UTC
Red Hat Product Errata RHEA-2019:2096 0 None None None 2019-08-06 12:45:45 UTC

Internal Links: 1644277

Description Richard W.M. Jones 2018-09-03 14:27:25 UTC 
+++ 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?
Comment 2 Richard W.M. Jones 2018-09-03 14:32:01 UTC 
Patch posted:
https://www.redhat.com/archives/libguestfs/2018-September/msg00013.html
Comment 3 Richard W.M. Jones 2018-09-03 17:38:24 UTC 
Upstream in
e12c56176abcc2d970a35f83bffc95f7ad1b2aab
Comment 6 Pino Toscano 2019-01-17 11:47:46 UTC 
This bug will be fixed by the rebase scheduled for RHEL 7.7, see bug 1621895.
Comment 8 zhoujunqin 2019-03-12 09:12:39 UTC 
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.
Comment 9 zhoujunqin 2019-04-16 10:02:26 UTC 
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.
Comment 11 errata-xmlrpc 2019-08-06 12:44:27 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.