This repository has been archived on 2025-03-20. You can view files and clone it, but cannot push or open issues or pull requests.
sonic-buildimage/platform/vs
yozhao101 be3c036794
[supervisord] Monitoring the critical processes with supervisord. (#6242)
- Why I did it
Initially, we used Monit to monitor critical processes in each container. If one of critical processes was not running
or crashed due to some reasons, then Monit will write an alerting message into syslog periodically. If we add a new process
in a container, the corresponding Monti configuration file will also need to update. It is a little hard for maintenance.

Currently we employed event listener of Supervisod to do this monitoring. Since processes in each container are managed by
Supervisord, we can only focus on the logic of monitoring.

- How I did it
We borrowed the event listener of Supervisord to monitor critical processes in containers. The event listener will take
following steps if it was notified one of critical processes exited unexpectedly:

The event listener will first check whether the auto-restart mechanism was enabled for this container or not. If auto-restart mechanism was enabled, event listener will kill the Supervisord process, which should cause the container to exit and subsequently get restarted.

If auto-restart mechanism was not enabled for this contianer, the event listener will enter a loop which will first sleep 1 minute and then check whether the process is running. If yes, the event listener exits. If no, an alerting message will be written into syslog.

- How to verify it
First, we need checked whether the auto-restart mechanism of a container was enabled or not by running the command show feature status. If enabled, one critical process should be selected and killed manually, then we need check whether the container will be restarted or not.

Second, we can disable the auto-restart mechanism if it was enabled at step 1 by running the commnad sudo config feature autorestart <container_name> disabled. Then one critical process should be selected and killed. After that, we will see the alerting message which will appear in the syslog every 1 minute.

- Which release branch to backport (provide reason below if selected)

 201811
 201911
[x ] 202006
2021-01-21 12:57:49 -08:00
..
docker-gbsyncd-vs [supervisord] Monitoring the critical processes with supervisord. (#6242) 2021-01-21 12:57:49 -08:00
docker-sonic-vs sonic-config-engine uses libswsscommon instead of swsssdk (#6406) 2021-01-20 12:06:08 -08:00
docker-syncd-vs [supervisord] Monitoring the critical processes with supervisord. (#6242) 2021-01-21 12:57:49 -08:00
sonic-version [vs]: build sonic vs kvm image (#2269) 2018-11-20 22:32:40 -08:00
tests FRR 7.5 2020-12-29 03:44:49 -08:00
create_vnet.sh [vs]: dynamically create front panel ports in vs docker (#4499) 2020-04-30 12:50:59 -07:00
docker-gbsyncd-vs.dep Add gearbox phy device files and a new physyncd docker to support VS gearbox phy feature (#4851) 2020-09-25 08:32:44 -07:00
docker-gbsyncd-vs.mk Add gearbox phy device files and a new physyncd docker to support VS gearbox phy feature (#4851) 2020-09-25 08:32:44 -07:00
docker-sonic-vs.dep [build]: support for DPKG local caching (#4117) 2020-03-11 20:04:52 -07:00
docker-sonic-vs.mk [sonic-yang-mgmt-py2]: remove sonic-yang-mgmt py2 (#6262) 2020-12-22 21:05:33 -08:00
docker-syncd-vs.dep [build]: support for DPKG local caching (#4117) 2020-03-11 20:04:52 -07:00
docker-syncd-vs.mk [docker-{sonic,syncd}-vs]: upgrade {sonic,syncd}-vs docker to stretch (#2865) 2019-05-06 07:19:36 -07:00
gbsyncd-vs.mk Add gearbox phy device files and a new physyncd docker to support VS gearbox phy feature (#4851) 2020-09-25 08:32:44 -07:00
kvm-image.dep [build]: support for DPKG local caching (#4117) 2020-03-11 20:04:52 -07:00
kvm-image.mk [build]: Move Systemd service start to systemd generator (#3172) 2019-07-29 15:52:15 -07:00
one-image.dep [build]: support for DPKG local caching (#4117) 2020-03-11 20:04:52 -07:00
one-image.mk [vsimage]: install systemd generator into one image 2020-04-17 04:51:51 +00:00
onie.dep [build]: support for DPKG local caching (#4117) 2020-03-11 20:04:52 -07:00
onie.mk [vs]: build sonic vs kvm image (#2269) 2018-11-20 22:32:40 -08:00
platform.conf [vs]: build sonic vs kvm image (#2269) 2018-11-20 22:32:40 -08:00
raw-image.dep [vsraw]: build sonic-vs.raw image 2020-04-17 04:51:51 +00:00
raw-image.mk [vsraw]: build sonic-vs.raw image 2020-04-17 04:51:51 +00:00
README.gns3.md [vsimage]: Support for the creation of a GNS3 appliance file (#3553) 2019-10-07 07:16:11 -07:00
README.vsdocker.md [vs]: dynamically create front panel ports in vs docker (#4499) 2020-04-30 12:50:59 -07:00
README.vsvm.md [baseimage]: support building multi-asic component (#3856) 2020-01-26 13:56:42 -08:00
rules.dep [build]: Fix for missing dependencies in the DPKG framework (#6393) 2021-01-13 10:32:42 -08:00
rules.mk Add gearbox phy device files and a new physyncd docker to support VS gearbox phy feature (#4851) 2020-09-25 08:32:44 -07:00
sonic_multiasic.xml Multi-ASIC implementation (#3888) 2020-03-31 10:06:19 -07:00
sonic-gns3a.sh [kvmimae]: Update sonic-gns3a.sh (#4694) 2020-06-04 13:29:36 -07:00
sonic-version.dep [build]: support for DPKG local caching (#4117) 2020-03-11 20:04:52 -07:00
sonic-version.mk [vs]: build sonic vs kvm image (#2269) 2018-11-20 22:32:40 -08:00
sonic.xml [vs]: sync changes to disk and add e1000 driver to sonic vm (#2288) 2018-11-22 12:09:21 -08:00
syncd-vs.dep [build]: support for DPKG local caching (#4117) 2020-03-11 20:04:52 -07:00
syncd-vs.mk [docker-orchagent]: make build depends only on sairedis package (#4880) 2020-07-12 18:08:51 +00:00

HOWTO Use Virtual Switch (VM)

  1. Install libvirt, kvm, qemu
sudo apt-get install libvirt-clients qemu-kvm libvirt-bin
  1. 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 # 
  1. 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
        ```