yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1977759@xxxxxxxxxxxxxxxxxx>]

[Expired for cloud-init because there has been no activity for 60 days.]

** Changed in: cloud-init
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1977759

Title:
  VMware vs OVF Detection Bug

Status in cloud-init:
  Expired

Bug description:
  Originally reported in IRC, there appears to be a bug in cloud
  detection for VMware. The user was attempting to run a RHEL 8 instance
  on VMware vSphere 7.0.2

  Initially the user reported an issue that appears fixed by [this
  patch](https://bugs.launchpad.net/cloud-init/+bug/1894837/comments/8)
  (should we upstream this?). After applying the patch, the user ran
  into another issue, this time OVF was detected rather than the vmware
  datasource.

  From the user:
  > I seems that salt-cloud is the reason why. It seems to deploy using pyVmomi and using VMware Tools and VMware guest customization with the OVF datasource.

  I see that cloud-init datasource detection does check for vmware tools installed [here](https://github.com/canonical/cloud-init/blob/8dca3ad01827e141e13d8d1169e4d31a4d164728/tools/ds-identify#L940), which I
  suspect causes ds-identify to include OVF as an option, leading to this issue.

  The user has the following GH gist documenting this issue:
  https://gist.github.com/jbfriedrich/348e988ba26a5a8631d7b33395a0ca90

  The user worked around the datasource mis-detection, but discovered
  that salt-cloud doesn't configure the hypervisor correctly which leads
  to disabled virtual nics in the guest.

  While we can't fix the salt-cloud issue, I think we should consider
  upstreaming the RHEL patch and fix the vmware detection issues
  described here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1977759/+subscriptions