+++ This bug was initially created as a clone of Bug #1362186 +++ ... (In reply to Michal Skrivanek from comment #4) > another minor fix is to actually remove the virtio drivers drop down as it > is not relevant to kvm imports. It just increases the confusion Aggreed.
Verified with rhevm-4.1.1-0.1.el7.noarch. Added KVM external provider with windows vms to my engine. Selected import action under vm menu, chose my external provider, chose the specific vm to import and proceeded to the next window in the menu. The virtio-win driver drop down was removed from this menu as expected. With VmWare provider thie drop down does exist as expected. One question that should be raised in this bug's context is regarding the REST API. I was able to import the same vm from the KVM provider when also included the driver_iso sub-attribute: <external_vm_import> <vm> <name>win7_KVM_local</name> </vm> <cluster id="{cluster_id}" /> <storage_domain id="{sd_id}" /> <name>win7_KVM_local</name> <sparse>true</sparse> <username>someusername</username> <password>somepassword</password> <provider>KVM</provider> <url>qemu+tcp://root@{kvm_host_url}/system?no_verify=0</url> <drivers_iso id="virtio-win-1.8.0.iso" /> </external_vm_import> This has no effect as the sub-attribute is redundant in this case, but maybe you want to consider failing such an API call with an informative message regarding the redundant sub-attribute?
(In reply to sefi litmanovich from comment #1) > One question that should be raised in this bug's context is regarding the > REST API. I was able to import the same vm from the KVM provider when also > included the driver_iso sub-attribute: > > <external_vm_import> > <vm> > <name>win7_KVM_local</name> > </vm> > <cluster id="{cluster_id}" /> > <storage_domain id="{sd_id}" /> > <name>win7_KVM_local</name> > <sparse>true</sparse> > <username>someusername</username> > <password>somepassword</password> > <provider>KVM</provider> > <url>qemu+tcp://root@{kvm_host_url}/system?no_verify=0</url> > <drivers_iso id="virtio-win-1.8.0.iso" /> > </external_vm_import> > > This has no effect as the sub-attribute is redundant in this case, but maybe > you want to consider failing such an API call with an informative message > regarding the redundant sub-attribute? Since virtio drivers have to be installed on KVM VMs prior to import (see Bug #1362186), then if nothing is break and this field is ignored for KVM vms then we are not sure we want to fail such an API call. Can you please make sure this is the case and this field doesn't cause the VM to fail afterwards in such cases? if it fail then we should handle this sub-attribute and if not then leave it as is.
This parameter should be ignored by VDSM and kvm2ovirt. So it definitely should not break any imported VM.