Currently ovftool ignores serial ports defined in an OVF, so cot deploy esxi (which uses ovftool) will create VMs with no serial ports even if the OVF defines them.

Until/unless VMware fixes this ovftool limitation, it would be really helpful for COT to implement some workaround (possibly using PowerCLI?) to force creation of the requested serial ports.

Issue Type: Potentially expected behavior, operator error, or defect

cot version: Common OVF Tool (COT), version 1.7.0+1.gada3935

OS: Ubuntu 14.04.3 LTS

vsphere version: vsphere 6.0

Summary:
Serial port is not added to guest if OVF tool does not define a serial port. If the OVF is edited to include a serial port, cot deploy will successfully deploy it. I am pointing cots at the vcenter server.

Steps to reproduce:

1. Use an OVA/OVF that doesn't include a serial port such as Tiny Core Linux https://communities.vmware.com/docs/DOC-21621). Note: Tiny Core doesn't seem to wire a tty to the serial port; I am using this OVA for testing because of its small size.

2. Using cots deploy in a manner such as

   (venv)jeffl@ubuntu:~/development/cot-testing$ cot -v deploy tiny-orig.ova esxi "10.10.120.150/DC1/host/host1" -u "jeffl" -p 'pass123' -d "datastore1" -N External-VM-Network=PG_RED -S telnet://:3010,server -n my_tiny
   INFO: COT.vm_factory         Loading 'tiny-orig.ova' as OVF
   VERBOSE: COT.vm_description     Temporary directory for VM created from tiny-orig.ova: /tmp/cotQ4ZozL
   VERBOSE: COT.ovf.ovf            Untarring tiny-orig.ova to working directory /tmp/cotQ4ZozL
   VERBOSE: COT.ovf.ovf            Extracted OVF descriptor from tiny-orig.ova to working dir /tmp/cotQ4ZozL
   VERBOSE: COT.ovf.ovf            Root namespace is http://schemas.dmtf.org/ovf/envelope/1
     INFO: COT.ovf.ovf            OVF version is 1.x
   VERBOSE: COT.ovf.ovf            Current configuration profiles are: []
   VERBOSE: COT.ovf.hardware       OVF contains 10 hardware Item elements describing 10 unique devices
     INFO: COT.ovf.ovf            OVF product class None --> platform GenericPlatform
   tiny-orig.ova configuration 'None' defines only 0 serial ports, but you have given connection information for 1 ports.
   Continue to create additional ports? [y] y
   INFO: COT.deploy_esxi        Deploying VM...
   VERBOSE: COT.helpers.helper     Checking for helper executable ovftool
   VERBOSE: COT.helpers.helper     ovftool is at /usr/bin/ovftool
     INFO: COT.helpers.helper     Calling 'ovftool --net:External-VM-Network=PG_RED --name=my_tiny --datastore=datastore1 tiny-orig.ova vi://jeffl:[email protected]/DC1/host/host1'...
   Opening OVA source: tiny-orig.ova
   The manifest validates
   Opening VI target: vi://[email protected]:443/DC1/host/host1
   Deploying to VI: vi://[email protected]:443/DC1/host/host1
   Transfer Completed
   Completed successfully
   INFO: COT.helpers.helper     ...done
   (venv)jeffl@ubuntu:~/development/cot-testing$
   

3. Examine vcenter to see if the newly created VM includes a serial port. In my case, it does not.

Workaround:
Add serial port to OVF via cot edit-hardware before running cot deploy.

Comments:
It appears as though fixup_serial_ports() isn't called in deploy_esxi.py:374 if serial_count[self.configuration] is zero. This makes me wonder if what I am seeing is expected behavior. I can't tell if the pyvomi code is modifying an existing serial port or adding a new one.

By the way, this is fantastic software and I appreciate your sharing it.

It would be nice to have 'remove-disk' and 'remove-file' commands to do the reverse of the existing 'add-disk' and 'add-file' commands.

Currently the CLI for COT is hard-coded to a terminal width of 79 characters when wrapping (or in some cases, failing to wrap) text output. It would be nice to have it respect the terminal width when available.

Similar to NIC names, it would be nice to be able to use a wildcard for network names:

cot edit-hardware foo.ova --nic-networks "mgmt0" "Ethernet1_{1}"

If we want to be crazy we could also support this for --mac-addresses-list and --serial-connectivity

• When creating new NICs in an OVF which has all NICs mapped to a single network, the new NICs should also map to this same network. (existing functionality, to be preserved)
• When creating new NICs in an OVF which has each NIC mapped to a different network, COT should create new networks to map the new NICs to, rather than mapping the new NICs to the same network as the last existing NIC (new functionality)
  • If the network names map obviously to the NIC name (GigabitEthernet3 <--> GigabitEthernet3) then the new network names should be similarly derived
  • If the network names are sequentially numbered in some fashion (Net1, Net2, Net3) then the new network names should be similarly derived.

I'm trying to generate a VMware Virtual Appliances as part of a build system. When the Appliance is in the user's hands and being deployed (in a vSphere Environment) I want the user to be able to set networking and root password. I see that you can set properties and I've tried this, but they are not exposed when the Appliance is deployed. Comparing what COT generates and what VMware generates from VMware Studio, I noticed the code generated is not the same:

VMware Studio

COT

<ovf:Property ovf:key="oe.IP" ovf:type="string" ovf:value="0.0.0.0" />

Is there a way in COT to generate lines with the userConfigurable attribute and no value (assuming that's the problem)?

Consider adding any of the following linters:

• pep8-naming (class/function/variable name style)
• mccabe (code complexity)
• pylint

The slowest part of COT is the actual file I/O [citation needed], especially when untarring and retarring an OVA file is required. This makes multi-stage operations like the following somewhat slow since the file is re-written and re-read repeatedly:

cot edit-hardware foo.ova --cpus 4
cot edit-properties foo.ova ...
cot inject-config config.txt foo.ova
cot info foo.ova

While COT is explicitly designed around separation of actions (so that the params defined for "edit-hardware" do not conflict with the params for "add-disk", etc.), it would be nice to provide for some mechanism of batching operations together with only a single "read" at the beginning and a single "write" at the end.

cot edit-hardware works fine when editing existing hardware types, but when attempting to create hardware of a type not previously present in an OVF, it errors out:

$ ./bin/cot edit-hardware COT/tests/minimal.ovf --cpus 1 -o test.ovf
Traceback (most recent call last):
  File "./bin/cot", line 64, in <module>
    COT.cli.main()
  File "./COT/cli.py", line 229, in main
    args.func(args)
  File "./COT/edit_hardware.py", line 77, in edit_hardware
    vm.set_cpu_count(args.cpus, args.profiles)
  File "./COT/ovf.py", line 734, in set_cpu_count
    profile_list)
  File "./COT/ovf.py", line 2261, in set_value_for_all_items
    .format(resource_type))
LookupError: No items of type cpu found!

cot install-helpers reports "Not sure how to install" for fatdisk and vmdktool on Linux if cot was built/installed under Python 3.x. This is because "sys.platform" for LInux changed from 'linux2' in 2.x and 3.2 to 'linux' in 3.3+

OVFs can specify multiple subtypes for a device (allowing the target host to choose which subtype it prefers/supports):

        <rasd:ResourceSubType>virtio E1000</rasd:ResourceSubType>

but cot edit-hardware doesn't presently provide this option:

$ cot edit-hardware foo.ova --nic-type e1000 virtio
cot: error: unrecognized arguments: virtio
$ cot edit-hardware foo.ova --nic-type "e1000 virtio"
cot edit-hardware: error: argument --nic-type: invalid choice: 'e1000 virtio' (choose from 'e1000', 'virtio', 'vmxnet3')
$ cot edit-hardware foo.ova --nic-type "e1000, virtio"
cot edit-hardware: error: argument --nic-type: invalid choice: 'e1000, virtio' (choose from 'e1000', 'virtio', 'vmxnet3')
$ cot edit-hardware foo.ova --nic-type e1000 --nic-type virtio
# accepted as valid but the resulting OVA only has virtio subtype

Currently cot deploy has two major limitations in its handling of ovftool:

1. It caches all output from ovftool while the tool runs and only dumps the output to screen after ovftool exits. Since ovftool can take a while to run, it's not clear to the user what is happening during this time.
2. In some cases ovftool may prompt the user for input mid-run, such as:

The manifest validates

Accept SSL fingerprint (71:80:F5:C1:F1:41:41:38:11:90:2C:1D:F4:11:75:19:35:AF:94:21) for host 192.1.1.4 as target type.

Fingerprint will be added to the known host file

Write 'yes' or 'no'

Because of item 1) above this prompt will not be displayed to the user and so COT will hang indefinitely.

Solution:

1. COT needs to provide live output from ovftool as it runs
2. COT needs to pass prompts for user input from ovftool through to the user, or automatically handle the prompts as appropriate.

COT doesn't dereference file links when building the OVA, but it should. This is causing errors downstream if the link is no longer applicable:

> tar tvf /tmp/foo.ova 
-rw-r--r-- glmatthe/eng  28897 2015-09-02 14:55:09 foo.ovf
-rw-r--r-- glmatthe/eng    136 2015-09-02 14:55:09 foo.mf
lrwxrwxrwx useruser/eng      0 2015-09-01 11:44:37 foo.vmdk -> /auto/x/y/z/q/foo.vmdk

cot inject-config csr1000v-universalk9.BLD_V155_1_S_XE314_THROTTLE_LATEST_20141125_130028-std.ova -c config -o csr1.ova
Traceback (most recent call last):
  File "/usr/local/bin/cot", line 9, in <module>
    load_entry_point('common-ovf-tool==1.1.5-2-g9c1c19c', 'console_scripts', 'cot')()
  File "build/bdist.linux-x86_64/egg/COT/cli.py", line 234, in main
  File "build/bdist.linux-x86_64/egg/COT/inject_config.py", line 69, in inject_config
LookupError: Could not find an empty cdrom drive to inject the config into

More properly, cot inject-config should overwrite any existing config file (or optionally let the user request to append instead of overwriting).

$ cot edit-hardware COT/tests/minimal.ovf -o temp.ovf --nics 1 --nic-type e1000
    INFO: Loading 'COT/tests/minimal.ovf' as OVF
    INFO: OVF version is 1.x
    INFO: OVF product class None --> platform GenericPlatform
 WARNING: No items of type ethernet found. Nothing to do.

Unexpected warning here!

    INFO: Updating NIC count in OVF under profile None to 1
 WARNING: No existing items of type ethernet found. Will create new ethernet from scratch.
    INFO: Added new ethernet under [None], instance is 1
    INFO: Writing out to file temp.ovf
$ cat temp.ovf
<?xml version='1.0' encoding='utf-8'?>
<ovf:Envelope xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">
  <ovf:References />
  <ovf:VirtualSystem ovf:id="x">
    <ovf:Info />
    <ovf:VirtualHardwareSection>
      <ovf:Info />
      <ovf:Item>
        <rasd:ElementName>Ethernet1</rasd:ElementName>
        <rasd:InstanceID>1</rasd:InstanceID>

No ResourceSubType here!

        <rasd:ResourceType>10</rasd:ResourceType>
      </ovf:Item>
    </ovf:VirtualHardwareSection>
  </ovf:VirtualSystem>
</ovf:Envelope>

Cisco has several potential use cases where additional arbitrary files need to be included in the config ISO, such as application configuration. Rather than making COT aware of specific files (like the current primary/secondary config text files) it would be nice to have an '--extra-files' option that can specify arbitrary files or directories to add.

Python standard seems to be to have three 'levels' of verbosity:

--quiet: WARN/ERROR
(default): INFO/WARN/ERROR
--verbose: DEBUG/INFO/WARN/ERROR

COT's current behavior:
(default): ERROR
-v: WARN/ERROR
-vv: INFO/WARN/ERROR
-vvv: DEBUG/INFO/WARN/ERROR

We should follow the standard instead.

Additionally, the levels are not always used consistently - in particular the DEBUG messages are extremely verbose while the INFO messages are often lacking.

The Cisco ASAv OVA uses several OVF property features not currently supported in COT, including:

• Grouping of Property elements under Category sections
• ValueMap property qualifier
• VMware property qualifiers such as vmw:qualifiers="IP"
• Properties whose value differs by selected configuration
• Properties with ovf:userConfigurable="false"

It would be terrific if COT (and particularly cot edit-properties) could support these features.

This may already be covered in another enhancement. It would be nice if COT could support the various vApp properties for enabling/disabling certain properties. Eg. If I add custom properties using COT, I still need to manually switch on the ability for the VM to leverage the properties via VMWare Tools, or an ISO mount.

In combination with #22, it would also be useful to provide some sort of interactive mode to allow step-by-step construction of complex CLI, for example something like:

$ cot
cot> package foo.ova
cot> edit-hardware
cot-edit-hardware> cpus 4
cot-edit-hardware> memory 4GB
cot-edit-hardware> done
Command: 'cot edit-hardware foo.ova --cpus 4 --memory 4GB'
cot> write bar.ova
Command: 'cot edit-hardware foo.ova --cpus 4 --memory 4GB --output bar.ova'
Created bar.ova (new file)
cot> exit
$

In pyvmomi 6.0.0.2016.4, as a side effect of vmware/pyvmomi#341, connection failures now raise a socket.error instead of a requests.exceptions.ConnectionError, causing a test failure:

======================================================================
ERROR: test_serial_fixup_connection_error (COT.tests.test_deploy_esxi.TestCOTDeployESXi)
Call fixup_serial_ports() to connect to an invalid host.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "COT/tests/test_deploy_esxi.py", line 207, in test_serial_fixup_connection_error
    self.instance.fixup_serial_ports(2)
  File "COT/deploy_esxi.py", line 355, in fixup_serial_ports
    self.username, self.password) as conn:
  File "COT/deploy_esxi.py", line 70, in __enter__
    return super(SmarterConnection, self).__enter__()
  File ".tox/py27/lib/python2.7/site-packages/pyVim/connect.py", line 525, in __enter__
    self.si = SmartConnect(*self.args, **self.kwargs)
  File ".tox/py27/lib/python2.7/site-packages/pyVim/connect.py", line 786, in SmartConnect
    sslContext)
  File ".tox/py27/lib/python2.7/site-packages/pyVim/connect.py", line 671, in __FindSupportedVersion
    sslContext)
  File ".tox/py27/lib/python2.7/site-packages/pyVim/connect.py", line 591, in __GetServiceVersionDescription
    path + "/vimServiceVersions.xml", sslContext)
  File ".tox/py27/lib/python2.7/site-packages/pyVim/connect.py", line 557, in __GetElementTree
    conn.request("GET", path)
  File "/lib/python2.7/httplib.py", line 1057, in request
    self._send_request(method, url, body, headers)
  File "/lib/python2.7/httplib.py", line 1097, in _send_request
    self.endheaders(body)
  File "/lib/python2.7/httplib.py", line 1053, in endheaders
    self._send_output(message_body)
  File "/lib/python2.7/httplib.py", line 897, in _send_output
    self.send(msg)
  File "/lib/python2.7/httplib.py", line 859, in send
    self.connect()
  File "/lib/python2.7/httplib.py", line 1270, in connect
    HTTPConnection.connect(self)
  File "/lib/python2.7/httplib.py", line 836, in connect
    self.timeout, self.source_address)
  File "/lib/python2.7/socket.py", line 575, in create_connection
    raise err
error: [Errno 61] Connection refused

thank you @glennmatthews

When deploying an OVF that has no defined configuration profiles, COT still prompts the user to select a profile but doesn't accept any input as valid:

Configuration Profiles:           CPUs    Memory   NICs Serials  Disks/Capacity
                                  ---- --------- ------ ------- ---------------
  None (default)                     2   1.50 GB      4       0   1 /   1.00 GB
Choose a Configuration:  [None] 
()
Entry does not match a profile. Please try again.
Configuration Profiles:           CPUs    Memory   NICs Serials  Disks/Capacity
                                  ---- --------- ------ ------- ---------------
  None (default)                     2   1.50 GB      4       0   1 /   1.00 GB
Choose a Configuration:  [None] None
()
Entry does not match a profile. Please try again.

@kakeim had determined that pyVmomi (https://github.com/vmware/pyvmomi) might be a suitable Python alternative to using ovftool, but had hit some bugs in that project. Further investigation is needed.

Per discussion with @glennmatthews opening this to track changes around the following

1. Today with an existing OVF (not OVA) COT will copy the disk files to a temp directory even if it is for an edit-product operation, and the input/output directories are the same. There are cases when this is undesirable because the potential is there for the edit-product operation to be lengthy. It may also sometimes be undesirable to copy vmdk's to a tmp dir when converting OVF to OVA.
2. It appears that COT will convert an existing stream optimized vmdk to raw, then back again. @glennmatthews replied that this was not the case and/or not intended. Need to just ensure this is happening, and correct if it is not.

In v1.2.2 the interactive edit-properties mode is no longer entered if no properties are given on the command line:

> cot edit-properties -o foo.ovf COT/tests/input.ovf 
    INFO: Loading 'COT/tests/input.ovf' as OVF
    INFO: OVF version is 1.x
    INFO: OVF product class None --> platform GenericPlatform
Overwrite existing file foo.ovf? [y] y
    INFO: Writing out to file foo.ovf
    INFO: Copying input.vmdk to /Users/glmatthe/Documents/OVF_Tools/cot-public/cot
    INFO: Copying input.iso to /Users/glmatthe/Documents/OVF_Tools/cot-public/cot

In v1.2.1 the functionality still works:

> cot edit-properties -o foo.ovf COT/tests/input.ovf 
    INFO: Loading 'COT/tests/input.ovf' as OVF
    INFO: OVF version is 1.x
    INFO: OVF product class None --> platform GenericPlatform
Overwrite existing file foo.ovf? [y] y

Please choose a property to edit:
   1) "Login Username"                         (login-username)
   2) "Login Password"                         (login-password)
   3) "Management IPv4 Address/Mask"           (mgmt-ipv4-addr)
   4) "Management IPv4 Default Gateway"        (mgmt-ipv4-gateway)
   5) "Router Name"                            (hostname)
   6) "Enable SSH Login"                       (enable-ssh-server)
   7) "Enable HTTP Server"                     (enable-http-server)
   8) "Enable HTTPS Server"                    (enable-https-server)
   9) "Enable Password"                        (privilege-password)
  10) "Domain Name"                            (domain-name)

For thoroughness, cot_unittest should use virtualenv to allow the test to be run under all installed/supported Python versions.

Currently COT errors out if you use 'cot add-disk' to try to overwrite a CD-ROM drive with a hard disk drive or vice versa. Instead, COT should probably warn the user and prompt for confirmation instead of unconditionally failing.

COT should provide proper man pages for each subcommand (cot-info, cot-edit-hardware, etc.).

When setting the subtype of a SCSI or IDE controller (OVF.set_scsi_subtype(), OVF.set_ide_subtype()), it might be nice to validate whether the given controller subtype is known to be supported by the platform represented by this OVF.

GLMATTHE-M-20W1:cot glmatthe$ bin/cot edit-hardware COT/tests/input.ovf -o network.ovf -N "new network"
Network new network is not currently defined. Create it? [y] y
Please enter a description for this network [new network] 
GLMATTHE-M-20W1:cot glmatthe$ bin/cot info network.ovf 
<snip>
Networks:
  VM Network
  new network

NICs and Associated Networks:
  GigabitEthernet1               : new network
  GigabitEthernet2               : new network
  GigabitEthernet3               : new network
<snip>

Network "VM Network" no longer has any NICs associated with it so COT may as well delete this network entry from the OVF.

We should be able to enhance the speed of our Travis-CI builds by migrating to the newer infrastructure: http://docs.travis-ci.com/user/migrating-from-legacy/

In order to accomplish this migration, instead of using 'cot install-helpers' to install the helper tools (which requires 'sudo', which is only available in the legacy infra), we need replicate the helper installtion into our .travis.yml.

Specifically we need to use addons.apt.packages in our travis.yml (http://docs.travis-ci.com/user/migrating-from-legacy/#Adding-APT-Packages) to install all of the packages that are available through apt-get, then build and locally install any that are not.

apt-get packages:

• make
• gcc
• genisoimage (travis-ci/apt-package-safelist#593)
• qemu-utils (travis-ci/apt-package-safelist#553)
• zlib1g-dev

packages to build from source:

• fatdisk
• vmdktool

Linux installation documentation is still a bit vague.

# cot -f -v edit-hardware input.ova -o csr1000v.ova --nics 4 --nic-type vmxnet3
WARNING:COT.ovf:Item has AddressOnParent but no Parent - AddressOnParent is meaningless and will not be updated for uniqueness.
WARNING:COT.ovf:Attribute '{http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData}Address' not found under ''
WARNING:COT.ovf:Attribute '{http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData}Parent' not found under ''

The latter two messages are meaningless warnings and shouldn't be seen here, but the first message indicates the problem - we are reusing the AddressOnParent value from the existing NIC, and ESXi doesn't like this.

COT handles ASCII just fine but can get confused by Unicode strings, especially in the output from various helper tools. We should handle Unicode properly but this is of course tricky since we want to be compatible with both Python 2.7 and 3.x, which differ substantially in their unicode handling.

When running cot edit-hardware under Python 3, the following error message is reported, although the file is edited correctly:

ERROR:cot:No namespace prefix on _attrib_{http://schemas.dmtf.org/ovf/envelope/1}required??

Adding -v shows some context:

ERROR:cot:No namespace prefix on _attrib_{http://schemas.dmtf.org/ovf/envelope/1}required??
WARNING:cot:Profile 1CPU-3GB already exists under OVFItem:  ElementName
    Serial 2             : {'<default>'}
  ResourceType
    21                   : {'<default>'}
  _attrib_{http://schemas.dmtf.org/ovf/envelope/1}required
    false                : {'<default>'}
  Description
    Auxiliary Port       : {'<default>'}
  InstanceID
    9                    : {'<default>'}
  AutomaticAllocation
    true                 : {'<default>'}
!

nice to have.

I am looking for something similar to libvirt's "virsh destroy <vm_name>". The destroy function should do the proper cleanup. For example, if the "deploy" operation added a disk to data storage, then "destroy" should remove the disk from data storage.

DSP 0243, 1.1.0, lines 1190-1206:

Configurations can further be used to control default values for properties. For Property elements inside a ProductSection, the following additional semantic is defined:

• It is possible to use alternative default property values for different configurations in a DeploymentOptionSection. In addition to a Label and Description element, each Property element may optionally contain Value elements. The Value element shall have an ovf:value attribute specifying the alternative default and an ovf:configuration attribute specifying the configuration in which this new default value should be used. Multiple Value elements shall not refer to the same configuration.

EXAMPLE 2: The following shows an example ProductSection:

    <ProductSection>
      <Property ovf:key="app.log" ovf:type="string" ovf:value="low"
ovf:userConfigurable="true">
        <Label>Loglevel</Label>
        <Description>Loglevel for the service</Description>
        <Value ovf:value="none" ovf:configuration="minimal">
      </Property>
    </ProductSection>

COT does not presently support this.

The current documentation is vague about what versions of Python 3.x COT actually supports.

Does COT actually run under Python 3.0? (Probably not, although our 2.6 support may get us closer)
Does COT run under Python 3.1?
Etc.

Currently cot deploy prompts the user to select a configuration profile as follows:

Configuration Profiles:           CPUs    Memory   NICs Serials  Disks/Capacity
                                  ---- --------- ------ ------- ---------------
  4CPU-4GB-3NIC (default)            4   4.00 GB      3       2   1 /   1.00 GB
    Label:          "4 vCPUs, 4 GB RAM, 3 NICs"
    Description:    "Default hardware profile - 4 vCPUs, 4 GB RAM, 3
                     NICs"
  2CPU-2GB-1NIC                      2   2.00 GB      1       2   1 /   1.00 GB
    Label:          "2 vCPUs, 2 GB RAM, 1 NIC"
    Description:    "Minimal hardware profile - 2 vCPUs, 2 GB RAM, 1
                     NIC"
Choose a Configuration:  [4CPU-4GB-3NIC] 

Having to type the full name of the selected profile can be a bit awkward. It would be nice to present the configurations as a numbered list, such as:

Configuration Profiles:           CPUs    Memory   NICs Serials  Disks/Capacity
                                  ---- --------- ------ ------- ---------------
1)  4CPU-4GB-3NIC (default)          4   4.00 GB      3       2   1 /   1.00 GB
    Label:          "4 vCPUs, 4 GB RAM, 3 NICs"
    Description:    "Default hardware profile - 4 vCPUs, 4 GB RAM, 3
                     NICs"
2)  2CPU-2GB-1NIC                    2   2.00 GB      1       2   1 /   1.00 GB
    Label:          "2 vCPUs, 2 GB RAM, 1 NIC"
    Description:    "Minimal hardware profile - 2 vCPUs, 2 GB RAM, 1
                     NIC"
Enter configuration name or number:  [1] 

If cot deploy fails due to an ovftool failure, the error message from ovftool is not always very useful. The end user doesn't necessarily realize that this is ovftool and not COT being unhelpful, so it makes COT look bad. Would be nice to gather additional information in case of an ovftool failure.

Example: A user encountered the following error:

$ cot deploy -s '172.25.1.4/iSVC-DC/host/172.25.1.101' -P -u [email protected] -p XErg_lab123 -n "CSR205" -c 1CPU-4GB  -N "GigabitEthernet1=Management_172_25"  -N "GigabitEthernet2=Network1" -N "GigabitEthernet3=Network1" -N "GigabitEthernet4=Network1" -N "GigabitEthernet5=Network1" -N "GigabitEthernet6=Network1"  esxi "csr1000v-universalk9.03.15.00.S.155-2.S-std.ova" -ds=datastore1
Deploying VM...
Opening OVA source: csr1000v-universalk9.03.15.00.S.155-2.S-std.ova
Opening VI target: vi://administrator%[email protected]:443/iSVC-DC/host/172.25.1.101
Error:
 - The operation is not allowed in the current state of the host.
Completed with errors
Helper program 'ovftool' exited with error 1

The actual issue was that the datastore for this host needed to be "datastore1 (3)"not "datastore1" but this is not at all obvious from the ovftool error.

COT doesn't work yet under Windows, mostly due to a lack of appropriate helper tools. Current status:

• Python 2.7 can be downloaded from https://www.python.org/downloads/windows/
• Setuptools can be downloaded from https://pypi.python.org/pypi/setuptools
• An unofficial QEMU build for Windows (for qemu-img)can be downloaded from http://wiki.qemu.org/Links#Unofficial_QEMU_binaries.
• mkisofs can be installed under Cygwin but that's suboptimal. Is there an appropriate free Windows tool (with CLI capability) that we can use when running COT on Windows?
• No Windows binary is available for fatdisk, and not sure if it will compile on Windows. Possibly use OSFMount under Windows?
• No Windows binary is available for vmdktool, and not sure if it will compile on Windows.

Would be nice to provide various synonyms for the built-in submodules to make the CLI more intuitive/discoverable. Some possibilities:

cot info --> cot describe
cot edit-hardware --> cot hw, cot hw-edit
cot inject-config --> cot set-bootstrap

Etc.

It would be nice for COT to have a GUI, possibly as a web tool, for users who are less comfortable with the CLI.