Fixes #272 - ESX compute resource on vcenter 7.x fails with InvalidAr…

[phess]

…gument: A specified parameter was not correct: deviceChange[1].device.key.

The fix is to force members of new_nics (i.e. NICs that the template VM did not have but are being added to the new VM) to pass a random negative integer for the device.key value.

Originally, a key of 0 was being passed for all new NICs, so if any existing NIC (or any other new NIC) already had a key of 0 this new VM would fail to be created. vSphere before 7.0 would mostly ignore this device.key value, so setting the same value of 0 for all NICs was fine. But starting with vSphere 7.0 this value absolutely has to be unique for each NIC, even if vSphere will not use the same values.

Anyway, this "new formality" of vSphere 7.x was hurting fog-vsphere's ability to create new VMs with NICs other than the ones already present in the VM template.

The range for the index was chosen kinda arbitrarily to lie between -25,000 and -29,999. As far as I can tell, any range will do. This range has shown to function properly for at least one customer.

[chris1984]

ACK, works great

[lhellebr]

@phess, @chris1984, looking at this PR, I have questions about scalability of this solution. You have chosen a very small interval of 5000 and do not check if you do not generate the same value twice, so:

1. If by chance (not that small in large scale) the same number will be generated, the operation will fail, correct?
2. As there are more and more VMs (and therefore more and more NICs) registered, the chance for collision will become increasingly big, eventually reaching to 100% as all 5000 IDs are used, efectivelly making the user unable to create a VM at all.

As I can easily imagine users with hundreds of thousands of VMs, I need to ask whether this solution really works for them. If not, this would be just a hotfix for one user who hit the issue now and this solves it for them.

[wbclark]

Am I correct in understanding that the interface ID generated randomly here is just a temporary placeholder which is only used during part of the cloning process, until it is replaced with the permanent (and positive integer valued) interace ID? In that case, I would expect collisions to be rare, and occur only when many VMs are being cloned simultaneously.

[chris1984]

@phess do you know the answer to the question from @lhellebr?

[phess]

@chris1984 and @lhellebr , as far as I can tell @wbclark 's reasoning is correct: collisions would only be possible between a single VM's multiple NICs.

In any case, using random numbers is probably not good enough to completely eliminate collisions even in a 5k-range. I suppose we could generate IDs incrementally so as to completely avoid those "lucky" collisions? Can ruby do something like C's newid=x++ where newid gets the current value of x and then x itself is incremented? If so, I believe this would be preferable to random IDs, and maybe the starting value of x could be random instead of every value of newid being random.

[lhellebr]

That sounds reasonable, I doubt anyone needs a VM with more than 5000 interfaces. But since the range is arbitrary, why not use a larger one?
If the IDs indeed only need to be unique within a single VM, making sure there will be no collisions (incremental value seems like an ok solution, beware of race conditions) would be enough for me to verify this.