Bug 2093401

Summary: Creating ESX compute resource on vcenter 7.x fails with InvalidArgument: A specified parameter was not correct: deviceChange[1].device.key
Product: Red Hat Satellite Reporter: Brad Buckingham <bbuckingham>
Component: Compute Resources - VMWareAssignee: Chris Roberts <chrobert>
Status: CLOSED DUPLICATE QA Contact: Lukáš Hellebrandt <lhellebr>
Severity: high Docs Contact:
Priority: high    
Version: 6.10.0CC: chrobert, mhulan, mjia, osousa, pcreech, pratshar, sadas, wclark
Target Milestone: UnspecifiedKeywords: Regression, Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: rubygem-fog-vsphere-3.5.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 2072696 Environment:
Last Closed: 2022-06-27 14:00:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 4 Lukáš Hellebrandt 2022-06-27 12:16:35 UTC 
Failed QA for the same reason as the 6.11 version of this BZ.

This usually works in low scale, see comment 13 in the original BZ. However, looking at the code, there is an ID being randomly selected in an interval of arbitrary size 5000 while its uniqueness is not being checked.

According to developers, the IDs only need to be unique for a single VM. First limitation that occurs here is that a VM can only have 5000 interfaces which I think is unnecessarily low but acceptable, a VM with more interfaces would be quite rare.

The important issue is, however, that the IDs are not being checked for uniqueness. When a VM has more than one interface, their IDs can be randomly generated the same, leading to an error. Chances of this are not small, for example, it would happen for every 5000th VM with 2 interfaces. Some of the larger customers are almost sure to hit this issue.

While this workaround isn't a real fix and doesn't scale, it makes VM provisioning on ESX 7 possible in most cases on small scale with reasonable amount of interfaces. Therefore, I think this shouldn't be considered fixed but also shouldn't be a release blocker, given the workaround code is present in the release.

I have reported bug 2101410 with a limited scope specified which can be verified to communicate this partial fix to customers in the 6.10.7 release information document.