Bug 1596810
Summary: | Transfer fails if local host belongs to another DC | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Nir Soffer <nsoffer> | ||||||
Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> | ||||||
Status: | CLOSED ERRATA | QA Contact: | |||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 7.6 | CC: | derez, juzhou, mxie, mzhan, nsoffer, ptoscano, rjones, tzheng, xiaodwan | ||||||
Target Milestone: | rc | ||||||||
Target Release: | 7.6 | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | V2V | ||||||||
Fixed In Version: | libguestfs-1.38.2-7.el7 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2018-10-30 07:45:56 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: | |||||||||
Bug Blocks: | 1588088 | ||||||||
Attachments: |
|
Description
Nir Soffer
2018-06-29 18:17:19 UTC
Moving this downstream since we'll have to fix it in RHEL 7.6.
I'm confused on this point:
> - virt-v2v should check that the host belongs to dc1
Why is checking the host not sufficient?
Created attachment 1455544 [details]
v2v log
Created attachment 1455546 [details]
ovirt engine log
(In reply to Richard W.M. Jones from comment #1) > Moving this downstream since we'll have to fix it in RHEL 7.6. > > I'm confused on this point: > > - virt-v2v should check that the host belongs to dc1 > Why is checking the host not sufficient? In ovirt every host blongs to a data center, and all storage in a data center belongs to the data center. Hosts in one data center cannot access storage in other data centers. For example in this setup: dc1 cluster1 host1 cluster2 host2 storage1 disk1 storage2 disk2 dc2 cluster3 host3 cluster4 host4 storage3 disk3 storage4 disk4 We can upload to disk1 and disk2 only from host1 and host2. host2 is good for upload even if it is not in cluster1 (where we create the vm). The correct way to check is probably be: 1. find the cluster by cluster name 2. find the dc from the cluster 3. check if the host belongs to this dc I don't know ovirt API enough to tell what is the best way to do this, but I'm sure Daniel can recommend a good way to do this. I hope we can do something like "search='hw_id=xxx-yyy and data-center=yyy-zzz'" Bug 1596851 is a similar variant of this issue. This patch avoid this issue when not using rhv-direct=true option: https://www.redhat.com/archives/libguestfs/2018-June/msg00170.html (In reply to Nir Soffer from comment #5) > (In reply to Richard W.M. Jones from comment #1) > > Moving this downstream since we'll have to fix it in RHEL 7.6. > > > > I'm confused on this point: > > > - virt-v2v should check that the host belongs to dc1 > > Why is checking the host not sufficient? > > In ovirt every host blongs to a data center, and all storage in a data center > belongs to the data center. Hosts in one data center cannot access storage > in other > data centers. > > For example in this setup: > > dc1 > cluster1 > host1 > cluster2 > host2 > storage1 > disk1 > storage2 > disk2 > dc2 > cluster3 > host3 > cluster4 > host4 > storage3 > disk3 > storage4 > disk4 > > We can upload to disk1 and disk2 only from host1 and host2. host2 is good for > upload even if it is not in cluster1 (where we create the vm). > > The correct way to check is probably be: > 1. find the cluster by cluster name > 2. find the dc from the cluster > 3. check if the host belongs to this dc > > I don't know ovirt API enough to tell what is the best way to do this, but > I'm > sure Daniel can recommend a good way to do this. > > I hope we can do something like > > "search='hw_id=xxx-yyy and data-center=yyy-zzz'" Right, for example: hosts = hosts_service.list( search='hw_id=DCBBBC71-B601-4BC2-B046-03FBF35D05AD and datacenter=Default', case_sensitive=False, ) As for the polling, transfer can start when ImageTransferPhase is TRANSFERRING. So we should check that it's the correct status before start transferring. E.g. while transfer.phase == types.ImageTransferPhase.INITIALIZING: time.sleep(1) transfer = transfer_service.get() if transfer.phase != types.ImageTransferPhase.TRANSFERRING: print "Can't start transfer, invalid status: {}".format(transfer.phase) sys.exit() Can you please attach also the relevant vdsm log. As the NPE is raised on PreapreImage: "at org.ovirt.engine.core.vdsbroker.vdsbroker.PrepareImageReturn.<init>(PrepareImageReturn.java:15) [vdsbroker.jar:]" Note that you can also add 'status' to the search (for the issue described in bug 1596851) i.e. search='hw_id=DCBBBC71-B601-4BC2-B046-03FBF35D05AD and datacenter=Default and status=Up' Fixed upstream in commit 4ed1bc5a79a77ad3a620b339f9ac2ecc8df6fd03. Try to reproduce the bug with builds: virt-v2v-1.38.2-6.el7.x86_64 libguestfs-1.38.2-6.el7.x86_64 libvirt-4.5.0-3.el7.x86_64 qemu-kvm-rhev-2.12.0-7.el7.x86_64 Reproduce steps: 1.Prepare test environment:there are two DataCenters on rhv4.2 and every Datacenter has its cluster, host and storage as below: Datercenter:NFS Cluster:NFS Host:NFS Storage:nfs_data Datercenter:ISCSI Cluster:ISCSI Host:ISCSI Storage:iscsi_data 2 Install virt-v2v on host "NFS" and try to convert guest from VMware to storage"iscsi_data", conversion is failed with same error with bug # virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win8.1-x86_64 -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os iscsi_data -op /tmp/rhvpasswd -oo rhv-cafile=/root/ca.pem -oo rhv-direct -of raw --password-file /tmp/passwd -b ovirtmgmt -oa preallocated -oo rhv-cluster=ISCSI [ 0.1] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win8.1-x86_64 [ 1.9] Creating an overlay to protect the source from being modified [ 2.7] Initializing the target -o rhv-upload -oa preallocated -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os iscsi_data [ 4.0] Opening the overlay [ 17.3] Inspecting the overlay [ 148.6] Checking for sufficient free disk space in the guest [ 148.6] Estimating space required on target for each disk [ 148.6] Converting Windows 8.1 Enterprise 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 are no virtio drivers available for this version of Windows (6.3 x86_64 Client). virt-v2v looks for drivers in /usr/share/virtio-win The guest will be configured to use slower emulated devices. virt-v2v: This guest does not have virtio drivers installed. [ 161.3] Mapping filesystem data to avoid copying unused and blank areas [ 162.1] Closing the overlay [ 162.2] Checking if the guest needs BIOS or UEFI to boot [ 162.2] Assigning disks to buses [ 162.2] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.aKmEGI/nbdkit1.sock", "file.export": "/" } (raw) nbdkit: error: /var/tmp/rhvupload.aKmEGI/rhv-upload-plugin.py: open: error: direct upload to host not supported, requires ovirt-engine >= 4.2 and only works when virt-v2v is run within the oVirt/RHV environment, eg. on an oVirt node. qemu-img: Could not open 'json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.aKmEGI/nbdkit1.sock", "file.export": "/" }': Failed to read data: Unexpected end-of-file before all bytes were read virt-v2v: error: qemu-img command failed, see earlier errors If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Verify the bug with builds: virt-v2v-1.38.2-8.el7.x86_64 libguestfs-1.38.2-8.el7.x86_64 libvirt-4.5.0-3.el7.x86_64 qemu-kvm-rhev-2.12.0-7.el7.x86_64 Steps: 1.Just update virt-v2v to latest version on nfs host and convert a guest from VMware to storage"iscsi_data" again # virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os iscsi_data -op /tmp/rhvpasswd -oo rhv-cafile=/root/ca.pem -oo rhv-direct -of raw --password-file /tmp/passwd -b ovirtmgmt -oa preallocated -oo rhv-cluster=ISCSI [ 0.1] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 [ 1.8] Creating an overlay to protect the source from being modified [ 2.6] Initializing the target -o rhv-upload -oa preallocated -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os iscsi_data [ 3.9] Opening the overlay [ 22.4] Inspecting the overlay [ 161.9] Checking for sufficient free disk space in the guest [ 161.9] Estimating space required on target for each disk [ 161.9] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [1273.2] Mapping filesystem data to avoid copying unused and blank areas [1275.3] Closing the overlay [1275.4] Checking if the guest needs BIOS or UEFI to boot [1275.4] Assigning disks to buses [1275.4] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.wYruaS/nbdkit1.sock", "file.export": "/" } (raw) (100.00/100%) [1997.8] Creating output metadata [2014.7] Finishing off 2.Power on guest on host "ISCSI" and checkpoints of guest are passed Result: Virt-v2v can convert guest successfully using rhv-upload when v2v conversion server and target data domain belong to different DataCenters of rhv4.2, so move the 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-2018:3021 |