T2-VOQ-Chassis: VS support by deepak-singhal0408 · Pull Request #18512 · sonic-net/sonic-buildimage

deepak-singhal0408 · 2024-03-29T23:50:11Z

Why I did it

Changes to ensure sonic_vs.img has everything required for it to be emulated as T2-VOQ-Chassis: Supervisor/Linecard..
With this change,

The image could be used to emulate Supervisor or Linecard
the image could be used to emulate different Linecard HWSKus.

Work item tracking

Microsoft ADO (number only):
27402561

How I did it

Following Changes are made as part of this PR:

On VS image, Database containers to be recreated again upon reboot. This will help change single asic VS image to multi-asic(docker_image_ctl.j2).
Copy all Sup and Linecard HWSKUs directories under kvm_platform directory. Create lanemap.ini, coreportindexmap.ini, fabriclanemap.ini under each hwsku/Asic directory. Copy asic.conf file from each platform directories to their child HW_SKU directories under kvm platform directory (This will help emulate different HW-Sku's with their respective num_asic asics): (sonic-device-data/Makefile).
New sonic-platform package for VS platforms. This is needed
3.1: To ensure, that database containers bring up goes through. The database containers on linecards fetch the supervisor slot_num, current_slot num etc.
PS: This package will be available on pizza box vs platforms as well. However, it will be noop there, as the package expects a metadata file, which will only be available on chassis VS platforms.
Changes to generate unique mac-address on VS platforms. This is done by using the device_hostname string (which will always be unique). Change to provide unique MAC address per asic on multi-asic VOQ VS platforms(sonic-cfggen, device_info.py, minigraph.py)
topology.service file to be dependent on sonic.target so that as part of config load_minigraph/config reload this service gets invoked.
topology.sh changes to move ports to their respective namespace (only applicable on multi-asic platforms)

How to verify it

Verified that sonic-vs.img.gz gets built succesfully and single asic VS DUT comes up fine(deployed vms-kvm-t0 topology) and could see that all containers come up fine. The show commands work as expected.
Verified bringup on VOQ chassis with different flavor of linecard emulation.

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

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

arlakshm

as comments.

files/build_templates/docker_image_ctl.j2

files/image_config/topology/topology.sh

src/sonic-py-common/sonic_py_common/device_info.py

…age support for VS (#3250) ### What I did For T2-Chassis VS support, we are adding new sonic_platform package for vs platforms. Please refer sonic-net/sonic-buildimage#18512 for more details. Due to this new platform package, need to modify excpetion handling as now the Module would be found, but the metadata file will not be found for pizzabox vs platforms. #### How I did it Modified the exception handling logic. MSFT ADO: 27414904 #### How to verify it Bring up vms-kvm-t0 topology. ran show interface status. The output is proper. PS: the Main PR(sonic-net/sonic-buildimage#18512) is dependent on this PR to be merged in first.

…mment

…isting/old info

… String

saiarcot895 · 2024-04-08T17:44:42Z

Looks like there's a new loganalyzer error message on t0:

Apr  8 07:23:49.040082 vlab-01 ERR sfputil: Failed to instantiate Chassis due to FileNotFoundError('Metadata file /etc/sonic/vs_chassis_metadata.json not found')

Is this expected? Does it need to be added to the ignore list?

deepak-singhal0408 · 2024-04-09T18:41:41Z

Looks like there's a new loganalyzer error message on t0:
Apr  8 07:23:49.040082 vlab-01 ERR sfputil: Failed to instantiate Chassis due to FileNotFoundError('Metadata file /etc/sonic/vs_chassis_metadata.json not found')
Is this expected? Does it need to be added to the ignore list?

Thanks @saiarcot895 .. Added above to loganalyzer_ignore file as discussed. PR sonic-net/sonic-mgmt#12345

deepak-singhal0408 · 2024-04-09T19:27:09Z

/azp run

azure-pipelines · 2024-04-09T19:27:15Z

Commenter does not have sufficient privileges for PR 18512 in repo sonic-net/sonic-buildimage

judyjoseph · 2024-04-09T20:19:17Z

/azp run

azure-pipelines · 2024-04-09T20:19:30Z

Azure Pipelines successfully started running 1 pipeline(s).

deepak-singhal0408 · 2024-04-09T21:01:25Z

Commenter does not have sufficient privileges for PR 18512 in repo sonic-net/sonic-buildimage

Hi @rlhui @yxieca , it seems I dont have permission to re run the pipeline? Could you please help check and let me know if this is expected or am I missing anything here?

saiarcot895 · 2024-04-12T21:59:46Z

@deepak-singhal0408 use /azpw instead of /azp.

judyjoseph · 2024-04-12T22:04:36Z

/azp run

azure-pipelines · 2024-04-12T22:04:52Z

Azure Pipelines successfully started running 1 pipeline(s).

deepak-singhal0408 · 2024-04-13T03:23:23Z

/azpw run

mssonicbld · 2024-04-13T03:23:25Z

/AzurePipelines run

prsunny · 2024-04-24T23:35:52Z

@deepak-singhal0408 , seems like swss PR checks are failing with this docker change. Could you confirm all swss tests were tested with this docker vs build?

deepak-singhal0408 · 2024-04-25T06:25:11Z

@deepak-singhal0408 , seems like swss PR checks are failing with this docker change. Could you confirm all swss tests were tested with this docker vs build?

@prsunny , this PR is merged in sonic-buildimage on April 19th. And there is a PR merge in sonic-swss on April 22nd(sonic-net/sonic-swss#3118). The PR checker for April 22nd change would have already taken my changes.. right? May I know why you think this PR would have caused issue?

…age support for VS (sonic-net#3250) ### What I did For T2-Chassis VS support, we are adding new sonic_platform package for vs platforms. Please refer sonic-net/sonic-buildimage#18512 for more details. Due to this new platform package, need to modify excpetion handling as now the Module would be found, but the metadata file will not be found for pizzabox vs platforms. #### How I did it Modified the exception handling logic. MSFT ADO: 27414904 #### How to verify it Bring up vms-kvm-t0 topology. ran show interface status. The output is proper. PS: the Main PR(sonic-net/sonic-buildimage#18512) is dependent on this PR to be merged in first.

…age support for VS (#3250) ### What I did For T2-Chassis VS support, we are adding new sonic_platform package for vs platforms. Please refer sonic-net/sonic-buildimage#18512 for more details. Due to this new platform package, need to modify excpetion handling as now the Module would be found, but the metadata file will not be found for pizzabox vs platforms. #### How I did it Modified the exception handling logic. MSFT ADO: 27414904 #### How to verify it Bring up vms-kvm-t0 topology. ran show interface status. The output is proper. PS: the Main PR(sonic-net/sonic-buildimage#18512) is dependent on this PR to be merged in first.

ishidawataru · 2024-06-07T06:00:33Z

@deepak-singhal0408 Where can I find vs_chassis_metadata.json? I built the multi-asic vs image from this repo but there is no vs_chassis_metadata.json under /etc/sonic.

yutongzhang-microsoft · 2024-06-21T03:22:42Z

Hi, @deepak-singhal0408 , I got the same error

Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:   File "/usr/lib/python3/dist-packages/sonic_platform/chassis.py", line 26, in __init__
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:     self.metadata = self._read_metadata()
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:                     ^^^^^^^^^^^^^^^^^^^^^
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:   File "/usr/lib/python3/dist-packages/sonic_platform/chassis.py", line 34, in _read_metadata
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:     raise FileNotFoundError("Metadata file {} not found".format(self.metadata_file))
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]: FileNotFoundError: Metadata file /etc/sonic/vs_chassis_metadata.json not found

deepak-singhal0408 · 2024-06-21T20:58:25Z

Hi, @deepak-singhal0408 , I got the same error

Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:   File "/usr/lib/python3/dist-packages/sonic_platform/chassis.py", line 26, in __init__
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:     self.metadata = self._read_metadata()
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:                     ^^^^^^^^^^^^^^^^^^^^^
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:   File "/usr/lib/python3/dist-packages/sonic_platform/chassis.py", line 34, in _read_metadata
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]:     raise FileNotFoundError("Metadata file {} not found".format(self.metadata_file))
Jun 21 03:01:42 vlab-01 determine-reboot-cause[15110]: FileNotFoundError: Metadata file /etc/sonic/vs_chassis_metadata.json not found

Hi @yutongzhang-microsoft , please give a try with this Fix. sonic-net/sonic-host-services#133
JFYI, this file is not expected to be present on pizza box vs platforms.
Even on chassis based vs image, this is not mandatory to be present..

ishidawataru · 2024-06-23T01:09:57Z

Even on chassis based vs image, this is not mandatory to be present..

How about stopping raising an exception instead of catching FileNotFoundError everywhere the exception can be ignored if the metadata file is not mandatory?

https://github.com/sonic-net/sonic-buildimage/pull/18512/files#diff-1837abe4216c07096db3b47b74a8ce47b0097622773caf92e9dc9f3c42636d06R34

yutongzhang-microsoft · 2024-06-24T01:58:33Z

Even on chassis based vs image, this is not mandatory to be present..

How about stopping raising an exception instead of catching FileNotFoundError everywhere the exception can be ignored if the metadata file is not mandatory?

https://github.com/sonic-net/sonic-buildimage/pull/18512/files#diff-1837abe4216c07096db3b47b74a8ce47b0097622773caf92e9dc9f3c42636d06R34

I agree with you, some other commands also failed because of this error.
@deepak-singhal0408 Can you fix as suggested?

…se containers on VS platform (#21089) Why I did it To support the emulation of VS chassis, we need to remove the existing critical service containers before transforming the HwSKU of the VS device. A previous PR #18512 introduced a change to the docker_image_ctl.j2 that forces VS images to recreate database containers every time the OS is cold started while the behaviors of other containers(swss/bgp/teamd/syncd) remained unchanged. As a consequence, when the VS device is rebooted without proper human intervention, the database containers will be recreated while the other services will reuse existing containers. That can cause the swss/bgp/syncd containers to become invalid if the database containers get recreated with a different container ID, because swss/bgp/syncd containers are configured to use the database containers as the underlying networking stack. By further investigation, we have found that it is not necessary to recreate the database containers in /usr/bin/database.sh to perform HwSKU transformation. So, we should remove this logic.

…se containers on VS platform (sonic-net#21089) Why I did it To support the emulation of VS chassis, we need to remove the existing critical service containers before transforming the HwSKU of the VS device. A previous PR sonic-net#18512 introduced a change to the docker_image_ctl.j2 that forces VS images to recreate database containers every time the OS is cold started while the behaviors of other containers(swss/bgp/teamd/syncd) remained unchanged. As a consequence, when the VS device is rebooted without proper human intervention, the database containers will be recreated while the other services will reuse existing containers. That can cause the swss/bgp/syncd containers to become invalid if the database containers get recreated with a different container ID, because swss/bgp/syncd containers are configured to use the database containers as the underlying networking stack. By further investigation, we have found that it is not necessary to recreate the database containers in /usr/bin/database.sh to perform HwSKU transformation. So, we should remove this logic.

…se containers on VS platform (#21089) Why I did it To support the emulation of VS chassis, we need to remove the existing critical service containers before transforming the HwSKU of the VS device. A previous PR #18512 introduced a change to the docker_image_ctl.j2 that forces VS images to recreate database containers every time the OS is cold started while the behaviors of other containers(swss/bgp/teamd/syncd) remained unchanged. As a consequence, when the VS device is rebooted without proper human intervention, the database containers will be recreated while the other services will reuse existing containers. That can cause the swss/bgp/syncd containers to become invalid if the database containers get recreated with a different container ID, because swss/bgp/syncd containers are configured to use the database containers as the underlying networking stack. By further investigation, we have found that it is not necessary to recreate the database containers in /usr/bin/database.sh to perform HwSKU transformation. So, we should remove this logic.

…se containers on VS platform (sonic-net#21089) Why I did it To support the emulation of VS chassis, we need to remove the existing critical service containers before transforming the HwSKU of the VS device. A previous PR sonic-net#18512 introduced a change to the docker_image_ctl.j2 that forces VS images to recreate database containers every time the OS is cold started while the behaviors of other containers(swss/bgp/teamd/syncd) remained unchanged. As a consequence, when the VS device is rebooted without proper human intervention, the database containers will be recreated while the other services will reuse existing containers. That can cause the swss/bgp/syncd containers to become invalid if the database containers get recreated with a different container ID, because swss/bgp/syncd containers are configured to use the database containers as the underlying networking stack. By further investigation, we have found that it is not necessary to recreate the database containers in /usr/bin/database.sh to perform HwSKU transformation. So, we should remove this logic.

…age support for VS (sonic-net#3250) ### What I did For T2-Chassis VS support, we are adding new sonic_platform package for vs platforms. Please refer sonic-net/sonic-buildimage#18512 for more details. Due to this new platform package, need to modify excpetion handling as now the Module would be found, but the metadata file will not be found for pizzabox vs platforms. #### How I did it Modified the exception handling logic. MSFT ADO: 27414904 #### How to verify it Bring up vms-kvm-t0 topology. ran show interface status. The output is proper. PS: the Main PR(sonic-net/sonic-buildimage#18512) is dependent on this PR to be merged in first.

…se containers on VS platform  #### Why I did it To support the emulation of VS chassis, we need to remove the existing critical service containers before transforming the HwSKU of the VS device. A previous PR [#18512](sonic-net/sonic-buildimage#18512) introduced a change to the docker_image_ctl.j2 that forces VS images to recreate database containers every time the OS is cold started while the behaviors of other containers(swss/bgp/teamd/syncd) remained unchanged. As a consequence, when the VS device is rebooted without proper human intervention, the database containers will be recreated while the other services will reuse existing containers. That can cause the swss/bgp/syncd containers to become invalid if the database containers get recreated with a different container ID, because swss/bgp/syncd containers are configured to use the database containers as the underlying networking stack. By further investigation, we have found that it is not necessary to recreate the database containers in /usr/bin/database.sh to perform HwSKU transformation. So, we should remove this logic. ##### Work item tracking - Microsoft ADO **(number only)**: 30454307 #### How I did it Remove the code that removes existing database containers in /usr/bin/database.sh #### How to verify it * Build VS image and install it on a KVM sonic-vs * Reboot the sonic-vs multiple times and check if all the containers are started successfully every time.  #### Which release branch to backport (provide reason below if selected) The original change was introduced into 202205 branch so we need to backport this fix. - [ ] 201811 - [ ] 201911 - [ ] 202006 - [ ] 202012 - [ ] 202106 - [ ] 202111 - [X] 202205 - [ ] 202211 - [ ] 202305 - [x] 202405 #### Tested branch (Please provide the tested image version)  - [X] 20220532.72 #### Description for the changelog  docker_image_ctl.j2: change to not remove existing database containers on VS platform

…hat recreates database containers on VS platform (#1703)  #### Why I did it To support the emulation of VS chassis, we need to remove the existing critical service containers before transforming the HwSKU of the VS device. A previous PR [#18512](sonic-net/sonic-buildimage#18512) introduced a change to the docker_image_ctl.j2 that forces VS images to recreate database containers every time the OS is cold started while the behaviors of other containers(swss/bgp/teamd/syncd) remained unchanged. As a consequence, when the VS device is rebooted without proper human intervention, the database containers will be recreated while the other services will reuse existing containers. That can cause the swss/bgp/syncd containers to become invalid if the database containers get recreated with a different container ID, because swss/bgp/syncd containers are configured to use the database containers as the underlying networking stack. By further investigation, we have found that it is not necessary to recreate the database containers in /usr/bin/database.sh to perform HwSKU transformation. So, we should remove this logic. ##### Work item tracking - Microsoft ADO **(number only)**: 30454307 #### How I did it Remove the code that removes existing database containers in /usr/bin/database.sh #### How to verify it * Build VS image and install it on a KVM sonic-vs * Reboot the sonic-vs multiple times and check if all the containers are started successfully every time.  #### Which release branch to backport (provide reason below if selected) The original change was introduced into 202205 branch so we need to backport this fix. - [ ] 201811 - [ ] 201911 - [ ] 202006 - [ ] 202012 - [ ] 202106 - [ ] 202111 - [X] 202205 - [ ] 202211 - [ ] 202305 - [x] 202405 #### Tested branch (Please provide the tested image version)  - [X] 20220532.72 #### Description for the changelog  docker_image_ctl.j2: change to not remove existing database containers on VS platform

chahibi · 2025-11-14T13:01:20Z

@deepak-singhal0408 I am still seeing the same error on the latest image from today. Do you have any update?

deepak-singhal0408 added 2 commits March 29, 2024 00:59

T2-VOQ-VS: vswitch related changes

16221da

Fix Makefile

6b51aef

deepak-singhal0408 requested a review from lguohan as a code owner March 29, 2024 23:50

deepak-singhal0408 self-assigned this Mar 29, 2024

deepak-singhal0408 mentioned this pull request Mar 30, 2024

T2-VOQ-VS: Modified exception handling due to new sonic_platform package support for VS sonic-net/sonic-utilities#3250

Merged

deepak-singhal0408 requested review from arlakshm, judyjoseph and saiarcot895 April 1, 2024 17:01

arlakshm reviewed Apr 1, 2024

View reviewed changes

Fix Indentation

723e4c8

deepak-singhal0408 added 4 commits April 4, 2024 05:18

Handled Macaddress Get for single asic linecards. Addressed review co…

d0d6c86

…mment

Parse the switch_type from minigraph file instead of checking from ex…

3c85d30

…isting/old info

Modify MacAddress Generation logic for VS: Generate based on hostname…

18555c3

… String

remove unused import

3334bb1

deepak-singhal0408 requested a review from abdosi April 7, 2024 07:20

deepak-singhal0408 mentioned this pull request Apr 8, 2024

T2-VOQ-VS: Add command to loganalyzer ignore sonic-net/sonic-mgmt#12345

Merged

8 tasks

Modified first octet of VS_MAC from 0x02 to 0x22

a74e296

mssonicbld mentioned this pull request May 9, 2024

[action] [PR:3250] T2-VOQ-VS: Modified exception handling due to new sonic_platform package support for VS (#3250) sonic-net/sonic-utilities#3310

Merged

deepak-singhal0408 mentioned this pull request Jun 21, 2024

Ignore sonic_platform package fileNotFoundError on non-chassis vs platforms sonic-net/sonic-host-services#133

Merged

ishidawataru mentioned this pull request Nov 11, 2024

vs: don't throw an exception when metadata file doesn't exist #20756

Open

11 tasks

BYGX-wcr mentioned this pull request Dec 7, 2024

[Bug Fix] docker_image_ctl.j2: remove the logic that recreates database containers on VS platform #21089

Merged

11 tasks

mssonicbld mentioned this pull request Dec 24, 2024

[action] [PR:21089] [Bug Fix] docker_image_ctl.j2: remove the logic that recreates database containers on VS platform (#21089) #21276

Merged

mssonicbld mentioned this pull request Oct 8, 2025

[action] [PR:21089] [Bug Fix] docker_image_ctl.j2: remove the logic that recreates database containers on VS platform Azure/sonic-buildimage-msft#1703

Merged

11 tasks

This was referenced Mar 26, 2026

Fix system-health crash on VS platform due to missing metadata file #26430

Closed

Fix system-health crash on VS platform due to missing metadata file #26446

Open

Conversation

deepak-singhal0408 commented Mar 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why I did it

Work item tracking

How I did it

How to verify it

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

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

Uh oh!

arlakshm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

saiarcot895 commented Apr 8, 2024

Uh oh!

deepak-singhal0408 commented Apr 9, 2024

Uh oh!

deepak-singhal0408 commented Apr 9, 2024

Uh oh!

azure-pipelines bot commented Apr 9, 2024

Uh oh!

judyjoseph commented Apr 9, 2024

Uh oh!

azure-pipelines bot commented Apr 9, 2024

Uh oh!

deepak-singhal0408 commented Apr 9, 2024

Uh oh!

saiarcot895 commented Apr 12, 2024

Uh oh!

judyjoseph commented Apr 12, 2024

Uh oh!

azure-pipelines bot commented Apr 12, 2024

Uh oh!

deepak-singhal0408 commented Apr 13, 2024

Uh oh!

mssonicbld commented Apr 13, 2024

Uh oh!

prsunny commented Apr 24, 2024

Uh oh!

deepak-singhal0408 commented Apr 25, 2024

Uh oh!

ishidawataru commented Jun 7, 2024

Uh oh!

yutongzhang-microsoft commented Jun 21, 2024

Uh oh!

deepak-singhal0408 commented Jun 21, 2024

Uh oh!

ishidawataru commented Jun 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yutongzhang-microsoft commented Jun 24, 2024

Uh oh!

chahibi commented Nov 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

deepak-singhal0408 commented Mar 29, 2024 •

edited

Loading

ishidawataru commented Jun 23, 2024 •

edited

Loading