[Cross Port] Fix ovf disk bugs#1521
Open
faisalabujabal wants to merge 7 commits intovmware-tanzu:release/vc-9.1.0from
Open
[Cross Port] Fix ovf disk bugs#1521faisalabujabal wants to merge 7 commits intovmware-tanzu:release/vc-9.1.0from
faisalabujabal wants to merge 7 commits intovmware-tanzu:release/vc-9.1.0from
Conversation
…mware-tanzu#1482) When reconciling VMI status.disks we should consider, when present, the DeploymentOptionSection and the default configuration. This PR updates UpdateVmiWithOvfEnvelope() to: 1. Check for the presence of the DeploymentOptionSection 2. If present, - check for a confugration marked as default - if not configuration is marked explicitly as default, use the first configuration item 3. When populating status.disks, only consider those Items in VirtualHardware which - specify the default configuration via Item.Configuration, and - specify no configuration key via Item.Configuration, and therefore, apply to all configuation If no DeploymentOptionSection is present, then we consider all Items in VirtualHardware as is currently done.
…-tanzu#1509) As of now, if the underlying datastore supports both 4kn and 512n logical sector sizes, then we end up favoring the 4kn size. The vSphere API docs mention that we should be picking 512n, so do that instead.
This patch allows images with no disks to bypass the quota check.
This patch supports fast-deploy with disks not backed by files in the OVF.
This patch adds VM deploy tests using stock, VMware images.
This patch udpates how VMI status information is realized from OVFS. The OVF is first converted to a ConfigSpec in order to benefit from GoVmomi's ability to manage deployment configs and virtual system collections.
When populating a VMI status.disk, we may encounter disks which have
duplicate names. For example
```
...
<DiskSection>
<Info>Virtual disk information</Info>
<Disk ovf:capacity="107373568" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" />
<Disk ovf:capacity="107373568" ovf:diskId="vmdisk2" ovf:fileRef="file2" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" />
</DiskSection>
...
<VirtualHardwareSection>
...
<Item>
<rasd:AddressOnParent>0</rasd:AddressOnParent>
<rasd:ElementName>Hard disk 1</rasd:ElementName>
<rasd:HostResource>ovf:/disk/vmdisk1</rasd:HostResource>
<rasd:InstanceID>8</rasd:InstanceID>
<rasd:Parent>3</rasd:Parent>
<rasd:ResourceType>17</rasd:ResourceType>
</Item>
<Item>
<rasd:AddressOnParent>1</rasd:AddressOnParent>
<rasd:ElementName>Hard disk 1</rasd:ElementName>
<rasd:HostResource>ovf:/disk/vmdisk2</rasd:HostResource>
<rasd:InstanceID>9</rasd:InstanceID>
<rasd:Parent>3</rasd:Parent>
<rasd:ResourceType>17</rasd:ResourceType>
</Item>
...
</VirtualHardwareSection>
...
```
or
```
...
<DiskSection>
<Info>Virtual disk information</Info>
<Disk ovf:capacity="107373568" ovf:diskId="vmdisk1" ovf:fileRef="file1" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" />
</DiskSection>
...
<VirtualHardwareSection>
...
<Item>
<rasd:AddressOnParent>0</rasd:AddressOnParent>
<rasd:ElementName>Hard disk 1</rasd:ElementName>
<rasd:HostResource>ovf:/disk/vmdisk1</rasd:HostResource>
<rasd:InstanceID>8</rasd:InstanceID>
<rasd:Parent>3</rasd:Parent>
<rasd:ResourceType>17</rasd:ResourceType>
</Item>
<Item>
<rasd:AddressOnParent>1</rasd:AddressOnParent>
<rasd:ElementName>Hard disk 1</rasd:ElementName>
<rasd:HostResource>ovf:/disk/vmdisk1</rasd:HostResource>
<rasd:InstanceID>9</rasd:InstanceID>
<rasd:Parent>3</rasd:Parent>
<rasd:ResourceType>17</rasd:ResourceType>
</Item>
...
</VirtualHardwareSection>
...
```
are valid OVF configurations, but will cause a failure when patching the VMI status. This is because both disks in both
scenarios here have identical names, `Hard disk 1`. Because `status.Disks` is defined as
```
// +optional
// +listType=map
// +listMapKey=name
// Disks describes the observed disk information for this image.
Disks []VirtualMachineImageDiskInfo `json:"disks,omitempty"`
```
the patch will fail due to these duplicate keys.
This PR updates the logic used to populate `status.Disks` such that when a duplicate name is encountered, it is
deduplicated by appending and incremented suffix, e.g. `_1`, `_2`, etc.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do, and why is it needed?
Which issue(s) is/are addressed by this PR? (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Are there any special notes for your reviewer:
Please add a release note if necessary: