dd9be59cd1
#### Why I did it Backport of https://github.com/Azure/sonic-buildimage/pull/7083 to the 202012 branch. To prevent error [messages](https://dev.azure.com/mssonic/build/_build/results?buildId=2254&view=logs&j=9a13fbcd-e92d-583c-2f89-d81f90cac1fd&t=739db6ba-1b35-5485-5697-de102068d650&l=802) like the following from being logged: ``` Mar 17 02:33:48.523153 vlab-01 INFO swss#supervisord 2021-03-17 02:33:48,518 ERRO pool supervisor-proc-exit-listener event buffer overflowed, discarding event 46 ``` This is basically an addendum to https://github.com/Azure/sonic-buildimage/pull/5247, which increased the event buffer size for dependent-startup. While supervisor-proc-exit-listener doesn't subscribe to as many events as dependent-startup, there is still a chance some containers (like swss, as in the example above) have enough processes running to cause an overflow of the default buffer size of 10. This is especially important for preventing erroneous log_analyzer failures in the sonic-mgmt repo regression tests, which have started occasionally causing PR check builds to fail. Example [here](https://dev.azure.com/mssonic/build/_build/results?buildId=2254&view=logs&j=9a13fbcd-e92d-583c-2f89-d81f90cac1fd&t=739db6ba-1b35-5485-5697-de102068d650&l=802). I set all supervisor-proc-exit-listener event buffer sizes to 1024, and also updated all dependent-startup event buffer sizes to 1024, as well, to keep things simple, unified, and allow headroom so that we will not need to adjust these values frequently, if at all. |
||
|---|---|---|
| .. | ||
| docker-gbsyncd-vs | ||
| docker-sonic-vs | ||
| docker-syncd-vs | ||
| sonic-version | ||
| tests | ||
| create_vnet.sh | ||
| docker-gbsyncd-vs.dep | ||
| docker-gbsyncd-vs.mk | ||
| docker-ptf.dep | ||
| docker-ptf.mk | ||
| docker-sonic-vs.dep | ||
| docker-sonic-vs.mk | ||
| docker-syncd-vs.dep | ||
| docker-syncd-vs.mk | ||
| gbsyncd-vs.mk | ||
| kvm-image.dep | ||
| kvm-image.mk | ||
| libsaithrift-dev.dep | ||
| libsaithrift-dev.mk | ||
| one-image.dep | ||
| one-image.mk | ||
| onie.dep | ||
| onie.mk | ||
| platform.conf | ||
| raw-image.dep | ||
| raw-image.mk | ||
| README.gns3.md | ||
| README.vsdocker.md | ||
| README.vsvm.md | ||
| rules.dep | ||
| rules.mk | ||
| sonic_multiasic.xml | ||
| sonic-gns3a.sh | ||
| sonic-version.dep | ||
| sonic-version.mk | ||
| sonic.xml | ||
| syncd-vs.dep | ||
| syncd-vs.mk | ||
HOWTO Use Virtual Switch (VM)
- Install libvirt, kvm, qemu
sudo apt-get install libvirt-clients qemu-kvm libvirt-bin
- Create SONiC VM for single ASIC HWSKU
$ sudo virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh #
virsh # create sonic.xml
Domain sonic created from sonic.xml
virsh #
- Create SONiC VM for multi-ASIC HWSKU Update sonic_multiasic.xml with the external interfaces required for HWSKU.
$ sudo virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh #
virsh # create sonic_multiasic.xml
Domain sonic created from sonic.xml
virsh #
Once booted up, create a file "asic.conf" with the content:
NUM_ASIC=<Number of asics>
under /usr/share/sonic/device/x86_64-kvm_x86_64-r0/
Also, create a "topology.sh" file which will simulate the internal
asic connectivity of the hardware under
/usr/share/sonic/device/x86_64-kvm_x86_64-r0/<HWSKU>
The HWSKU directory will have the required files like port_config.ini
for each ASIC.
Having done this, a new service "topology.service" will be started
during bootup which will invoke topology.sh script.
3. Access virtual switch:
1. Connect SONiC VM via console
```
$ telnet 127.0.0.1 7000
```
OR
2. Connect SONiC VM via SSH
1. Connect via console (see 3.1 above)
2. Request a new DHCP address
```
sudo dhclient -v
```
3. Connect via SSH
```
$ ssh -p 3040 admin@127.0.0.1
```