New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import.spec should not assume Deployment param always exists for OVA/OVFs #487

Closed
lamw opened this Issue Apr 2, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@lamw
Copy link

lamw commented Apr 2, 2016

It looks like the import.spec always assumes there's a Deployment Type param defined which is not always the case. This is something that needs to be inspected by parsing the OVF definition to see what options are available.

The issue is that if you simply generate the spec and then modify just the OVF params and don't realize this, you'll get an fault when running import.ova command:

└─[0] <> govc import.ova -options=vesxi3.json /Volumes/Storage/Images/nested_esxi_appliance_v6.0u2.ova
govc: ServerFaultCode: A specified parameter was not correct: cisp.deploymentOption

Here's output of the import.spec:

└─[1] <> govc import.spec /Volumes/Storage/Images/nested_esxi_appliance_v6.0u2.ova | python -m json.tool
{
    "Deployment": "small",
    "DiskProvisioning": "thin",
    "IPAllocationPolicy": "dhcpPolicy",
    "IPProtocol": "IPv4",
    "InjectOvfEnv": false,
    "Name": null,
    "PowerOn": false,
    "PropertyMapping": [
        {
            "Key": "guestinfo.hostname",
            "Value": "esxi-1.primp-industries.com"
        },
        {
            "Key": "guestinfo.ipaddress",
            "Value": "192.168.1.190"
        },
        {
            "Key": "guestinfo.netmask",
            "Value": "255.255.255.0"
        },
        {
            "Key": "guestinfo.gateway",
            "Value": "192.168.1.1"
        },
        {
            "Key": "guestinfo.dns",
            "Value": "192.168.1.1"
        },
        {
            "Key": "guestinfo.domain",
            "Value": "primp-industries.com"
        },
        {
            "Key": "guestinfo.ntp",
            "Value": "192.168.1.1"
        },
        {
            "Key": "guestinfo.syslog",
            "Value": "192.168.1.150"
        },
        {
            "Key": "guestinfo.password",
            "Value": ""
        },
        {
            "Key": "guestinfo.ssh",
            "Value": "true"
        },
        {
            "Key": "guestinfo.createvmfs",
            "Value": "false"
        }
    ],
    "WaitForIP": false
}

Here's the OVA that I was using: https://bintray.com/artifact/download/photon-controller/esxi-appliances/nested_esxi_appliance_v6.0u2.ova

@lamw

This comment has been minimized.

Copy link
Author

lamw commented Apr 2, 2016

Forgot to add that IPAllocationPolicy & IPProtocol may also not be applicable and should be left out of the spec if it's not in the OVA/OVF

@cblomart

This comment has been minimized.

Copy link
Contributor

cblomart commented Apr 5, 2016

Ok looking at the ovf file of vcsa i see an IpAssignmentSection (xml node) in the declared vmw namespace pointing to http://www.vmware.com/schema/ovf. But on the vmware website the url (hoping for a xsd)... but 404 :-(

I would have like to handle extra parameters properly before looking into adding networkmapping:
Adding them to the envelope definition (govomi/ovf/envelope.go).

Currently govc simply adds the mentionned options per default (apparently these comes more from vapp implementation). It doesn't even check if the ovf provides any insight.

PS: also an occasion to check how golang xml unmarshaling handles namespaces.

@dougm dougm added the area/govc label Apr 29, 2016

@srbry

This comment has been minimized.

Copy link

srbry commented Aug 18, 2016

+1, had this issue today, used import.spec to generate an options.json but it was error when deploying my ova with import.ova until I deleted the Deployment key.

@rahulkj

This comment has been minimized.

Copy link

rahulkj commented Dec 9, 2016

Ran into the same issue yesterday and turned out to be the Deployment key. Had to remove it to get the deployment going

@srinarayanant

This comment has been minimized.

Copy link

srinarayanant commented Apr 16, 2017

VMware-NSX-Manager-6.2.5-4818372.ova

@srinarayanant

This comment has been minimized.

Copy link

srinarayanant commented Apr 16, 2017

seems the bug is still there, happens for VMware-NSX-Manager-6.2.5-4818372.ova too

anfernee pushed a commit to anfernee/govmomi that referenced this issue Oct 25, 2017

Yongkun Anfernee Gui
import.spec not to assign deploymentOption
We used to forcefully assign deploymentOption among [small, medium, large]
when we call import.spec on an ova/ovf that doesn't include
deploymentOption. This could generate an option file that cannot be
accepted by import.ova or import.ovf. After this change we only assign
deploymentOption when it's included in ova/ovf file.

Fixes vmware#487

anfernee pushed a commit to anfernee/govmomi that referenced this issue Oct 25, 2017

Yongkun Anfernee Gui
import.spec not to assign deploymentOption
We used to forcefully assign deploymentOption among [small, medium, large]
when we call import.spec on an ova/ovf that doesn't include
deploymentOption. This could generate an option file that cannot be
accepted by import.ova or import.ovf. After this change we only assign
deploymentOption when it's included in ova/ovf file.

Fixes vmware#487
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment