[BUG] Cannot import previously exported ovf/ova image

[waldner]

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.

[github-actions[bot]]

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.

[waldner]

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.

[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

[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.

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle stale

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle stale

[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).

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle stale

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle-stale

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle-stale

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle-stale

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle-stale

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle-stale

[github-actions[bot]]

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.

[waldner]

/remove-lifecycle-stale