govmomi Unable to import previously exported ovf/ova image

Describe the bug

Cannot import previously exported ovf/ova image.

To Reproduce

Steps to reproduce the behavior:

1. govc export.ovf -vm='/dc/vm/vm1' ovfdir
2. # delete vm1 from vcenter 
3. govc import.ovf  -ds='vsanDatastore' -folder='TESTFOLDER' -name=IMPORTEDVM ovfdir/vm1/vm1.ovf 
[23-11-21 20:01:37] Warning: Line 105: Invalid value 'MGMT' for element 'Connection'.
govc: A specified parameter was not correct: ovfSection.info.key

4. tar -cf vm1.ova -C ovfdir .
5. govc import.ova -dc='dc' -ds='vsanDatastore' -folder='TESTFOLDER' -name=IMPORTEDVM vm1.ova
[23-11-21 20:03:11] Warning: Line 105: Invalid value 'MGMT' for element 'Connection'.
govc: A specified parameter was not correct: ovfSection.info.key

Expected behavior The VM should have been imported.

Affected version

$ govc version
govc 0.26.1

MGMT is the name of the network the original machine was attached to, and it does exist in vmware at the time the import is attempted. The same OVA file works if I import it using the vsphere web client, but my goal is to automate and script the import.

It's possible that I'm doing something wrong.

Nov 23 '21 19:11 waldner

Howdy 🖐 waldner ! Thank you for your interest in this project. We value your feedback and will respond soon.

If you want to contribute to this project, please make yourself familiar with the CONTRIBUTION guidelines.

Nov 23 '21 19:11 github-actions[bot]

More information: even an OVA file created with powerCli fails with the exact same error, so doesn't seem related to whether the OVA has been created with govc or not.

$ govc import.spec TESTVM.ova > specs.json
$ # edit specs.json to adapt config
$ govc import.ova  -dc='dc' -ds='vsanDatastore' -folder='TESTFOLDER' -name=TESTVM -options=specs.json TESTVM.ova
govc: A specified parameter was not correct: ovfSection.info.key

TESTVM.ova was obtained by running Export-VApp -Destination 'C:\outdir' -Format OVA -VM "TESTVM" then moved to the govc machine. Again, it works with the vsphere web client.

Nov 24 '21 22:11 waldner

More info: the <ImportVApp> SOAP call performed by govc includes the following ovfSections:

         <vAppConfig XMLSchema-instance:type="VmConfigSpec">
            <ovfSection>
              <operation>add</operation>
              <info>
                <namespace>http://www.vmware.com/schema/ovf</namespace>
                <type>StorageGroupSection</type>
                <atEnvelopeLevel>true</atEnvelopeLevel>
                <contents>&lt;vmw:StorageGroupSection ovf:required="false" vmw:id="group1" vmw:name="vSAN Default Storage Policy" xmlns="http://schemas.dmtf.org/ovf/envelope/1" xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
    &lt;Info&gt;Storage policy for group of disks&lt;/Info&gt;
    &lt;vmw:Description&gt;vSAN Default Storage Policy storagepolicy group&lt;/vmw:Description&gt;
  &lt;/vmw:StorageGroupSection&gt;</contents>
              </info>
            </ovfSection>
            <ovfSection>
              <operation>add</operation>
              <info>
                <key>1</key>
                <namespace>http://www.vmware.com/schema/ovf</namespace>
                <type>StorageSection</type>
                <atEnvelopeLevel>false</atEnvelopeLevel>
                <contents>&lt;vmw:StorageSection ovf:required="false" vmw:group="group1" xmlns="http://schemas.dmtf.org/ovf/envelope/1" xmlns:cim="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
      &lt;Info&gt;Storage policy group reference&lt;/Info&gt;
    &lt;/vmw:StorageSection&gt;</contents>
              </info>
            </ovfSection>
            <installBootRequired>false</installBootRequired>
          </vAppConfig>

One has the <key> element, the other doesn't, but according to https://vdc-download.vmware.com/vmwb-repository/dcr-public/bf660c0a-f060-46e8-a94d-4b5e6ffc77ad/208bc706-e281-49b6-a0ce-b402ec19ef82/SDK/vsphere-ws/docs/ReferenceGuide/vim.vApp.OvfSectionInfo.html it should not be mandatory.

On the vcenter server, the error looks like this (not very helpful):

Description:
11/25/2021, 8:11:49 PM Failed to create virtual machine TESTVM on 10.1.0.2

Nov 25 '21 17:11 waldner

Another update: the import works flawlessly with ansible (using the https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_deploy_ovf_module.html#ansible-collections-community-vmware-vmware-deploy-ovf-module) which AFAICT uses pyvmomi, so I still maintain govc is not working properly.

Dec 09 '21 14:12 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Mar 10 '22 01:03 github-actions[bot]

/remove-lifecycle stale

Mar 10 '22 09:03 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Jun 09 '22 01:06 github-actions[bot]

/remove-lifecycle stale

Jun 11 '22 22:06 waldner

Here's what seems to be happening:

running with -verbose=true, I see that the keys in the info sections are correctly generated, with values 0 and 1:

            VAppConfig: &types.VmConfigSpec{
                OvfSection:   []types.VAppOvfSectionSpec{
                    {
                        ArrayUpdateSpec: types.ArrayUpdateSpec{
                            Operation: "add",
                        },
                        Info: &types.VAppOvfSectionInfo{
                            Key:             0,
                            Namespace:       "http://www.vmware.com/schema/ovf",
                            Type:            "StorageGroupSection",
                            AtEnvelopeLevel: types.NewBool(true),
                            Contents:        "...",
                        },
                    },
                    {
                        ArrayUpdateSpec: types.ArrayUpdateSpec{
                            Operation: "add",
                        },
                        Info: &types.VAppOvfSectionInfo{
                            Key:             1,
                            Namespace:       "http://www.vmware.com/schema/ovf",
                            Type:            "StorageSection",
                            AtEnvelopeLevel: types.NewBool(false),
                            Contents:        "...",
                        },
                    },

But then the first key gets lost when converting to XML, due to the omitempty tag in the VAppOvfSectionInfo struct (vim25/types/types.go, line 50770):

Key             int32  `xml:"key,omitempty"`

I'm not familiar with the govmomi codebase so I'm not even attempting to provide a patch, but a quick test done by removing the omitempty tag and rebuilding govc makes the OVA import work.

Hopefully this provides enough information to the developers to fix the problem. I still maintain that this is definitely a bug. Also, let me emphasize that this affects all products using govmomi (in our use case, for example, the vsphere terraform provider is failing to import the OVA due to the bug).

Aug 30 '22 18:08 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Nov 30 '22 01:11 github-actions[bot]

/remove-lifecycle stale

Nov 30 '22 09:11 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Mar 02 '23 01:03 github-actions[bot]

/remove-lifecycle-stale

Mar 02 '23 10:03 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Jun 02 '23 01:06 github-actions[bot]

/remove-lifecycle-stale

Jun 02 '23 07:06 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Sep 02 '23 01:09 github-actions[bot]

/remove-lifecycle-stale

Sep 02 '23 10:09 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Dec 03 '23 01:12 github-actions[bot]

/remove-lifecycle-stale

Dec 03 '23 11:12 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Mar 04 '24 01:03 github-actions[bot]

/remove-lifecycle-stale

Mar 04 '24 09:03 waldner

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Mark as fresh by adding the comment /remove-lifecycle stale.

Aug 31 '24 01:08 github-actions[bot]

/remove-lifecycle-stale

Aug 31 '24 09:08 waldner