Description of problem: ISO domain required on imported from KVM (via Libvirt). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Import VM from KVM without having a ISO domain setup. The imports fails with the error "Invalid ISO image path" Actual results: VM fails to import. Expected results: VM should import without ISO domain setup. Additional info: Adding a ISO domain allows to import to succeed, but no iso files need to added to the domain. Since the domain can be empty why is it required?
Scott hi, can you provide the logs? Does your original KVM VM had a CD attached? If you could also provide the libvirt XML from the source VM
Created attachment 1522768 [details] XML of original VM
Hello, The original VM did not have a CD attached. I create a new VM for testing without a CD. I attempted to import the test VM. The pertinent part of engine.log is below. I assume that is the log you are referring to? 2019-01-23 10:57:23,058-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand] (DefaultQuartzScheduler6) [7e0c8781] START, GlusterServersListVDSCommand(HostName = node3, VdsIdVDSCommandParametersBase:{hostId='0f3cfb4b-03b7-491e-9cca-28cb66927b65'}), log id: 43bab053 2019-01-23 10:57:23,380-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand] (DefaultQuartzScheduler6) [7e0c8781] FINISH, GlusterServersListVDSCommand, return: [10.10.10.30/24:CONNECTED, node1:CONNECTED, node2:CONNECTED, noed4:CONNECTED], log id: 43bab053 2019-01-23 10:57:23,389-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler6) [7e0c8781] START, GlusterVolumesListVDSCommand(HostName = node3, GlusterVolumesListVDSParameters:{hostId='0f3cfb4b-03b7-491e-9cca-28cb66927b65'}), log id: 651b6b7a 2019-01-23 10:57:23,559-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler6) [7e0c8781] FINISH, GlusterVolumesListVDSCommand, return: {ee6d63e1-4a3e-4e3a-b7c3-63b2c648bcb7=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@5cfea895, 6fdce977-cb11-4ec4-a16f-1d7f47929995=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@663b5076}, log id: 651b6b7a 2019-01-23 10:57:24,700-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsNamesFromExternalProviderVDSCommand] (default task-8316) [c0c6ccaa-9952-41cd-b9b6-b4bca5bd1259] START, GetVmsNamesFromExternalProviderVDSCommand(HostName = ovirt-me5159-node1, GetVmsFromExternalProviderParameters:{hostId='2be5b54c-4964-4c91-80cc-b222580daf30', url='qemu+ssh://root@HOSTNAME/system', username='null', originType='KVM', namesOfVms='null'}), log id: 2e88e999 2019-01-23 10:57:25,526-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsNamesFromExternalProviderVDSCommand] (default task-8316) [c0c6ccaa-9952-41cd-b9b6-b4bca5bd1259] FINISH, GetVmsNamesFromExternalProviderVDSCommand, return: [VM [ImranAhmed_Ubuntu18.04], VM [cmc-stc-01], VM [ftp_rmason], VM [Matthew_Ubuntu], VM [termlicusersrv], VM [rdsqlsrv], VM [ssh], VM [dns2], VM [Matthew_SVN], VM [foreman], VM [nextcloud], VM [nemo], VM [dc2], VM [matlic], VM [printsrvx64], VM [mailhost], VM [tyr], VM [rhel7.5]], log id: 2e88e999 2019-01-23 10:57:38,604-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand] (DefaultQuartzScheduler5) [8187d0a] START, GlusterServersListVDSCommand(HostName = ovirt-me5159-node3, VdsIdVDSCommandParametersBase:{hostId='0f3cfb4b-03b7-491e-9cca-28cb66927b65'}), log id: 414476fb 2019-01-23 10:57:38,951-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand] (DefaultQuartzScheduler5) [8187d0a] FINISH, GlusterServersListVDSCommand, return: [10.10.10.30/24:CONNECTED, ovirt-node1:CONNECTED, node2:CONNECTED, node4:CONNECTED], log id: 414476fb 2019-01-23 10:57:38,964-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler5) [8187d0a] START, GlusterVolumesListVDSCommand(HostName = ovirt-me5159-node3, GlusterVolumesListVDSParameters:{hostId='0f3cfb4b-03b7-491e-9cca-28cb66927b65'}), log id: 4b84389e 2019-01-23 10:57:39,139-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler5) [8187d0a] FINISH, GlusterVolumesListVDSCommand, return: {ee6d63e1-4a3e-4e3a-b7c3-63b2c648bcb7=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@5cfea895, 6fdce977-cb11-4ec4-a16f-1d7f47929995=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@663b5076}, log id: 4b84389e 2019-01-23 10:57:39,255-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFullInfoFromExternalProviderVDSCommand] (default task-8316) [221c8730-53db-4b31-93fa-7ab9f9b51734] START, GetVmsFullInfoFromExternalProviderVDSCommand(HostName = ovirt-me5159-node1, GetVmsFromExternalProviderParameters:{hostId='2be5b54c-4964-4c91-80cc-b222580daf30', url='qemu+ssh://root@HOSTNAME/system', username='null', originType='KVM', namesOfVms='[rhel7.5]'}), log id: 5d05be3e 2019-01-23 10:57:39,717-05 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFullInfoFromExternalProviderVDSCommand] (default task-8316) [221c8730-53db-4b31-93fa-7ab9f9b51734] FINISH, GetVmsFullInfoFromExternalProviderVDSCommand, return: [VM [rhel7.5]], log id: 5d05be3e 2019-01-23 10:57:40,096-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand] (default task-8316) [8ea2f137-bb01-432e-9ad4-9b1348a3a4ee] START, GlusterServersListVDSCommand(HostName = ovirt-me5159-node3, VdsIdVDSCommandParametersBase:{hostId='0f3cfb4b-03b7-491e-9cca-28cb66927b65'}), log id: 862aa0a 2019-01-23 10:57:40,437-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterServersListVDSCommand] (default task-8316) [8ea2f137-bb01-432e-9ad4-9b1348a3a4ee] FINISH, GlusterServersListVDSCommand, return: [10.10.10.30/24:CONNECTED, node1:CONNECTED, node2:CONNECTED, node4:CONNECTED], log id: 862aa0a 2019-01-23 10:57:41,172-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterTasksListVDSCommand] (DefaultQuartzScheduler2) [22e708fe] START, GlusterTasksListVDSCommand(HostName = ovirt-me5159-node3, VdsIdVDSCommandParametersBase:{hostId='0f3cfb4b-03b7-491e-9cca-28cb66927b65'}), log id: 14bf6361 2019-01-23 10:57:41,364-05 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterTasksListVDSCommand] (DefaultQuartzScheduler2) [22e708fe] FINISH, GlusterTasksListVDSCommand, return: [], log id: 14bf6361 2019-01-23 10:57:44,542-05 INFO [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (default task-8316) [7d5cdc30-9ba0-4220-9c19-9899838835a9] Lock Acquired to object 'EngineLock:{exclusiveLocks='[1698bb1e-2b2c-4c6a-8684-060aa63d262d=VM, rhel7.5=VM_NAME]', sharedLocks=''}' 2019-01-23 10:57:44,600-05 WARN [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (default task-8316) [] Validation of action 'ImportVmFromExternalProvider' failed for user admin@internal-authz. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH 2019-01-23 10:57:44,601-05 INFO [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (default task-8316) [] Lock freed to object 'EngineLock:{exclusiveLocks='[1698bb1e-2b2c-4c6a-8684-060aa63d262d=VM, rhel7.5=VM_NAME]', sharedLocks=''}'
I think that Virt team should take a look at this. The validation in ImportVmFromExternalProviderCommand.java: if (getParameters().getVirtioIsoName() != null && getActiveIsoDomainId() == null) { return failValidation(EngineMessage.ERROR_CANNOT_FIND_ISO_IMAGE_PATH); } Needs to investigate why is VirtoIsoName populated.
I have similar problem with Ovirt 4.3.3. The kvm had an iso image connected with CD drive. So it reported "Invalid ISO image path" for import. However, even I removed iso image from kvm, the error is still there. Only work around is to generate an empty iso domain.
I have the same issue on oVirt 4.3.5.
Though I found other issues with KVM importing and fixed them, I was not able to simulate this issue. I imported VMs with a referenced iso file onto a DC / Cluster that did not have an iso storage domain referenced and the KVM import succeeded. I am testing on the current master (ovirt 4.4). Maybe this issue is outdated.
I see this bug : On oVirt 4.3.7, trying to import a vm from a remote libvirt Centos 7.4 host The vm to import does not have a CDROM device, only one virtio system disk import doesn't start, I get "invalid iso image path"
I solved the import problem by creating an NFS ISO Domain on oVirt. It should not be necessary to have an ISO domain in order to import vm that do not have disk drives
(In reply to Guillaume Pavese from comment #12) > I solved the import problem by creating an NFS ISO Domain on oVirt. > > It should not be necessary to have an ISO domain in order to import vm that > do not have disk drives Please note, the issue you describe is being addressed in 1632068. Thank you.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days