How to: Deploy Apps as Virtual Network Devices #304
Quali-Community
started this conversation in
Useful Tips & Guides
Replies: 1 comment
-
sample shell file attached virtualswitch.zip Pascal Joly (Pascal.J) - 04/20/2016 12:54 PM
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In this article we describe the process to create an App that will represent a virtual network device once deployed.
Step 1:
Create a new network Shell that includes a specific autoload function to represent the structure of the deployed network device. see example attached : virtualswitch.zip
Data Model: In order for the resource family and model to be available for apps they have to be defined as type "Application".
Extract of datamodel.xml file (the Shell networking standard will be updated shortly with a specific branch for Apps):
Step 2:import this new Shell into CloudShell:you can use the shell foundry utility available on Git to package it.
Step 3: creating the App template
As a domain administrator, go to the Manage section and create a new App. In the advanced section select an App Family and Model that represent the deployed app model. In this example we select vswitchexample_cisco model.
provide the attribute values.
in the same screen, select an associated driver:
Step 4 : Deploy the App
The driver attached to the deployed app model (from the previous Step) is based on the standard networking shell and contains an "autoload" function (get_inventory function) and other functions typical of your network device lifecycle (upgrade firmware, backup/restore, run command).
The autoload function will need to be customized to defined specifically the resources to be created, based on the virtual device image.
This autoload function will be run after the VM is deployed and before the connectivity is run (by default). it will create the proper resource structure based on the model definition and configure the NIC mapping attributes defined for each port.
Note that the autoload function may be triggered as part of the Sandbox Setup script, and may be triggered at a different time in the App deployment workflow. Verify that the app deployment service has the "Autoload" attribute set to true (this is an admin only function).
Mapping Ports to NICs:
the Port model has a special attribute: "Requested vNIC Name" that will contain the corresponding expecting mapping between the logical resource port and the VM vNIC. this will enable the port to be connectable to L2 services.
The connectivity will look for the port attribute value to assign the VLAN to the correct vNIC. if not available we will find the first NIC available. By Default, the connectivity orchestration will take the first NIC available that is not already assigned to the reserved Network.
Once the App is deployed, the VM is created and the deployed App has now all the commands and resource structure available based on the autoload and the driver
The deployed app is now connectable.
Connect the App. the Vswitch can now be connected like a regular resource to other resources in the system or the VLAN service:
The VLANId allocation will be applied to the VM NIC that is mapped to the port (per port attribute definition).
Note: Several ports can be mapped between the same App instances as long as there are enough NICs available on the corresponding VM.
General guidelines and Limitations:
- Virtual Network Devices Connectivity: virtual network devices connectivity can only be done after deploying the VMs, so the connectivity needs to be orchestrated as part of the environment setup or done manually by the sandbox user (interactive mode).
- Modeling ports:Recommendation is to have one to one mapping of ports to vNIC (we don't support many to one port to NIC mapping). So the admin needs to make sure the VM image will have enough NICs to support that.
- Modeling cards: current limitation is a one to one mapping between a VM and the root network device. that means we do not support a network device in Apps that would have cards subresources mapped to one VM each.
- Virtual network devices in the BI: After they are deployed, App instances will be fully reportable, as if they were physical devices (you will be able to say what the vswitch utilization was, it will show in our out-of-box dashboards). However we will not be able to connect the usage to virtual capacity consumed from the vCenter or to the original App template.
Attachments:
Pascal Joly (Pascal.J) - 03/31/2016 04:27 AM
· 2491 ·
Beta Was this translation helpful? Give feedback.
All reactions