yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #91717
[Bug 1992509] Re: Jammy's fix to CD-ROM device in OVF breaks VMware datasource
Hi James and Andrew,
I'm reopening this one since I can see DS OVF is always loaded when
deploying ubuntu-23.04-beta-cloudimg-amd64.ova onto vSphere. Cloud-init
version is 23.1.1. As Andrew mentioned in the description, ovfEnv.xml
constructed with OVF properties and put into an ISO file, the ISO file
attached to VM's CD-ROM device.
PR 1573 (https://github.com/canonical/cloud-init/pull/1573) cannot resolve this issue since in datasource_list, DS OVF is ahead of DS VMware.
Before PR 1573 change, the sequence of transports was:
1. local seed_dir (OVF)
2. customization cfg (OVF)
3. guestinfo.ovfEnv (OVF)
4. ISO cdrom (OVF)
5. EnvVars (VMware)
6. GuestInfo (VMware)
After PR 1573 change, the sequence of transports is:
1. local seed_dir (OVF)
2. guestinfo.ovfEnv (OVF)
3. ISO cdrom (OVF)
4. EnvVars (VMware)
5. GuestInfo (VMware)
6. customization cfg (OVF)
I'm thinking of that can we move DS VMware to be in front of DS OVF in cloud-init datasource search list? Not sure if this has been discussed or not, any concerns?
Best regards,
Pengpeng
** Changed in: cloud-init
Status: Expired => New
--
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/1992509
Title:
Jammy's fix to CD-ROM device in OVF breaks VMware datasource
Status in cloud-init:
New
Bug description:
At some point Canonical updated the OVF used to produce Jammy's OVA at
https://cloud-
images.ubuntu.com/releases/jammy/release-20220808/ubuntu-22.04-server-
cloudimg-amd64.ova from the OVF used to produce Impish's OVA at
https://cloud-
images.ubuntu.com/releases/impish/release-20220708/ubuntu-21.10-server-
cloudimg-amd64.ova. However, this update routinely causes failures in
the Cloud-Init Data Source for VMware at
https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html.
Technically speaking the VMware data source should have routinely
failed with Canonical's cloud OVA, but prior to Jammy there was a bug
in the OVF -- the CD-ROM device was parented to the wrong IDE
controller. The diff between the two OVFs is attached, but the
important bit was here:
> - <rasd:Parent>3</rasd:Parent>
> + <rasd:Parent>5</rasd:Parent>
The CD-ROM device in Impish is parented to device ID 3, which is the
following device:
> <Item>
> <rasd:Address>0</rasd:Address>
> <rasd:Description>SCSI Controller</rasd:Description>
> <rasd:ElementName>SCSI Controller 0</rasd:ElementName>
> <rasd:InstanceID>3</rasd:InstanceID>
> <rasd:ResourceSubType>VirtualSCSI</rasd:ResourceSubType>
> <rasd:ResourceType>6</rasd:ResourceType>
> </Item>
Except when parenting a CD-ROM device to a SCSI controller like this
causes vSphere 7.x+ (and perhaps earlier versions -- I could not
easily check) to quietly drop the CD-ROM device. However, on Jammy the
parent is device ID 5, which is the following device:
> <Item>
> <rasd:Address>1</rasd:Address>
> <rasd:Description>IDE Controller</rasd:Description>
> <rasd:ElementName>VirtualIDEController 1</rasd:ElementName>
> <rasd:InstanceID>5</rasd:InstanceID>
> <rasd:ResourceType>5</rasd:ResourceType>
> </Item>
Parenting a CD-ROM to an IDE controller is fine, and deploying the
Jammy OVA on vSphere 7.x+ results in a VM with a valid CD-ROM device.
And that is the root of the problem. Because now if the VM also has
one or more OVF properties defined, as the Ubuntu OVFs do, vSphere
will send that information into the guest using one of two transports:
ISO or GuestInfo (ESX --> VM RPC via VM Tools). Both Ubuntu OVFs
indicate to use the ISO transport:
> <VirtualHardwareSection ovf:transport="iso">
The ISO transport logic in vSphere is as follows:
1. if there are one or more OVF properties
2. construct an ISO file with the OVF environment and its properties
3. upload the ISO to a datastore accessible by the ESXi host where the VM is scheduled
4. attach the ISO file to the VM's CD-ROM device
When the VM is powered on, VM Tools reads the contents of the ISO
mounted to the CD-ROM device. However, the presence of the CD-ROM with
valid OVF environment data *also* results in the Cloud-Init OVF data
source
(https://cloudinit.readthedocs.io/en/latest/topics/datasources/ovf.html)
detecting that it should be loaded
(https://github.com/canonical/cloud-
init/blob/cd2cca35a1bf36b584422f431c3ddf55b820434c/tools/ds-
identify#L984-L1030). Once that occurs the VMware data source is not
loaded, even if there is valid data to do so
(https://github.com/canonical/cloud-
init/blob/cd2cca35a1bf36b584422f431c3ddf55b820434c/tools/ds-
identify#L1459-L1499).
The fix to the CD-ROM device is itself not an issue -- it *should*
have been fixed. In fact, if the CD-ROM was not fixed but the
"ovf:transport" value had been changed to "guestInfo" then the same
problem would have occurred as the OVF data source would have been
triggered that way and taken precedence over the VMware data source
(https://github.com/canonical/cloud-
init/blob/cd2cca35a1bf36b584422f431c3ddf55b820434c/tools/ds-
identify#L965-L982). However, while not strictly a problem in a
vacuum, the change *does* regress the prior behavior of the stock,
Ubuntu cloud images. All of a sudden the Jammy OVA, and presumably
future images, will trigger the OVF data source on vSphere instead of
the VMware data source when both were detected via ds_identify.
This is unfortunate, and I am not sure what can be done about it. The
fix to the CD-ROM was necessary, even if it did break the VMware data
source when OVF properties are defined in the OVF. What do y'all think
should occur?
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1992509/+subscriptions
References