COT considers OVF with different CPU InstanceID across different profiles as invalid about cot HOT 6 OPEN

Hm, this is not a use case I've previously encountered. I can look into it (could you provide an OVF file?) but I'm curious, is there a reason you're using a different InstanceID for different configurations, instead of using the same InstanceID for each config-specific CPU item?

from cot.

Because according to the OVF spec, section 8.3:

InstanceID A unique instance ID of the element within the section.

Although, looking back at the VCSA .ovf, that does re-use the InstanceID too. I don't see anything in either the VirtualHardwareSection or DeploymentOptionSection parts of the docs that actually says you can though :-)

I've attached an example OVF also.

tmp.ovf.txt

from cot.

Thanks!

You want section 9.8 (DeploymentOptionSection):

• Each Item has an optional ovf:configuration attribute, containing a list of configurations separated by a single space character. If not specified, the item shall be selected for any configuration. If specified, the item shall be selected only if the chosen configuration ID is in the list. A configuration attribute shall not contain an ID that is not specified in the DeploymentOptionSection.
• Within a single VirtualHardwareSection or ResourceAllocationSection, multiple Item elements are allowed to refer to the same InstanceID. A single combined Item for the given InstanceID shall be constructed by picking up the child elements of each Item element, with child elements of a former Item element in the OVF descriptor not being picked up if there is a like-named child element in a latter Item element. Any attributes specified on child elements of Item elements that are not picked up that way, are not part of the combined Item element.

That said, your approach is also valid (if less common in my own experience), so I will keep looking into this issue 😄

Thanks!

from cot.

Aaah. OK. I'll switch over then. There's no need to make life harder :-)

If I could get cot to add disks with no images, I think I could ditch my own work altogether, then.

from cot.

"Disks with no images" - as in Disk elements with no associated fileRef? COT recognizes these as valid but I don't currently have support for creating them. Wouldn't be hard to add though I think. If that's not what you're looking for, please clarify.

from cot.

yes - A type 17 <Item> and a <Disk> with a capacity but no fileRef or populatedSize, so it shows up as an unformatted block device in the final VM. I think a few things use this kind of arrangement for log or database partitions where the sizing is different depending on the deployment option chosen. In my use case, the extra disks only exist in some of the configurations.

from cot.