4858153d25
Why I did it End goal: To have azure pipeline job to run multi-asic VS tests. Intermediate goal: Require multi-asic KVM image so that the test can be run. The difference between single asic and multi-asic KVM image is asic.conf file which has different NUM_ASIC values. Idea behind the approach in this PR to attain the intermediate goal above: Ease of building multi-asic KVM image so that any user or azure pipeline can use a simple make command to generate single or multi-asic KVM images as required. Use a single onie installer image and multiple KVM images for single and multi-asic images. Current scenario: For VS platform, sonic-vs.bin is generated which is the onie installer image and sonic-vs.img.gz is generated which is the KVM iamge. Scenario to be achieved: sonic-vs.bin - which will include single asic platform, 4 asic platform and 6 asic platform. sonic-vs.img.gz - single asic KVM image sonic-4asic-vs.img.gz - 4 asic KVM image sonic-6asic-vs.img.gz - 6 asic KVM image In this PR, 2 new platforms are added for 4-asic and 6-asic VS. How I did it Create 4-asic and 6-asic device directories with the required files and hwsku files. Add onie-recovery image information in vs platform. How to verify it After this PR change, no build change. sonic-vs.bin onie installer image should include information of new multi-asic vs platforms. |
||
|---|---|---|
| .. | ||
| brcm_gearbox_vs | ||
| plugins | ||
| asic.conf | ||
| default_sku | ||
| installer.conf | ||
| pmon_daemon_control.json | ||
| README.md | ||
Changing the virtual device
You can control the hw sku and default factory configuration for the VS image by modifying the content of the file default_sku in this directory.
The format of default_sku is a single line:
<hw_key> <default_preset>
Allowable values for hw_key
| hw_key | Device |
|---|---|
| Force10-S6000 | Dell Force10 S6000 |
| brcm_gearbox_vs | Similar to Force10-S6000, but implements a virtual BRCM81724 Gearbox Phy |
Allowable values for default_preset
These include "t1", "l2", and "empty". See the file sonic-buildimage/src/sonic-config-engine/config_samples.py for details on how each default_preset value is interpreted.
Changing the hwsku of an existing VS switch
To change the default hwsku for a VS image that has already been built and installed, follow these steps:
-
Edit /usr/share/sonic/device/x86_64-kvm_x86_64-r0/default_sku. For details, see the section below (Device Specific Documentation)
-
Edit /etc/sonic/config_db.json, and change the "hwsku" key in DEVICE_METADATA:localhost to match the hw_key used in default_sku. Example:
"DEVICE_METADATA": { "localhost": { ... "hwsku": "brcm_gearbox_vs", ... } }, ...
-
Reboot the switch
-
Use "show platform summary" to verify, and follow any steps specific to the platform, as needed, such as those described below for the brcm_gearbox_vs hwsku.
Device Specific Documentation
For general info on building, see https://github.com/Azure/sonic-buildimage/blob/master/README.md
Force-10-S6000
This is the default VS for SONiC. To enable, set contents of default_sku to:
Force10-S6000 t1
To build:
make init
make configure PLATFORM=vs
make target/sonic-vs.img.gz
brcm_gearbox_vs
This sku simulates a device with a Broadcom BRCM81724 gearbox PHY. To enable, set default_sku to:
brcm_gearbox_vs t1
To build (same as Force-10-S6000):
make init
make configure PLATFORM=vs
make target/sonic-vs.img.gz
To verify, install and bring up SONiC. There will be a new gbsyncd docker which is designed to respond to configuration directed towards the gearbox phy "switch". swss will create that gearbox switch on startup after detecting the gearbox is present (this is done by a short lived gearsyncd that runs in the swss docker).
The commands "show gearbox interfaces status" and "show gearbox phys status" can be used to verify the virtual gearbox phy has been created. See https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md#gearbox for details.