Inconsistent Behavior using REST API to PUT Networ...

derevan007 · ‎10-16-2013

When using the vCloud Director REST API to customize CentOS to add a 2nd NIC and identifying it as primary, the FQDN (hostname –f) ends up being incorrect (about one out of 10 times). This is due to the way it is updating the /etc/hosts file. In the case where it is wrong, the primary NIC comes after the secondary NIC in the /etc/hosts file. In cases where it works, the new primary NIC is inserted before the secondary NIC. What's odd is that the vCloud API behavior is not consistent when run against similar servers (that are all configured the same way via the API).

Below is a comparison of API Request/Responses for one case that worked and one that did not. Note that NIC-1 comes before NIC-0 in both requests, but the response, shows them in a different order than the request, and subsequently in /etc/hosts. The 2 networks used in both requests are the same. The servers are pretty much identical in every way (originated from same template, same sequence of customization, etc).

Below is an example of the API request when it works, where the order of the NICs in the request matches with the order in the result, and hence results in the correct /etc/hosts file.

API Request:

<NetworkConnectionSection type="application/vnd.vmware.vcloud.networkConnectionSection+xml" href="https://10.201.113.22/api/vApp/vm-f101dc65-3269-4695-ab65-6aec3812b4ca/networkConnectionSection/" ovf:required="false" xsi:schemaLocation="http://schemas.dmtf.org/ovf/envelope/1 http://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.1.0.xsd http://www.vmware.com/vcloud/v1.5 http://10.201.113.22/api/v1.5/schema/master.xsd" xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <ovf:Info>Specifies the available VM network connections</ovf:Info>
    <PrimaryNetworkConnectionIndex>1</PrimaryNetworkConnectionIndex>
   <vcd:NetworkConnection network="vCloud 10.201.125.16x Mgmt" needsCustomization="true" xmlns:vcd="http://www.vmware.com/vcloud/v1.5">
        <vcd:NetworkConnectionIndex>1</vcd:NetworkConnectionIndex>
        <vcd:IpAddress>10.201.125.162</vcd:IpAddress>
        <vcd:IsConnected>true</vcd:IsConnected>
        <vcd:IpAddressAllocationMode>MANUAL</vcd:IpAddressAllocationMode>
    </vcd:NetworkConnection>
    <NetworkConnection network="vCloud 17.x" needsCustomization="true">
        <NetworkConnectionIndex>0</NetworkConnectionIndex>
        <IpAddress>192.168.17.5</IpAddress>
        <IsConnected>true</IsConnected>
        <MACAddress>00:50:56:01:00:96</MACAddress>
        <IpAddressAllocationMode>MANUAL</IpAddressAllocationMode>
    </NetworkConnection>
    <Link rel="edit" type="application/vnd.vmware.vcloud.networkConnectionSection+xml" href="https://10.201.113.22/api/vApp/vm-f101dc65-3269-4695-ab65-6aec3812b4ca/networkConnectionSection/" />
</NetworkConnectionSection>

Result:

<?xml version="1.0" encoding="UTF-8"?>

<ovf:Info>Specifies the available VM network connections</ovf:Info>

<NetworkConnectionIndex>1</NetworkConnectionIndex>

<IpAddressAllocationMode>MANUAL</IpAddressAllocationMode>

</NetworkConnection>

<NetworkConnectionIndex>0</NetworkConnectionIndex>

<IpAddressAllocationMode>MANUAL</IpAddressAllocationMode>

</NetworkConnection>

</NetworkConnectionSection>

Below is the correct and expected result (NIC 1 before NIC 0):

[root@CSCO-app-03F ~]# cat /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

10.201.125.162 CSCO-app-03F.tidalsoft.local CSCO-app-03F # NIC <eth1>

192.168.17.5 CSCO-app-03F # NIC <eth0>

[root@CSCO-app-03F ~]# hostname -f

CSCO-app-03F.tidalsoft.local

Below is the API Request followed by the result for the case where it does not work properly. The request has NIC 1 before NIC 0, but the result has NIC 0 before NIC 1. In both cases, NIC1 is identified as primary.

API Request:

<ovf:Info>Specifies the available VM network connections</ovf:Info>

<vcd:NetworkConnection network="vCloud 10.201.125.16x Mgmt" needsCustomization="true" xmlns:vcd="http://www.vmware.com/vcloud/v1.5">

<vcd:NetworkConnectionIndex>1</vcd:NetworkConnectionIndex>

<vcd:IpAddress>10.201.125.163</vcd:IpAddress>

<vcd:IsConnected>true</vcd:IsConnected>

<vcd:IpAddressAllocationMode>MANUAL</vcd:IpAddressAllocationMode>

</vcd:NetworkConnection>

<NetworkConnectionIndex>0</NetworkConnectionIndex>

<IpAddressAllocationMode>MANUAL</IpAddressAllocationMode>

</NetworkConnection>

</NetworkConnectionSection>

Result:

<?xml version="1.0" encoding="UTF-8"?>

<ovf:Info>Specifies the available VM network connections</ovf:Info>

<NetworkConnectionIndex>0</NetworkConnectionIndex>

<IpAddressAllocationMode>MANUAL</IpAddressAllocationMode>

</NetworkConnection>

<NetworkConnectionIndex>1</NetworkConnectionIndex>

<IpAddressAllocationMode>MANUAL</IpAddressAllocationMode>

</NetworkConnection>

</NetworkConnectionSection>

Below is incorrect (NIC 0 before NIC 1)

[root@CSCO-db-029 ~]# cat /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

192.168.17.9 CSCO-db-029 # NIC <eth0>

10.201.125.163 CSCO-db-029.tidalsoft.local CSCO-db-029 # NIC <eth1>

[root@CSCO-db-029 ~]# hostname -f

CSCO-db-029

the_kca · ‎08-11-2014

Have you ever identified a solution (or workaround) to this issue

All

Inconsistent Behavior using REST API to PUT NetworkConnectionSection results in wrong FQDN