Bug 1161019
| Summary: | RFE: Only install RHEV-APT if virt-v2v -o rhev/-o vdsm option is used | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | tingting zheng <tzheng> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | Yehuda Zimmerman <yzimmerm> |
| Priority: | low | ||
| Version: | 7.1 | CC: | dyuan, juzhou, mbooth, mxie, mzhan, pasik, ptoscano, rjones |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | V2V | ||
| Fixed In Version: | libguestfs-1.36.1-1.el7 | Doc Type: | Bug Fix |
| Doc Text: |
*virt-v2v* only copies `rhev-apt.exe` and `rhsrvany.exe` when needed
Previously, *virt-v2v* always copied the `rhev-apt.exe` and `rhsrvany.exe` files when converting Windows guests. Consequently, they were present in the converted Windows guests, even when they were not needed. With this update, *virt-v2v* only copies these files when they are needed in the Windows guest.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 22:08:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1359086 | ||
| Bug Blocks: | |||
|
Description
tingting zheng
2014-11-06 07:37:40 UTC
Since I believe this is essentially cosmetic (the files do no harm) I'm moving this to RHEL 7.2. RHSRVANY is required for any Windows conversion (to run firstboot scripts), so it's not an error to install it if the target is KVM. However RHEV-APT could be avoided if the conversion is to KVM, ie. NOT -o rhev or -o vdsm. (not actually fixed yet, I'll post patches) I can reproduce the bug on builds: virt-v2v-1.32.7-3.el7.x86_64 libguestfs-1.32.7-3.el7.x86_64 libvirt-2.0.0-10.virtcov.el7_3.5.x86_64 qemu-kvm-rhev-2.6.0-28.cov.el7_3.1.x86_64 libguestfs-winsupport-7.2-1.el7.x86_64 virtio-win-1.9.0-3.el7.noarch Try to verify the bug with builds: virt-v2v-1.36.2-2.el7.x86_64 libguestfs-1.36.2-2.el7.x86_64 libvirt-3.1.0-2.el7.x86_64 qemu-kvm-rhev-2.8.0-6.el7.x86_64 libguestfs-winsupport-7.2-2.el7.x86_64 virtio-win-1.9.0-3.el7.noarch Steps: 1.Could find rhsrvany.exe and rhev-apt.exe on v2v conversion server # ls /usr/share/virt-tools/ rhev-apt.exe rhsrvany.exe 2.Convert a win7 guest from xen server to kvm by virt-v2v # virt-v2v -ic xen+ssh://10.73.3.21 xen-hvm-win7-x86_64 -of qcow2 3.After finishing conversion, Check if the files rhsrvany.exe and rhev-apt.exe exists on kvm Result: 3.1 There is not rhev-apt.exe under C:\ 3.2 There is not directory RedHat under C:\Programe Files, so there is not rhsrvany.exe under C:\Programe Files\RedHat\Firstboot 3.3 There is not RHSrvAny.exe under C:\Programe Files(x86)\RedHat\RHEV\apt 4.Convert the win7 guest to from xen server to rhv by virt-v2v # virt-v2v -ic xen+ssh://10.73.3.21 xen-hvm-win7-x86_64 -of qcow2 -o rhv -os 10.73.131.93:/home/nfs_export -on app-7.4 5.After finishing conversion, Check if the files rhsrvany.exe and rhev-apt.exe exists in guest on rhv Result: 5.1 There is rhev-apt.exe under C:\ 5.2 There is not directory RedHat under C:\Programe Files, so there is not rhsrvany.exe under C:\Programe Files\RedHat\Firstboot 5.3 There is RHSrvAny.exe under C:\Programe Files(x86)\RedHat\RHEV\apt Hi Pino, Because there is not RHSrvAny.exe in original guest on xen server, so I think RHSrvAny.exe is same with rhsrvany.exe, right? If so, why there is not RHSrvAny.exe when converting guest from xen to kvm by v2v? Hi Ming Xie, your observations on rhev-apt looks correct to me, now rhev-apt is copied in the guest only when the output mode (-o) is rhv or vdsm. This is basically what the changes in this bug were about. Regarding RHSrvAny, please note that: a) the location is changed, now is C:\Program Files\Guestfs\Firstboot b) it is installed if firstboot scripts are needed, no matter what the output mode is c) the path mentioned in 3.3 and 5.3 is not something libguestfs/v2v handles, and I guess it is provided by RHV itself Hi Pino, Thanks for your info, research when rhsrvany will be installed for windows guest as below: 1)I could find rhsrvany under C:\Program Files\Guestfs\Firstboot when converting windows guest from kvm/xen/vmware to rhv 2)But I can't find rhsrvany under C:\Program Files\Guestfs\Firstboot or any other directory in C:\ when converting windows guest from xen/vmware to kvm 3)I also can't find rhsrvany under C:\Program Files\Guestfs\Firstboot or any other directory in C:\ when converting windows guest from kvm/xen/vmware to glance According to above result, rhsrvany will be installed only when converting guest to rhv like rhev-apt Why rhsrvany is not installed if target hypervisor is kvm or glance,windows guest doesn't need firstboot script if target hypervisor is kvm or glance? (In reply to mxie from comment #11) > 1)I could find rhsrvany under C:\Program Files\Guestfs\Firstboot when > converting windows guest from kvm/xen/vmware to rhv When converting to RHV, rhev-apt is installed, and a firstboot script is needed to run it, so rhsrvany is installed. > 2)But I can't find rhsrvany under C:\Program Files\Guestfs\Firstboot or any > other directory in C:\ when converting windows guest from xen/vmware to kvm > > 3)I also can't find rhsrvany under C:\Program Files\Guestfs\Firstboot or any > other directory in C:\ when converting windows guest from kvm/xen/vmware to > glance No upnp_wait tool on the conversion server, and most probably there was no Red Hat Xen PV driver installed, nor Parallel Tools installed, hence no firstboot scripts were needed. > Why rhsrvany is not installed if target hypervisor is kvm or glance,windows > guest doesn't need firstboot script if target hypervisor is kvm or glance? No, that is because there was no need for firstboot scripts with the guests you tried, and thus rhsrvany was not installed. According to the comment 9 ~ comment12, this bug has been fixed, so 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/RHBA-2017:2023 |