Bug 857160

Created attachment 612527 [details]
RHEVM log snippet for bond creation

When an interface has a network attached, the interface should be updated via UpdateNetworkToVdsInterfaceCommand.

AddBondCommand should be in use for creating a bond over nics which have no network attached. 

This is the reason for succeeding in bond creation for nics with no network attached and failing to update the eth0 which rhevm network is already attached.

From API side, supporting the described scenario is problematic:
1. Creating a bond is done via POST method.
2. Modifying an existing interface is done as PUT.

But what actually required here is creating a new bond by modifying an existing entity (detach a network, assemble a bond with that nic as a slave + additional slaves and attach the network to the created bond). This doesn't fall into any of REST methods.

The webadmin is capable doing so, since it uses the UpdateNetworkToVdsInterfaceCommand to achieve the complex network configuration.
But REST will use UpdateNetworkToVdsInterfaceCommand only via PUT to update a nic/network attached to, and at the moment the list of slaves is not being in REST API to the backend in UpdateNetworkToVdsInterfaceCommand.

We could add that list of slaves for the PUT method, but we'll end up with a mixed entity representing partially the slave nic and partially the required bond, e.g:

<host_nic>
    <name>bond0</name>
    <network id="388a02c5-c733-499b-bc3a-24a5f0534a61"/>
    <ip gateway="10.1.1.2" netmask="255.255.255.0" address="10.1.1.1"/>
    <boot_protocol>static</boot_protocol>
    <bonding>
        <options>
            <option type="Active-Backup" value="1" name="mode"/>
            <option value="100" name="miimon"/>
        </options>
        <slaves>
            <host_nic id="0640fe2d-b462-4057-a1a8-afcc4469e551">
            </host_nic>
            <host_nic id="364a296b-44f6-4691-a441-3fe55068258d">
            </host_nic>
        </slaves>
    </bonding>
    <check_connectivity>true</check_connectivity>
</host_nic>

and the entity referred in the url is the nic that the network is attached to.

This functionality is provided via REST using the SetupNetworks api, introduced in 3.1.

this functionality was not supported in RHEVM 3.0.X api you are using

btw in 3.1 there is new action in api called setupnetworks [2], it should
do the job, you can try it in sdk against 3.1 beta [2].

[1] /api/hosts/xxx/nics/setupnetworks
[2]

1. nics = api.hosts.get(name=xxx).nics
2. nics_arr = nics.list()
   (change nics in nics_arr like you'd expect them to look like)
3. my_nics = params.HostNics(host_nic=[nics_arr[0],nics_arr[1],...])
   or
   my_nics = params.HostNics(host_nic=nics_arr)
4. nics.setupnetworks(action=params.Action(host_nics=my_nics))

We have tried setupnetworks() with rhevm-sdk-3.1.0.8-1.el6ev and RHEV-M 3.1.0-14.el6ev.

Even if we just take the nics.list() result and call setupnetworks() with it, we get a Java NullPointerException exception on the RHEV-M server.

I'll attach a reproducer script, the current network configuration for the host we ran this against (taken from the API), and the Java stack trace.

Created attachment 614564 [details]
host network configuration

Created attachment 614565 [details]
reproducer script

Created attachment 614571 [details]
Java stack trace

After a few more trials, we managed to create bond0 with eth0/eth1 and the rhevm network using the setupnetworks() method. We did this by reverting the host's network configuration to rhevm on eth0, removing all other interfaces.

The NullPointerException seems to be related to the other networks we have on bond1 and bond2.

From the comments above it seems like when using sdk 3,1 with RHEV 3.1 the scenario worked and the bond was created.

Because this bugs encapsulates a lot of data which most of it is no longer relevant I would like to ask that if there is a specific issue with setupNetwork and bond creation in 3.1 please report a new bug with steps to reproduce.