[ R4.1 build 15 ] Juju + Netronome : Virtio-forwarder needs to be allowed to configure as default vnic type

[Ankit Jain]

Issue : Not able to set Virtio-forwarder as default vnic-type. By default, vnic type used is "normal" as shown below:

| binding_profile | None |
| binding_vif_details | port_filter='True' |
| binding_vif_type | vrouter |
| binding_vnic_type | normal

Need a way to set virtio-forwarder as default vnic type with the following details:

| binding_host_id | nodei8 |
| binding_profile | pci_slot='0000:04:0f.3', pci_vendor_info='19ee:6003', physical_network='None' |
| binding_vif_details | vhostuser_mode='server', vhostuser_socket='/var/run/vrouter/uvh_vif_tap49f0978a-d0', vhostuser_vrouter_plug='True' |
| binding_vif_type | vrouter |
| binding_vnic_type | virtio-forwarder

As of now, we know the following way to launch accelerated VMs:

1) Create a port with vnic-type virtio-forwarder
   openstack port create --network net1 --vnic-type virtio-forwarder port1

2) Launch the VM with port1

It does not seem to be possible to directly launch VMs with virtio-forwarder as default vnic-type. The port with virtio-forwarder as vnic-type need to be created.

We need a way to set Virtio-forwarder as default vnic-type to run the sanity scripts
as many test cases create VMs by passing net_ids as nic_list skipping the port creation ( not port_ids where it's allowed to specifiy virtio-forwarder as vnic type as shown below:

test_vm_add_delete -> vm fixture : create_vm ->

        vm1_fixture = self.create_vm(vn_fixture=vn_fixture,
                                     vm_name=get_random_name('vm_add_delete'))

        elif port_ids:
            nics_list = [{'port-id': x} for x in port_ids]
        elif vn_ids:
            nics_list = [{'net-id': x} for x in vn_ids]

        self.obj.servers.create(name=vm_name, image=image,
                                security_groups=sg_ids,
                                flavor=flavor, nics=nics_list,
                                key_name=self.key, availability_zone=zone,
                                min_count=count, max_count=count, userdata=userdata)

[Jan Gutter (jangutter)]

There are many places in OpenStack core (Neutron and Nova) that assumes the default VNIC type is NORMAL. Currently, the only supported place to set the VNIC type is by using the API at port creation, for example, with HEAT or the CLI.

[Jan Gutter (jangutter)]

Would this bug not be more applicable to contrail-test ? The OpenStack API and workflow for this case is well-established (mech_sriov has similar semantics) and is highly unlikely to change.

[Ankit Jain (ankitja)]

Openstack supports VM creation using net_ids. So, If I want to launch a VM using net_ids not port_ids as required by my test, but want to use a different vnic type than the normal one, how do I achieve the same without this issue??

Could not understand how could it be just contrail-test related issue..
If not default, then can't specifying vnic type at the time of vm creation be made possible?
May be an option parameter in create_vm.

[Sudheendra Rao (sudheendra-k)]

adding to #3, this problem wan't seen in R3.1/R3.2 for netronome and same TCs from contrail-test passed. So AFAIK the bug is not related to contrail-test.

[Jan Gutter (jangutter)]

I think I see where the confusion is happening. In R3.1, the version of OpenStack Nova provided by Juniper was hacked to not require the PCI allocation. This change was not acceptable for upstream OpenStack and had NUMA issues. The current VNIC based method is acceptable upstream (openvswitch, mech_sriov and others are using this mechanism), works with NUMA and is available since OpenStack Pike.

A side effect of this is that accelerated ports have to be plugged using port-based attachment. The net-based attachment is a convenience function: behind the scenes a port is still created.