Hide Forgot
Description of problem: OtherResourceType element is missing in ovf file when importing VM without VNIC profile (imported from 3.2 engine) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create VM in 3.2 environment and export this VM 2. Import this VM to 3.3 environment 3. Check the ovf file Actual results: OtherResourceType is missing in the ovf file Expected results: OtherResourceType should exist but be empty Additional info: When creating ovf file with VNIC profile the OtherResourceType does exist
Since the vnic profiles feature was introduced in ovirt-engine 3.3, the OtherResourceType which represents the vnic profile name in the OVF should appear only in VMs/Templates exported from ovirt-engine 3.3. Therefore it is legit not having this field on exported vm from ovirt-engine 3.2.
re-opening so these two use cases will be tested: 1. export from 3.3 engine in 3.0-3.2 cluster levels should not have this, and should successfull import in a 3.0-3.2 engine (matching to export cluster level of course) 2. import to 3.2 and 3.3 cluster levels in a 3.3 engine works for a VM exported from 3.1 and 3.2 engine/cluster
(In reply to Itamar Heim from comment #2) > re-opening so these two use cases will be tested: > 1. export from 3.3 engine in 3.0-3.2 cluster levels should not have this, > and should successfull import in a 3.0-3.2 engine (matching to export > cluster level of course) Why there is concern regarding the appearance of this field (OtherResourceType which represents the vnic profile name) in 3.0-3.2 cluster levels ? It shouldn't cause the failure in import to engine 3.2 and will make the import to engine 3.3 (to any cluster level) more accurate. > > 2. import to 3.2 and 3.3 cluster levels in a 3.3 engine works for a VM > exported from 3.1 and 3.2 engine/cluster
(In reply to Moti Asayag from comment #3) > Why there is concern regarding the appearance of this field > (OtherResourceType which represents the vnic profile name) in 3.0-3.2 > cluster levels ? It shouldn't cause the failure in import to engine 3.2 and > will make the import to engine 3.3 (to any cluster level) more accurate. i see this as a considerable concept change, hence worth specific import/export testing (actually, a test case for testing import/export for backward/forward compatibility should happen in each version anyway, but that's a good scenario to make sure it is covered for.
Scenarios of importing VM with VNIC profile from 3.2 DC/CLuster to 3.2 DC/CLuster and from 3.3 to 3.2 were tested as a part of TCMS in other test cases
Closing - RHEV 3.3 Released