| Summary: | remove virtio-win drivers drop down for KVM imports | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Michal Skrivanek <michal.skrivanek> |
| Component: | BLL.Virt | Assignee: | Sharon Gratch <sgratch> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | sefi litmanovich <slitmano> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 4.0.2.2 | CC: | bugs, mgoldboi, michal.skrivanek, mkalinin, nsimsolo, sgratch, tgolembi, tjelinek |
| Target Milestone: | ovirt-4.1.1 | Flags: | rule-engine:
ovirt-4.1+
rule-engine: planning_ack+ rule-engine: devel_ack+ mavital: testing_ack+ |
| Target Release: | 4.1.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1362186 | Environment: | |
| Last Closed: | 2017-04-21 09:46:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1362186 | ||
|
Description
Michal Skrivanek
2016-09-09 07:33:05 UTC
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. |