It is possible to select ISO from data domain in second dialog of VM Import flow. (See bug 1721443 however). But the ISO is passed incorrectly to VDSM and the import fails. Looking at VDSM log I see that when convertExternalVm() API call is invoked engine passes: u'virtio_iso_path': u'/rhev/data-center/mnt/gateway:_home_ISO/f06cfdfb-d117-4f75-b489-17039cd0b306/images/11111111-1111-1111-1111-111111111111/3437db2f-c8fb-465a-9bab-baaa1578c514' The path above is constructed from the path to ISO domain (!) and the disk ID (3437db2f-c8fb-465a-9bab-baaa1578c514) of the ISO selected. This is clearly wrong because there is no such file in the ISO domain.
Please provide more information for simulating this issue such as: 1. Which VM import are you referring to (what choice is being chosen for the source (Export Domain, VmWare, KVM, etc.)? 2. What would be the proper directory expected, such as this seems to be incorrect: "gateway:_home_ISO" 3. could you provide the ISO such as from a KVM server (if that is what you are testing for example). Thank you.
(In reply to Steven Rosenberg from comment #1) > Please provide more information for simulating this issue such as: > > 1. Which VM import are you referring to (what choice is being chosen for the > source (Export Domain, VmWare, KVM, etc.)? I used VMware as the source > 2. What would be the proper directory expected, such as this seems to be > incorrect: "gateway:_home_ISO" Pat should depend on the storage domain that contains the file. Right now it seems that it builds the path as: <path_to_iso_domain> + "/" + <domain_id> + "/images/111.../" + <iso_file_name> Which is wrong for files in data domain. It has to be made more general: <path_to_domain> + "/" + <doman_id> + "/images/" + <image_id> + "/" + <volume_id> > 3. could you provide the ISO such as from a KVM server (if that is what you > are testing for example). I'm not sure what you are asking here.
(In reply to Tomáš Golembiovský from comment #2) > (In reply to Steven Rosenberg from comment #1) > > Please provide more information for simulating this issue such as: > > > > 1. Which VM import are you referring to (what choice is being chosen for the > > source (Export Domain, VmWare, KVM, etc.)? > > I used VMware as the source > > > 2. What would be the proper directory expected, such as this seems to be > > incorrect: "gateway:_home_ISO" > > Pat should depend on the storage domain that contains the file. Right now it > seems that it builds the path as: > > <path_to_iso_domain> + "/" + <domain_id> + "/images/111.../" + > <iso_file_name> > > Which is wrong for files in data domain. It has to be made more general: > > <path_to_domain> + "/" + <doman_id> + "/images/" + <image_id> + "/" + > <volume_id> > > > 3. could you provide the ISO such as from a KVM server (if that is what you > > are testing for example). > > I'm not sure what you are asking here. From IRC: srosenbe> Good Morning. <srosenbe> I sat with Nisim yesterday on this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1721455 <srosenbe> We setup a virt-io repository with iso files. I then preformed an import and it succeeded without error. The VM also runs. <srosenbe> The issue may be with how the iso that you have behaves. <srosenbe> First of all it needs to be a virt-io iso. It should have an iso extension. <srosenbe> It is not clear why the file name is the GUID. <srosenbe> Please consider these issues. Is there some way we can obtain the file itself and add it to Nisim's repository so it can be simulated, or are we not following the criteria as per the iso requirements. Thank you.
The important factor here is that you do not use an ISO domain at all. Here are the steps to reproduce the problem: 1) get an ISO somewhere; ideally something that is not yet in your ISO domain (if you have one attached) to avoid confusion later 2) in Admin UI navigate to 'Storage -> Disks' and choose 'Upload -> Start' action 3) locate the ISO on your machine and start the disk upload 4) wait for the upload to finish 5) navigate to 'Compute -> Virtual Machines' and choose 'Import' action 6) choose VMware provider (actually that's what I used but imho any provider is OK) 7) fill in the needed fields, load the VM list and choose a VM to import 8) press Next to go to the second dialog 9) here check the box to use virtio drivers and select the ISO you have uploaded (look for ID at the end of the list -- bug 1721443) 10) click OK to start the import I don't know if this shows somewhere in engine.log but to validate on VDSM side what is being send you have to enable debug logs and look for the parameter to the `convertExternalVm` API call in vdsm.log. Another option is to check the environment variables of the virt-v2v process and look for `VIRTIO_WIN`. Note that the fact the VM import finishes does not mean the ISO was presented correctly. Specifying invalid ISO is not a fatal error so you really have to check logs or environment.
I did one more test and it seems you cannot start an import without active ISO domain. Out of curiosity I put my ISO domain into maintenance so that I see only ISOs from data domain in the list. After selecting the ISO and clicking OK I get an error: Invalid ISO image path Let me know if you want me to open a separate bug for this.
Created attachment 1582694 [details] Error when no ISO domain is active
I addressed the "Invalid ISO image path" validation issue because if we allow choosing an iso from a data domain we should allow the user to continue with the import even though an iso domain is not active in the system. Also, iso domain support will be removed in the future. I was not able to simulate the main issue, which seems to be due to the path. When uploading an iso from my local directory, there is no error and the import works fine: 2019-06-23 18:07:44,141+0300 INFO (jsonrpc/4) [api.host] START convertExternalVm(uri=u'vpx://administrator%40vsphere.local.lab.tlv.redhat.com/Compute_DC/Compute_Cluster/rose05.qa.lab.tlv.redhat.com?no_verify=1', username=u'administrator', password='********', vminfo={u'domainID': u'47e4ebac-6d85-4da8-9504-73886711fd58', u'format': u'RAW', u'disks': [{u'volumeID': u'ae7ff276-c2a1-4dc7-9706-26292afd1746', u'imageID': u'332d8fd4-7cad-4ee4-a9ce-f92218b9c15d'}], u'qcow2_compat': u'1.1', u'allocation': u'Sparse', u'poolID': u'5f8be1f5-4ac5-40cd-bf9c-7033d9f7d655', u'virtio_iso_path': u'/8c620fa6-e375-4f5e-b271-fe3fe8f3f75c', u'vmName': u'centos44'}, jobid=u'd68629f9-5cf3-44ae-bc5b-c0ac67857eb0') from=::ffff:10.35.1.148,42774, flow_id=3dff18f6-f3a5-4f97-b8a5-f3146d2ed052 (api:48) This is from the vdsm log and as one can see that the virtio_iso_path = "/8c620fa6-e375-4f5e-b271-fe3fe8f3f75c" Again the way you are mounting the path may have to do with the failure to access the file: /rhev/data-center/mnt/gateway:_home_ISO If you can provide more information on how you are mounting the drive itself and where the file actually sits, it may be easier to simulate this issue. Meanwhile, it seems to work fine locally. Thank you.
ISO domain support *may* be removed. Not a certainty yet
(In reply to Ryan Barry from comment #8) > ISO domain support *may* be removed. Not a certainty yet OK, Fred Rolland in Storage was pretty sure it would be. He was OK with removing the validation.
(In reply to Steven Rosenberg from comment #7) > This is from the vdsm log and as one can see that the virtio_iso_path = > "/8c620fa6-e375-4f5e-b271-fe3fe8f3f75c" Is this path valid on your VDSM host? Does it refer to the ISO image you have selected in the import dialog?
(In reply to Tomáš Golembiovský from comment #10) > (In reply to Steven Rosenberg from comment #7) > > This is from the vdsm log and as one can see that the virtio_iso_path = > > "/8c620fa6-e375-4f5e-b271-fe3fe8f3f75c" > > Is this path valid on your VDSM host? Does it refer to the ISO image you > have selected in the import dialog? OK, I did some checking and first of all 8c620fa6-e375-4f5e-b271-fe3fe8f3f75c is the GUID of the iso that was loaded in your 2-3 instructions, so that part is correct. In searching the log I do find that other image files do point to fully qualified paths on the storage domain, for example: 'path': u'/rhev/data-center/mnt/vserver-spider.eng.lab.tlv.redhat.com:_pub_srosenbe_engine__44/47e4ebac-6d85-4da8-9504-73886711fd58/images/332d8fd4-7cad-4ee4-a9ce-f92218b9c15d/ae7ff276-c2a1-4dc7-9706-26292afd1746' This is in the format of your example: /rhev/data-center/mnt/gateway:_home_ISO/f06cfdfb-d117-4f75-b489-17039cd0b306/images/11111111-1111-1111-1111-111111111111/3437db2f-c8fb-465a-9bab-baaa1578c514 Both of which seem to fit your format: <path_to_domain> + "/" + <doman_id> + "/images/" + <image_id> + "/" + <volume_id> I assume what you are saying is that 11111111-1111-1111-1111-111111111111 is not a valid image_id and therefore the directory representing that does not exist. It seems there are a few issues: 1. Why the vdsm log is not giving an error in either scenario when the path is wrong. 2. Why in my testing the actual path is missing, just the volume id is sent. 3. Why in your scenario it does send the fully qualified path incorrectly (incorrect image id?) I will investigate further now that I understand better what is expected, more feedback from you will help as well concerning whether it is just the imageId or other aspects of the path/file that are not correct, etc.
(In reply to Steven Rosenberg from comment #11) > (In reply to Tomáš Golembiovský from comment #10) > > (In reply to Steven Rosenberg from comment #7) > It seems there are a few issues: > > 1. Why the vdsm log is not giving an error in either scenario when the path > is wrong. Yes, I already mentioned in comment 4. VDSM does not check the path and virt-v2v does not complain when the path is invalid. > 2. Why in my testing the actual path is missing, just the volume id is sent. That I do not know. Could it be that you have no ISO domain at all and you have applied the patch for validation? > 3. Why in your scenario it does send the fully qualified path incorrectly > (incorrect image id?) Let me provide more information about my environment. That may help you understand what is happening and what should be the expected behavior. I have two domains in my cluster: /rhev/data-center/mnt/gateway:_home_ISO -- this is a mount point for ISO domain (NFS) /rhev/data-center/mnt/gateway:_home_data_ovirt-master-data -- this is a mount point for data domain (NFS) What engine is sending is: /rhev/data-center/mnt/gateway:_home_ISO/f06cfdfb-d117-4f75-b489-17039cd0b306/images/11111111-1111-1111-1111-111111111111/3437db2f-c8fb-465a-9bab-baaa1578c514 You can see that this points to the ISO domain. That is wrong because I selected image from data domain. The last part of the path -- 3437db2f-c8fb-465a-9bab-baaa1578c514 -- is the disk ID of the image I have selected. Now compare that with the correct path that engine *should* send for this image: /rhev/data-center/mnt/gateway:_home_data_ovirt-master-data/b4f43e42-56c8-40ac-acce-830dd1cbfd8e/images/3437db2f-c8fb-465a-9bab-baaa1578c514/502ec83b-0016-4db1-9262-e1b3e456755d Hope this helps. Let me know if you need more info.
(In reply to Tomáš Golembiovský from comment #0) Maybe this is the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1589763#c22
Note: For Block Storage, this issue is dependent upon: https://bugzilla.redhat.com/show_bug.cgi?id=1727164
Note: For concurrency issues, dependent upon: https://bugzilla.redhat.com/show_bug.cgi?id=1725915
This bug/RFE is more than 2 years old and it didn't get enough attention so far, and is now flagged as pending close. Please review if it is still relevant and provide additional details/justification/patches if you believe it should get more attention for the next oVirt release.
We rely on having ISO domain on some import flows but we also expect users to upload ISOs to data domains, so without this, users would have to have their ISOs in two different places Therefore it makes sense to us to invest in enabling this
*** Bug 2109021 has been marked as a duplicate of this bug. ***
This bug has low overall severity and is not going to be further verified by QE. If you believe special care is required, feel free to properly align relevant severity, flags and keywords to raise PM_Score or use one of the Bumps ('PrioBumpField', 'PrioBumpGSS', 'PrioBumpPM', 'PrioBumpQA') in Keywords to raise it's PM_Score above verification threashold (1000).
This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status.