Test Specification

This file lists all test cases’ specifications.

class KvmUnitTestSuite
Description:
This test suite is for executing the community maintained KVM tests.
See: https://gitlab.com/kvm-unit-tests/kvm-unit-tests
Platform:

Azure, Ready

Area:

kvm

Category:

community

verify_kvm_unit_tests()
Description:
Runs kvm-unit-tests.
Priority:

3

class Docker
Description:
This test suite runs the docker test cases for java, python, dotnet 3.1
, dotnet5.0, and wordpress.
Platform:

Azure, Ready

Area:

docker

Category:

functional

verify_docker_java_app()
Description:
This test case creates and runs a java app using docker
Steps:
1. Install Docker
2. Copy java dockerfile and program file to node
3. Create docker image and run docker container
4. Check results of docker run against java string identifier
Priority:

2

verify_docker_python_app()
Description:
This test case creates and runs a python app using docker
Steps:
1. Install Docker
2. Copy python dockerfile and program file to node
3. Create docker image and run docker container
4. Check results of docker run against python string identifier
Priority:

3

verify_docker_compose_wordpress_app()
Description:
This test case uses docker-compose to create and run a wordpress mysql app
Steps:
1. Install Docker and Docker-Compose on node
2. Copy docker-compose.yml into node
3. Start docker container with docker-compose
4. Run ps in the docker container and capture output
5. Check that “apache2” can be found in captured output
Priority:

3

verify_docker_dotnet50_app()
Description:
This test case creates and runs a dotnet app using docker
Steps:
1. Install Docker
2. Copy dotnet dockerfile into node
3. Create docker image and run docker container
4. Check results of docker run against dotnet string identifier
Priority:

2

verify_docker_dotnet31_app()
Description:
This test case creates and runs a dotnet app using docker
Steps:
1. Install Docker
2. Copy dotnet dockerfile into node
3. Create docker image and run docker container
4. Check results of docker run against dotnet string identifier
Priority:

1

verify_docker_seccomp_profile()
Description:
Verifies a custom Docker seccomp profile is applied and enforced.
Steps:
1. Install Docker on the target node
2. Copy the custom seccomp profile that explicitly denies the chmod syscall
3. Start a container with this custom seccomp profile and try to run chmod;
the command should fail, proving the profile is enforced
4. Start another container without the custom profile and run the same chmod
command; this time it should succeed, proving the restriction only comes
from the profile
Priority:

2

Requirement:

unsupported_os[Windows, BSD]

class Xfstesting
Description:
This test suite is to validate different types of data disk and network file system
on Linux VM using xfstests.
Platform:

Azure, Ready

Area:

storage

Category:

community

verify_generic_standard_datadisk()
Description:
This test case will run generic xfstests testing against
standard data disk with xfs type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_generic_ext4_standard_datadisk()
Description:
This test case will run generic xfstests testing against
standard data disk with ext4 type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_xfs_standard_datadisk()
Description:
This test case will run xfs xfstests testing against
standard data disk with xfs type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_xfs_nvme_datadisk()
Description:
This test case will run xfs xfstests testing against
nvme data disk with xfs type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_generic_ext4_nvme_datadisk()
Description:
This test case will run generic xfstests testing against
nvme data disk with ext4 type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_ext4_standard_datadisk()
Description:
This test case will run ext4 xfstests testing against
standard data disk with ext4 type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_btrfs_nvme_datadisk()
Description:
This test case will run btrfs xfstests testing against
nvme data disk with btrfs type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_btrfs_standard_datadisk()
Description:
This test case will run btrfs xfstests testing against
standard data disk with btrfs type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_generic_nvme_datadisk()
Description:
This test case will run generic xfstests testing against
nvme data disk with xfs type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_ext4_nvme_datadisk()
Description:
This test case will run ext4 xfstests testing against
nvme data disk with ext4 type system.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_azure_file_share_nfsv4()
Description:
This test case runs xfstests against Azure Files NFSv4.1 shares.
This is similar to verify_azure_file_share but uses NFSv4.1 protocol
instead of SMB/CIFS. Azure Files NFS requires:
- Premium FileStorage storage account
- Private endpoint connectivity (NFS doesn’t support public endpoints)
- NFSv4.1 protocol support
Parallel Execution:
Tests are split across multiple workers (default: 4) to reduce
total execution time. Each worker gets its own:
- xfstests directory copy (to avoid shared state conflicts)
- Azure NFS File Share pair (test + scratch)
- Test and scratch mount points
Reference:
https://learn.microsoft.com/en-us/azure/storage/files/files-nfs-protocol
Priority:

5

Requirement:

unsupported_os[BSD, Windows]

verify_azure_file_share()
Description:
This test case will run cifs xfstests testing against
azure file share.
The case will provision storage account with private endpoint
and use access key // ntlmv2 for authentication.
Parallel Execution:
Tests are split across multiple workers (default: 4) to reduce
total execution time. Each worker gets its own:
- xfstests directory copy (to avoid shared state conflicts)
- Azure File Share pair (CIFS doesn’t support subdirectory mounts)
- Test and scratch mount points
Priority:

5

Requirement:

unsupported_os[BSD, Windows]

class TvmTest
Description:
This test suite is to validate secureboot in Linux VM.
Platform:

Azure, Ready

Area:

tvm

Category:

functional

verify_measuredboot_compatibility()
Description:
This case tests the image is compatible with Measured Boot.
Steps:
1. Enable repository azurecore and install
azure-compatscanner, then run mbinfo to check
Measured Boot compatibility (skipped on ARM64).
2. Install tpm2-tools and read TPM PCR0-7 values
using tpm2_pcrread.
3. Verify that PCR0-7 are not all zeros, which
indicates the firmware and bootloader recorded
measurements during boot (Measured Boot active).
Priority:

2

Requirement:

supported_features

verify_secureboot_compatibility()
Description:
This case tests the image is compatible with Secure Boot.
Steps:
1. Enable repository azurecore and install
azure-security, then run sbinfo to check Secure
Boot compatibility (skipped on ARM64).
2. Install mokutil and verify Secure Boot is enabled
via mokutil –sb-state.
Priority:

2

Requirement:

supported_features

class Nvme
Description:
This test suite is to validate NVMe disk on Linux VM.
Platform:

Azure, Ready

Area:

nvme

Category:

functional

verify_nvme_blkdiscard()
Description:
This test case will
1. Create a partition, xfs filesystem and mount it.
2. Umount the mountpoint.
3. Run blkdiscard command on the partition.
4. Remount command should fail after run blkdiscard command.
Priority:

3

Requirement:

supported_features[Nvme]

verify_nvme_fstrim()
Description:
This test case will
1. Create a partition, xfs filesystem and mount it.
2. Check how much the mountpoint is trimmed before operations.
3. Create a 300 gb file ‘data’ using dd command in the partition.
4. Check how much the mountpoint is trimmed after creating the file.
5. Delete the file ‘data’.
6. Check how much the mountpoint is trimmed after deleting the file,
and compare the final fstrim status with initial fstrim status.
Priority:

3

Requirement:

supported_features[Nvme]

verify_nvme_max_disk()
Description:
This case runs nvme_basic_validation test against max NVMe disks.
The test steps are same as nvme_basic_validation.
Priority:

2

Requirement:

supported_features

verify_nvme_manage_ns()
Description:
This test case will run commands 2-5, the commands are expected fail or not
based on the capabilities of the device.
1. Use nvme id-ctrl device command list the capabilities of the device.
1.1 When ‘Format NVM Supported’ shown up in output of ‘nvme id-ctrl device’,
then nvme disk can be format, otherwise, it can’t be format.
1.2 When ‘NS Management and Attachment Supported’ shown up in output of
‘nvme id-ctrl device’, nvme namespace can be created, deleted and detached,
otherwise it can’t be managed.
2. nvme format namespace - format a namespace.
3. nvme create-ns namespace - create a namespace.
4. nvme delete-ns -n 1 namespace - delete a namespace.
5. nvme detach-ns -n 1 namespace - detach a namespace.
Priority:

3

Requirement:

supported_features[Nvme]

verify_nvme_basic()
Description:
This test case will
1. Get nvme devices and nvme namespaces from /dev/ folder,
compare the count of nvme namespaces and nvme devices.
2. Compare the count of nvme namespaces return from nvme list
and list nvme namespaces under /dev/.
3. Compare nvme devices count return from lspci
and list nvme devices under /dev/.
4. Azure platform only, nvme devices count should equal to
actual vCPU count / 8.
Priority:

1

Requirement:

supported_features[Nvme]

verify_nvme_sriov_rescind()
Description:
This test case does following steps to verify VM working normally during
disable and enable nvme and sriov devices.
1. Disable PCI devices.
2. Enable PCI devices.
3. Get PCI devices slots.
4. Check PCI devices are back after rescan.
Priority:

2

Requirement:

supported_features[Nvme]

verify_nvme_function_unpartitioned()
Description:
The test case is same as verify_nvme_function, except it uses
unpartitioned disks.
This test case will do following things for each NVMe device.
1. Get the number of errors from nvme-cli before operations.
2. Create filesystem and mount it.
3. Create a txt file on the partition, content is ‘TestContent’.
4. Create a file ‘data’ on the partition, get the md5sum value.
5. Umount and remount the partition.
6. Get the txt file content, compare the value.
7. Compare the number of errors from nvme-cli after operations.
Priority:

2

Requirement:

supported_features[Nvme]

verify_nvme_rescind()
Description:
This test case will
1. Disable NVME devices.
2. Enable PCI devices.
3. Get NVMe devices slots.
4. Check NVMe devices are back after rescan.
Priority:

2

Requirement:

supported_features[Nvme]

verify_nvme_function()
Description:
This test case will do following things for each NVMe device.
1. Get the number of errors from nvme-cli before operations.
2. Create a partition, filesystem and mount it.
3. Create a txt file on the partition, content is ‘TestContent’.
4. Create a file ‘data’ on the partition, get the md5sum value.
5. Umount and remount the partition.
6. Get the txt file content, compare the value.
7. Compare the number of errors from nvme-cli after operations.
Priority:

2

Requirement:

supported_features[Nvme]

class Dpdk
Description:
This test suite check DPDK functionality
Platform:

Azure, Ready

Area:

dpdk

Category:

functional

verify_dpdk_testpmd_hotplug_sender_failsafe_pmd()
Description:
testpmd with hotplug vf for failsafe pmd (send only version)
Priority:

2

Requirement:

supported_features[IsolatedResource]

verify_dpdk_l3fwd_ntttcp_tcp()
Description:
Run the L3 forwarding test for DPDK.
This test creates a DPDK port forwarding setup between
two NICs on the same VM. It forwards packets from a sender on
subnet_a to a receiver on subnet_b. Without l3fwd,
packets will not be able to jump the subnets. This imitates
a network virtual appliance setup, firewall, or other data plane
tool for managing network traffic with DPDK.
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_multiprocess()
Description:
Build and run DPDK multiprocess client/server sample application.
Requires 3 nics since client/server needs two ports + 1 nic for LISA
Priority:

4

Requirement:

supported_features[IsolatedResource]

verify_dpdk_send_receive_multi_txrx_queue_netvsc()
Description:
Tests a basic sender/receiver setup for default failsafe driver setup.
Sender sends the packets, receiver receives them.
We check both to make sure the received traffic is within the expected
order-of-magnitude.
Priority:

2

Requirement:

min_count=2

verify_dpdk_send_receive_multi_txrx_queue_failsafe()
Description:
Tests a basic sender/receiver setup for default failsafe driver setup.
Sender sends the packets, receiver receives them.
We check both to make sure the received traffic is within the
expected order-of-magnitude.
Priority:

2

Requirement:

min_count=2

verify_dpdk_build_gb_hugepages_failsafe()
Description:
failsafe version with 2MB hugepages
This test case checks DPDK can be built and installed correctly.
Prerequisites, accelerated networking must be enabled.
The VM should have at least two network interfaces,
with one interface for management.
More details: https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk#prerequisites # noqa: E501
Priority:

2

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_send_receive_netvsc()
Description:
Tests a basic sender/receiver setup for direct netvsc pmd setup.
Sender sends the packets, receiver receives them.
We check both to make sure the received traffic is within the expected
order-of-magnitude.
Priority:

2

Requirement:

min_count=2

verify_dpdk_ring_ping()
Description:
This test runs the dpdk ring ping utility from:
https://github.com/shemminger/dpdk-ring-ping
to measure the maximum latency for 99.999 percent of packets during
the test run. The maximum should be under 200000 nanoseconds
(.2 milliseconds).
Not dependent on any specific PMD.
Priority:

4

Requirement:

supported_features[IsolatedResource]

verify_dpdk_l3fwd_ntttcp_tcp_hotplug()
Description:
Run the L3 forwarding test for DPDK.
This test creates a DPDK port forwarding setup between
two NICs on the same VM. It forwards packets from a sender on
subnet_a to a receiver on subnet_b. Without l3fwd,
packets will not be able to jump the subnets. This imitates
a network virtual appliance setup, firewall, or other data plane
tool for managing network traffic with DPDK.
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_build_failsafe()
Description:
failsafe version with 1GiB hugepages.
This test case checks DPDK can be built and installed correctly.
Prerequisites, accelerated networking must be enabled.
The VM should have at least two network interfaces,
with one interface for management.
More details: https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk#prerequisites # noqa: E501
Priority:

2

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_send_receive_failsafe()
Description:
Tests a basic sender/receiver setup for default failsafe driver setup.
Sender sends the packets, receiver receives them.
We check both to make sure the received traffic is within the expected
order-of-magnitude.
Priority:

2

Requirement:

min_count=2

verify_dpdk_l3fwd_ntttcp_tcp_gb_hugepages()
Description:
Run the l3fwd test using GiB hugepages.
This test creates a DPDK port forwarding setup between
two NICs on the same VM. It forwards packets from a sender on
subnet_a to a receiver on subnet_b. Without l3fwd,
packets will not be able to jump the subnets. This imitates
a network virtual appliance setup, firewall, or other data plane
tool for managing network traffic with DPDK.
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_send_receive_multi_txrx_queue_4k_mtu_netvsc()
Description:
Tests a basic sender/receiver setup for dpdk netvsc pmd with MTU of 4k.
Sender sends the packets, receiver receives them.
Test will fail if MTU set fails and/or DPDK crashes.
Test Gbps throughput is annotated into the test result.
Priority:

2

Requirement:

min_count=2

verify_dpdk_testpmd_hotplug_receiver_netvsc_pmd()
Description:
test sriov failsafe during vf revoke (receive side)
Priority:

2

Requirement:

supported_features[IsolatedResource]

verify_dpdk_send_receive_multi_txrx_queue_8k_mtu_netvsc()
Description:
Tests a basic sender/receiver setup for dpdk netvsc pmd with MTU of 8k.
Sender sends the packets, receiver receives them.
Test will fail if MTU set fails and/or DPDK crashes.
Test Gbps throughput is annotated into the test result.
Priority:

2

Requirement:

min_count=2

verify_dpdk_build_gb_hugepages_netvsc()
Description:
netvsc pmd version with 1GiB hugepages
This test case checks DPDK can be built and installed correctly.
Prerequisites, accelerated networking must be enabled.
The VM should have at least two network interfaces,
with one interface for management.
More details refer https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk#prerequisites # noqa: E501
Priority:

2

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_symmetric_mp()
Description:
netvsc pmd version.
This test case checks DPDK can be built and installed correctly.
Prerequisites, accelerated networking must be enabled.
The VM should have at least two network interfaces,
with one interface for management.
More details refer https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk#prerequisites # noqa: E501
Priority:

2

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_testpmd_hotplug_receiver_failsafe_pmd()
Description:
test sriov failsafe during vf revoke (receive side)
Priority:

2

Requirement:

supported_features[IsolatedResource]

verify_dpdk_send_receive_gb_hugepages_failsafe()
Description:
Tests a basic sender/receiver setup for default failsafe driver setup.
Sender sends the packets, receiver receives them.
We check both to make sure the received traffic is within the expected
order-of-magnitude.
Test uses 1GB hugepages.
Priority:

2

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_ovs()
Description:
Install and run OVS+DPDK functional tests
Priority:

4

Requirement:

disk

verify_dpdk_build_netvsc()
Description:
netvsc pmd version.
This test case checks DPDK can be built and installed correctly.
Prerequisites, accelerated networking must be enabled.
The VM should have at least two network interfaces,
with one interface for management.
More details refer https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk#prerequisites # noqa: E501
Priority:

2

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_send_receive_gb_hugepages_netvsc()
Description:
Tests a basic sender/receiver setup for direct netvsc pmd setup.
Sender sends the packets, receiver receives them.
We check both to make sure the received traffic is within the expected
order-of-magnitude.
Test uses 1GB hugepages.
Priority:

2

Requirement:

unsupported_features[Gpu, Infiniband]

verify_dpdk_testpmd_hotplug_sender_netvsc_pmd()
Description:
testpmd with hotplug vf for netvsc pmd (send only version)
Priority:

2

Requirement:

supported_features[IsolatedResource]

verify_dpdk_send_receive_multi_txrx_queue_max_mtu_netvsc()
Description:
Tests a basic sender/receiver setup for dpdk netvsc pmd with jumbo frames.
Default is set to request an mtu of 9k, test will skip if it’s not possible.
Sender sends the packets, receiver receives them.
Test checks that traffic flowed, and annotates the Gbps throughput.
Priority:

2

Requirement:

min_count=2

verify_dpdk_nff_go()
Description:
Install and run ci test for NFF-Go on ubuntu
Priority:

4

Requirement:

supported_features[IsolatedResource]

verify_dpdk_vpp()
Description:
verify vpp is able to detect azure network interfaces
1. run fd.io vpp install scripts
2. install vpp from their repositories
3. start vpp service
4. check that azure interfaces are detected by vpp
Priority:

4

Requirement:

unsupported_os[CBLMariner]

verify_dpdk_send_receive_multi_txrx_queue_1500_mtu_netvsc()
Description:
Tests a basic sender/receiver setup for dpdk netvsc pmd with MTU of 1500.
Sender sends the packets, receiver receives them.
Test will fail if MTU set fails and/or DPDK crashes.
Test Gbps throughput is annotated into the test result.
Priority:

2

Requirement:

min_count=2

verify_dpdk_testpmd_multiple_port_receive_netvsc_pmd()
Description:
Run testpmd with multiple senders to a single receiver
using the netvsc pmd. This test checks how the receiver VM
handles a large volume of traffic on multiple ports.
Otherwise it is very similar to the
single sender / single receiver version of the tests.
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

verify_uio_binding()
Description:
UIO basic functionality test.
- Bind interface to uio_hv_generic
- check that sysfs entry is created
- unbind
- check that the driver is unloaded.
- rebind to original driver
Priority:

2

Requirement:

supported_features[IsolatedResource]

class DpdkPerformance
Description:
This test suite is to validate DPDK performance
Platform:

Azure, Ready

Area:

dpdk

Category:

performance

perf_dpdk_multi_queue_failsafe_pmd()
Description:
DPDK Performance: failsafe mode, muliple tx/rx queues
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

perf_dpdk_send_only_netvsc_pmd()
Description:
DPDK Performance: failsafe mode, minimal core count
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

perf_dpdk_minimal_netvsc_pmd()
Description:
DPDK Performance: netvsc mode, minimal core count
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

perf_dpdk_send_only_failsafe_pmd()
Description:
DPDK Performance: failsafe mode, minimal core count
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

perf_dpdk_multi_queue_netvsc_pmd()
Description:
DPDK Performance: direct use of VF, multiple tx/rx queues
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

perf_dpdk_minimal_failsafe_pmd()
Description:
DPDK Performance: failsafe mode, minimal core count
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

perf_dpdk_l3fwd_ntttcp_tcp()
Description:
Run the L3 forwarding perf test for DPDK.
This test creates a DPDK port forwarding setup between
two NICs on the same VM. It forwards packets from a sender on
subnet_a to a receiver on subnet_b. Without l3fwd,
packets will not be able to jump the subnets. This imitates
a network virtual appliance setup, firewall, or other data plane
tool for managing network traffic with DPDK.
Priority:

3

Requirement:

unsupported_features[Gpu, Infiniband]

class OpenSSLTestSuite
Description:
Tests the functionality of OpenSSL, including encryption and decryption
operations. Validates that OpenSSL can successfully encrypt plaintext data
and decrypt it back to its original form using generated keys and IVs.
Validates that OpenSSL signs and verifies signatures correctly.
Platform:

Azure, Ready

Area:

security

Category:

functional

verify_golang_sys_crypto()
Description:
This test will use Go experimental system crypto tests
Priority:

3

Requirement:

supported_os[CBLMariner]

verify_openssl_basic()
Description:
Verifies basic OpenSSL encryption and decryption behavior by generating
a random key and IV, encrypting various types of plaintext, and
decrypting them back to their original form.
Priority:

2

verify_openssl_speed_test()
Description:
This test will first Run OpenSSL speed test
that measures the performance of cryptographic
functions. The parameter sec is set to 1 second
to ensure that the test runs for a short duration
and test avoids timeout.
Priority:

2

class FipsTests
Description:
Tests the functionality of FIPS enable
Platform:

Azure, Ready

Area:

security

Category:

functional

verify_fips_enablement()
Description:
This test case will
1. Check whether FIPS is currently enabled on the VM.
2. Switch FIPS mode (enabled-to-disabled or disabled-to-enabled).
3. Restart the VM for the changes to take effect.
4. Verify that FIPS was switched properly.
5. Revert the FIPS mode to its original state.
6. Restart the VM for the changes to take effect.
7. Verify that FIPS was reverted properly.
Note that for some platforms, we will only enable fips if it is disabled,
and then only if we have the proper tool to do so.
Priority:

2

Requirement:

supported_os[CBLMariner, Ubuntu]

verify_azl_fips_status()
Description:
Ensures that an AZL machine is in the correct FIPS mode.
Priority:

3

Requirement:

supported_os[CBLMariner]

class DmCacheTestSuite
Description:
This test suite validates dm-cache functionality using LVM on Azure VMs.
It sets up a dm-cache configuration to verify that caching is functional
and provides performance benefits.
Platform:

Azure, Ready

Area:

dmcache

Category:

functional

verify_dm_cache_setup()
Description:
This test verifies dm-cache functionality by:
1. Creating loopback devices to simulate slow origin and fast cache disks
2. Setting up LVM physical volumes and volume groups
3. Creating logical volumes for origin and cache pool
4. Attaching cache pool to origin LV to enable caching
5. Formatting and mounting the cached logical volume
6. Verifying the dm-cache setup is working correctly
Priority:

2

Requirement:

supported_os[CBLMariner]

class StorageTest
Description:
This test suite is to validate storage function in Linux VM.
Platform:

Azure, Ready

Area:

storage

Category:

functional

verify_disk_with_nobarrier()
Description:
This test case is to
1. Make raid0 based on StandardHDDLRS disks.
2. Mount raid0 with nobarrier options.
Priority:

3

Requirement:

unsupported_os[Windows, BSD]

verify_disk_with_fio_verify_option()
Description:
This test case is to
1. Attach 2 512GB premium SSD disks
2. Create a 100GB partition for each disk using fdisk
3. Create a RAID type 1 device using partitions created in step 2
4. Run fio against raid0 with verify option for 100 times
Priority:

1

Requirement:

unsupported_os[Windows, BSD]

class Nested
Description:
This test suite is used to run nested vm related tests.
Platform:

Azure, Ready

Area:

nested

Category:

functional

verify_nested_kvm_basic()
Description:
This test case will run basic tests on provisioned L2 vm.
Steps:
1. Create L2 VM with Qemu.
2. Verify that files can be copied from L1 VM to L2 VM.
3. Verify that files from internet can be downloaded to L2 VM.
Priority:

1

Requirement:

supported_features[NestedVirtualization]

class HyperVDynamicMemory
Description:
Validates Hyper-V dynamic memory behaviour on Linux guests
Platform:

Azure, Ready

Area:

hyperv

Category:

functional

verify_dynamic_memory_hot_add()
Description:
Validates that with dynamic memory enabled, VM memory stress triggers hot add and increases assigned memory above the Startup Memory, while keeping host and guest memory aligned.
Priority:

3

verify_dynamic_memory_balloon_down()
Description:
Validates balloon down behavior: applying VM memory stress deflates the balloon and increases the VM’s assigned memory from the level before stress, while keeping host and guest memory usage aligned.
Priority:

3

verify_dynamic_memory_upper_limit()
Description:
Validates that dynamic memory increases assigned memory up to the configured maximum limit when the VM is under memory stress, while keeping host and guest memory usage aligned.
Priority:

3

verify_dynamic_memory_balloon_up()
Description:
Validates that when the host is under memory pressure, the Hyper-V balloon driver inflates and reduces the VM’s assigned memory while keeping host and guest memory usage aligned.
Priority:

3

verify_dynamic_memory_lower_limit()
Description:
Validates that, under host memory pressure, dynamic memory reduces the VM’s assigned memory down to the configured minimum limit when ballooning is enabled.
Priority:

3

verify_dynamic_memory_balloon_down_hugepages()
Description:
Validates balloon down with huge pages: mmaphuge stress deflates the balloon and raises assigned memory, with AnonHugePages increasing and keeping host and guest memory usage aligned.
Priority:

3

verify_dynamic_memory_hot_add_hugepages()
Description:
Validates under huge page (mmaphuge) stress, dynamic memory increases assigned memory and AnonHugePages rises accordingly, keeping host and guest memory usage aligned.
Priority:

3

verify_dynamic_memory_upper_limit_hugepages()
Description:
Validates that under huge page (mmaphuge) stress, dynamic memory increases the VM’s assigned memory up to the configured Maximum limit, while keeping host and guest memory usage aligned.
Priority:

3

class DevicePassthroughFunctionalTests
Description:
This test suite is for testing device passthrough functional tests.
Platform:

Azure, Ready

Area:

device_passthrough

Category:

functional

verify_device_passthrough_on_guest()
Description:
Check if passthrough device is visible to guest.
This testcase supports the CLOUD_HYPERVISOR and HYPERV platforms
of LISA. Please refer below runbook snippet.
platform:
- type: cloud-hypervisor
cloud-hypervisor:
device_pools:
- type: “pci_net”
devices:
- vendor_id: xxx
device_id: xxx
requirement:
cloud-hypervisor:
device_passthrough:
- pool_type: “pci_net”
managed: “yes”
count: 1
We will check if sufficient devices are visible to guest or not.
Platform will create device pool based on given device/vendor id.
‘device_passthrough’ section will tell platform to create node
with appropriate num of devices being passthrough. Based on pool_type
value, platform will try to get devices from pool and assign it to node.
Testcase will verify if needed devices are present on node by reading
the runtime passthrough device context. It will resolve vendor/device
ids for assigned host devices and check how many matching devices are
present on the guest.
Priority:

4

Requirement:

supported_platform_type

class LwtunnelSuite
Description:
Validates LWTUNNEL (Lightweight Tunnel) functionality including
route-based encapsulation for BPF, SEG6, and other tunnel types.
Platform:

Azure, Ready

Area:

network

Category:

functional

verify_lwtunnel_bpf_support()
Description:
Verifies BPF-based lightweight tunnel support by:
1. Checking kernel configs are enabled
2. Compiling and loading a minimal BPF program
3. Attaching it to a route as lwtunnel encap
4. Verifying the route is created with BPF encap
Priority:

3

class XfrmSuite
Description:
This test suite validates XFRM (IPsec) interface functionality.
XFRM interfaces are used for IPsec VPN tunnels and are essential
for secure network communications.
Platform:

Azure, Ready

Area:

network

Category:

functional

verify_xfrm_interface_load_unload()
Description:
This test case verifies that the xfrm_interface kernel module
can be loaded and unloaded without issues.
Steps:
1. Check if CONFIG_XFRM_INTERFACE is enabled and not built-in.
2. Unload the xfrm_interface module if loaded.
3. Load the xfrm_interface module.
4. Verify the module is loaded.
5. Unload the module.
6. Verify the module is unloaded.
Priority:

3

verify_xfrm_interface()
Description:
This test case verifies that the xfrm_interface kernel module
can be loaded and provides the expected functionality.
Steps:
1. Check if CONFIG_XFRM_INTERFACE is enabled in kernel config.
2. Load the xfrm_interface module if not already loaded.
3. Verify the module is loaded successfully.
4. Create a test xfrm interface (xfrm0).
5. Verify the interface was created.
6. Clean up the test interface.
Priority:

2

class Sriov
Description:
This test suite uses to verify accelerated network functionality.
Platform:

Azure, Ready

Area:

sriov

Category:

functional

verify_sriov_basic()
Description:
This case verifies module of sriov network interface is loaded and each
synthetic nic is paired with one VF.
Steps,
1. Check VF of synthetic nic is paired.
2. Check module of sriov network device is loaded.
3. Check VF counts listed from lspci is expected.
Priority:

1

Requirement:

network_interface

verify_sriov_single_vf_connection_max_cpu()
Description:
This case needs 2 nodes and 64 Vcpus. And it verifies module of sriov network
interface is loaded and each synthetic nic is paired with one VF, and check
rx statistics of source and tx statistics of dest increase after send 200 Mb
file from source to dest.
Steps,
1. Check VF of synthetic nic is paired.
2. Check module of sriov network device is loaded.
3. Check VF counts listed from lspci is expected.
4. Setup SSH connection between source and dest with key authentication.
5. Ping the dest IP from the source machine to check connectivity.
6. Generate 200Mb file, copy from source to dest.
7. Check rx statistics of source VF and tx statistics of dest VF is increased.
Priority:

2

Requirement:

network_interface

verify_sriov_disable_enable_on_guest()
Description:
This case verify VM works well after down the VF nic and up VF nic inside VM.
Steps,
1. Do the basic sriov check.
2. Do network connection test with bring down the VF nic.
3. After copy 200Mb file from source to desc.
4. Check rx statistics of source synthetic nic and tx statistics of dest
synthetic nic is increased.
5. Bring up VF nic.
Priority:

2

Requirement:

network_interface

verify_sriov_provision_with_max_nics_reboot_from_platform()
Description:
This case verify VM works well when provisioning with max sriov nics.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
3. Reboot VM from API.
4. Do the basic sriov testing.
Priority:

2

Requirement:

network_interface

verify_sriov_max_vf_connection_max_cpu()
Description:
This case needs 2 nodes, max nics and 64 Vcpus. And it verifies module of sriov
network interface is loaded and each synthetic nic is paired with one VF, and
check rx statistics of source and tx statistics of dest increase after send 200
Mb file from source to dest.
Steps,
1. Check VF of synthetic nic is paired.
2. Check module of sriov network device is loaded.
3. Check VF counts listed from lspci is expected.
4. Setup SSH connection between source and dest with key authentication.
5. Ping the dest IP from the source machine to check connectivity.
6. Generate 200Mb file, copy from source to dest.
7. Check rx statistics of source VF and tx statistics of dest VF is increased.
Priority:

2

Requirement:

network_interface

verify_sriov_disable_enable()
Description:
This case verify VM works well after disable and enable accelerated network in
network interface through sdk.
Steps,
1. Do the basic sriov check.
2. Set enable_accelerated_networking as False to disable sriov.
3. Set enable_accelerated_networking as True to enable sriov.
4. Do the basic sriov check.
5. Do step 2 ~ step 4 for 2 times.
Priority:

1

Requirement:

supported_platform_type[AZURE, HYPERV]

verify_sriov_ethtool_offload_setting()
Description:
This case verify below two kernel patches.
1. hv_netvsc: Sync offloading features to VF NIC
https://github.com/torvalds/linux/commit/68622d071e555e1528f3e7807f30f73311c1acae#diff-007213ba7199932efdb096be47d209a2f83e4d425c486b3adaba861d0a0c80c5 # noqa: E501
2. hv_netvsc: Allow scatter-gather feature to be tunable
https://github.com/torvalds/linux/commit/b441f79532ec13dc82d05c55badc4da1f62a6141#diff-007213ba7199932efdb096be47d209a2f83e4d425c486b3adaba861d0a0c80c5 # noqa: E501
Steps,
1. Change scatter-gather feature on synthetic nic,
verify the the feature status sync to the VF dynamically.
2. Disable and enable sriov,
check the scatter-gather feature status keep consistent in VF.
Priority:

2

Requirement:

unsupported_os[BSD, Windows]

verify_sriov_add_max_nics()
Description:
This case verify VM works well after attached the max sriov nics after
provision.
Steps,
1. Attach 7 extra sriov nic into the VM.
2. Do the basic sriov testing.
Priority:

2

Requirement:

network_interface

verify_sriov_disable_enable_pci()
Description:
This case verify VM works well after disable and enable PCI device inside VM.
Steps,
1. Disable sriov PCI device inside the VM.
2. Enable sriov PCI device inside the VM.
3. Do the basic sriov check.
4. Do VF connection test.
Priority:

2

Requirement:

network_interface

verify_sriov_single_vf_connection()
Description:
This case verifies module of sriov network interface is loaded and
each synthetic nic is paired with one VF, and check rx statistics of source
and tx statistics of dest increase after send 200 Mb file from source to dest.
Steps,
1. Check VF of synthetic nic is paired.
2. Check module of sriov network device is loaded.
3. Check VF counts listed from lspci is expected.
4. Setup SSH connection between source and dest with key authentication.
5. Ping the dest IP from the source machine to check connectivity.
6. Generate 200Mb file, copy from source to dest.
7. Check rx statistics of source VF and tx statistics of dest VF is increased.
Priority:

1

Requirement:

network_interface

verify_sriov_reload_modules()
Description:
This case verify VM works well during remove and load sriov modules.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
3. Remove sriov module, check network traffic through synthetic nic.
4. Load sriov module, check network traffic through VF.
Priority:

1

Requirement:

network_interface

verify_sriov_provision_with_max_nics()
Description:
This case verify VM works well when provisioning with max sriov nics.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
Priority:

2

Requirement:

network_interface

verify_irqbalance()
Description:
This test case verifies that irq rebalance is running.
When irqbalance is in debug mode, it will log “Selecting irq xxx for
rebalancing” when it selects an irq for rebalancing. We expect to see
this irq rebalancing when VM is under heavy network load.
An issue was previously seen in irqbalance 1.8.0-1build1 on Ubuntu.
When IRQ rebalance is not running, we expect to see poor network
performance and high package loss. Contact the distro publisher if
this is the case.
Steps,
1. Stop irqbalance service.
2. Start irqbalance as a background process with debug mode.
3. Generate some network traffic.
4. Check irqbalance output for “Selecting irq xxx for rebalancing”.
Priority:

2

Requirement:

network_interface

verify_sriov_max_vf_connection()
Description:
This case needs 2 nodes and max nics. And it verifies module of sriov network
interface is loaded and each synthetic nic is paired with one VF, and check
rx statistics of source and tx statistics of dest increase after send 200 Mb
file from source to dest.
Steps,
1. Check VF of synthetic nic is paired.
2. Check module of sriov network device is loaded.
3. Check VF counts listed from lspci is expected.
4. Setup SSH connection between source and dest with key authentication.
5. Ping the dest IP from the source machine to check connectivity.
6. Generate 200Mb file, copy from source to dest.
7. Check rx statistics of source VF and tx statistics of dest VF is increased.
Priority:

2

Requirement:

network_interface

verify_sriov_provision_with_max_nics_reboot()
Description:
This case verify VM works well when provisioning with max sriov nics.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
3. Reboot VM from guest.
4. Do the basic sriov testing.
Priority:

2

Requirement:

network_interface

verify_services_state()
Description:
This case verifies all services state with Sriov enabled.
Steps,
1. Get overrall state from systemctl status, if no systemctl command,
skip the testing
2. The expected state should be running
Priority:

1

Requirement:

network_interface

verify_sriov_interrupts_change()
Description:
This case is to verify interrupts count increased after network traffic
went through the VF, if CPU is less than 8, it can’t verify the interrupts
spread to CPU evenly, when CPU is more than 16, the traffic is too light to
make sure interrupts distribute to every CPU.
Steps,
1. Start iperf3 on server node.
2. Get initial interrupts sum per irq and cpu number on client node.
3. Start iperf3 for 120 seconds with 128 threads on client node.
4. Get final interrupts sum per irq number on client node.
5. Compare interrupts changes, expected to see interrupts increased.
6. Get final interrupts sum per cpu on client node.
7. Collect cpus which don’t have interrupts count increased.
8. Compare interrupts count changes, expected half of cpus’ interrupts
increased.
Priority:

2

Requirement:

node

verify_sriov_provision_with_max_nics_stop_start_from_platform()
Description:
This case verify VM works well when provisioning with max sriov nics.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
3. Stop and Start VM from API.
4. Do the basic sriov testing.
Priority:

2

Requirement:

network_interface

class Synthetic
Description:
This test suite uses to verify synthetic network functionality.
Platform:

Azure, Ready

Area:

network

Category:

functional

verify_synthetic_add_max_nics_one_time_after_provision()
Description:
This case verify VM works well after attaching 7 extra synthetic nics
in one time.
Steps,
1. Provision VM with 1 network interface with synthetic network.
2. Add 7 extra network interfaces in one time.
3. Check each nic has an ip address.
Priority:

2

Requirement:

network_interface

verify_synthetic_provision_with_max_nics_reboot()
Description:
This case verify VM works well when provison with max synthetic nics.
Steps,
1. Provision VM with max network interfaces with synthetic network.
2. Check each nic has an ip address.
3. Reboot VM from guest.
4. Check each nic has an ip address.
Priority:

2

Requirement:

network_interface

verify_synthetic_provision_with_max_nics_stop_start_from_platform()
Description:
This case verify VM works well when provison with max synthetic nics.
Steps,
1. Provision VM with max network interfaces with synthetic network.
2. Check each nic has an ip address.
3. Stop and Start VM from API.
4. Check each nic has an ip address.
Priority:

2

Requirement:

network_interface

verify_synthetic_provision_with_max_nics()
Description:
This case verify VM works well when provison with max synthetic nics.
Steps,
1. Provision VM with max network interfaces with synthetic network.
2. Check each nic has an ip address.
Priority:

2

Requirement:

network_interface

verify_synthetic_provision_with_max_nics_reboot_from_platform()
Description:
This case verify VM works well when provison with max synthetic nics.
Steps,
1. Provision VM with max network interfaces with synthetic network.
2. Check each nic has an ip address.
3. Reboot VM from API.
4. Check each nic has an ip address.
Priority:

2

Requirement:

network_interface

verify_synthetic_add_max_nics_one_by_one_after_provision()
Description:
This case verify VM works well after attaching 7 extra synthetic nics
one by one.
Steps,
1. Provision VM with 1 network interface with synthetic network.
2. Add 7 extra network interfaces one by one.
3. Check each nic has an ip address.
Priority:

2

Requirement:

network_interface

class NetworkSettings
Description:
This test suite runs the ethtool related network test cases.
Platform:

Azure, Ready

Area:

network

Category:

functional

verify_device_statistics()
Description:
This test case requires 4 or more cpu cores, so as to validate
among 4 or more channels(queues), no particular queue is continuously
starving(not sending/receiving any packets).
Steps:
1. Get all the device’s statistics.
2. Validate device statistics lists per queue statistics as well.
3. Run traffic using iperf3 and check stats for each device.
4. if the same queue (say queue #0) is inactive repeatitively,
and the count of channels is >= 4 (total #queues), test should fail
and require further investigation.
Priority:

2

Requirement:

min_core_count=4

verify_device_rss_hash_key_change()
Description:
This test case verifies changing device’s RSS hash key takes
into affect.
Steps:
1. Skip the test if the kernel version is any less than LTS 5.
2. Get all the device’s RSS hash key values.
3. Swap the last 2 characters of original hash key to make a new hash key.
4. Validate changing the hash key setting using the new hash key.
5. Revert back the settings to original values.
Priority:

2

Requirement:

unsupported_os[BSD, Windows]

verify_device_gro_lro_settings_change()
Description:
This test case verifies changing device’s GRO and LRO setting takes
into affect.
Steps:
1. Get all the device’s generic-receive-offload and large-receive-offload
settings.
2. If both GRO and LRO settings are “[fixed]” then skip testing specific
device.
3. Try flipping the GRO and LRO settings and validate it takes affect.
4. Revert back the settings to original values.
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_ringbuffer_settings_change()
Description:
This test case verifies if ring buffer settings can be changed with ethtool.
Steps:
1. Get the current ring buffer settings.
2. Change the rx and tx value to new_values using ethtool.
3. Get the settings again and validate the current rx and tx
values are equal to the new_values assigned.
4. Revert back the rx and tx value to their original values.
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_device_rx_hash_level_change()
Description:
This test case verifies whether changing device’s RX hash level
for tcp and udp takes into affect.
Steps:
Note: Same steps are used for both TCP and UDP.
1. Get all the device’s RX hash level status.
2. Depending on current setting, change to enabled/disabled.
3. Validate changing the hash level setting.
4. Revert back the settings to original values.
Priority:

2

verify_device_msg_level_change()
Description:
This test case verifies whether setting/unsetting device’s
message level flag takes into affect.
Steps:
1. Verify Get/Set message level supported on kernel version.
2. Get all the device’s message level number and name setting.
2. Depending on current setting, set/unset a message flag by number
and name.
3. Validate changing the message level flag setting.
4. Revert back the setting to original value.
Note: BSD does not support the feature tested here and
lacks the hv_netvsc module used to support it.
Priority:

2

Requirement:

unsupported_os[BSD, Windows]

verify_device_channels_change()
Description:
This test case verifies changing device channels count with ethtool.
Steps:
1. Get the current device channels info.
2 a. Keep Changing the channel count from min to max value using ethtool.
b. Get the channel count info and validate the channel count
value is equal to the new value assigned.
3. Revert back the channel count to its original value.
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_device_enabled_features()
Description:
This test case verifies required device features are enabled.
Steps:
1. Get the device’s enabled features.
2. Validate below features are in the list of enabled features-
rx-checksumming
tx-checksumming
tcp-segmentation-offload
scatter-gather
Priority:

1

class InetDiagSuite
Description:
This test suite validates INET_DIAG functionality, particularly
the INET_DIAG_DESTROY feature which allows administrative termination
of TCP connections via netlink socket interface. This is useful for
forcefully closing stuck connections or cleaning up resources.
Platform:

Azure, Ready

Area:

network

Category:

functional

verify_inet_diag_destroy()
Description:
This test case verifies that the INET_DIAG_DESTROY kernel feature
works correctly by creating a TCP connection and then destroying it
using the ss (socket statistics) command.
Steps:
1. Check if CONFIG_INET_DIAG_DESTROY is enabled in kernel config.
2. Create an established TCP connection using Python sockets.
3. Verify the connection exists using ss command.
4. Destroy the connection using ‘ss -K’ (kill socket).
5. Verify the connection was destroyed (no longer visible).
6. Clean up any remaining connections.
Priority:

2

verify_inet_diag_enabled()
Description:
This test case verifies that CONFIG_INET_DIAG is enabled in the kernel,
which is required for socket diagnostic functionality. INET_DIAG
provides
the interface for tools like ss to query socket information.
Steps:
1. Check if CONFIG_INET_DIAG is enabled in kernel config.
2. Verify ss command is available and functional.
3. Test basic ss functionality by listing sockets.
Priority:

3

class CongestionControlSuite
Description:
This test suite validates TCP congestion control behavior.
Current coverage focuses on BBR3-specific functionality
(only for kernels that are built with BBR3 support).
Platform:

Azure, Ready

Area:

network

Category:

functional

verify_bbr3_applies_to_live_tcp_flow()
Description:
This test case verifies the BBR3 algorithm remains stable on a live TCP flow.
Steps:
1. Verify BBR3 is available.
2. Set TCP congestion control to BBR3.
3. Create a TCP connection and verify it reaches ESTAB.
4. Validate the connection remains established.
5. Restore the original algorithm and cleanup.
Priority:

2

verify_bbr3_kernel_config_runtime_consistency()
Description:
This test case verifies BBR3 kernel config and runtime state are consistent
as part of congestion-control validation.
Steps:
1. Check if BBR3 is enabled in kernel config.
2. Verify BBR3 appears in runtime available algorithms.
Priority:

3

verify_bbr3_set_and_restore()
Description:
This test case verifies the BBR3 algorithm can be selected and restored.
Steps:
1. Verify BBR3 is available.
2. Save the current TCP congestion control algorithm.
3. Set TCP congestion control to BBR3.
4. Verify BBR3 is active.
5. Restore the original algorithm.
Priority:

2

verify_bbr3_available()
Description:
This test case verifies the BBR3 algorithm appears in available
TCP congestion control algorithms.
Steps:
1. Read available TCP congestion control algorithms.
2. Verify BBR3 is listed.
Priority:

3

class NetInterface
Description:
This test suite validates basic functionalities of Network Interfaces.
Platform:

Azure, Ready

Area:

network

Category:

functional

validate_netvsc_reload()
Description:
This test case verifies if synthetic network module - netvsc
can be reloaded gracefully when done multiple times.
Steps:
1. Validate netvsc isn’t built-in already. If it is then skip the test.
2. Unload and load netvsc module multiple times in a loop.
Priority:

1

Requirement:

network_interface

class Stress
Description:
This test suite uses to verify accelerated network functionality under stress.
Platform:

Azure, Ready

Area:

sriov

Category:

stress

stress_sriov_disable_enable()
Description:
This case verify VM works well after disable and enable accelerated network in
network interface through sdk under stress.
It is a regression test case to check the bug
https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-azure/+git/
bionic/commit/id=16a3c750a78d8, which misses the second hunk of the upstream
patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=877b911a5ba0. Details please check https://bugs.launchpad.net/
ubuntu/+source/linux-azure/+bug/1965618
Steps,
1. Do the basic sriov check.
2. Set enable_accelerated_networking as False to disable sriov.
3. Set enable_accelerated_networking as True to enable sriov.
4. Do the basic sriov check.
5. Do step 2 ~ step 4 for 25 times.
Priority:

3

Requirement:

supported_platform_type[AZURE]

stress_sriov_with_max_nics_stop_start_from_platform()
Description:
This case verify VM works well when provisioning with max sriov nics.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
3. Stop and Start VM from API.
4. Do the basic sriov testing.
5. Repeat step 3 and 4 for 10 times.
Priority:

2

Requirement:

network_interface

stress_synthetic_with_max_nics_reboot_from_platform()
Description:
This case verify VM works well when provison with max synthetic nics.
Steps,
1. Provision VM with max network interfaces with synthetic network.
2. Check each nic has an ip address.
3. Reboot VM from API.
4. Check each nic has an ip address.
5. Repeat step 3 and 4 for 10 times.
Priority:

2

Requirement:

network_interface

stress_sriov_with_max_nics_reboot()
Description:
This case verify VM works well when provisioning with max sriov nics.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
3. Reboot VM from guest.
4. Do the basic sriov testing.
5. Repeat step 3 and 4 for 10 times.
Priority:

2

Requirement:

network_interface

stress_sriov_with_max_nics_reboot_from_platform()
Description:
This case verify VM works well when provisioning with max sriov nics.
Steps,
1. Provision VM with max network interfaces with enabling accelerated network.
2. Do the basic sriov testing.
3. Reboot VM from API.
4. Do the basic sriov testing.
5. Repeat step 3 and 4 for 10 times.
Priority:

2

Requirement:

network_interface

stress_synthetic_provision_with_max_nics_reboot()
Description:
This case verify VM works well when provison with max synthetic nics.
Steps,
1. Provision VM with max network interfaces with synthetic network.
2. Check each nic has an ip address.
3. Reboot VM from guest.
4. Check each nic has an ip address.
5. Repeat step 3 and 4 for 10 times.
Priority:

2

Requirement:

network_interface

stress_synthetic_with_max_nics_stop_start_from_platform()
Description:
This case verify VM works well when provison with max synthetic nics.
Steps,
1. Provision VM with max network interfaces with synthetic network.
2. Check each nic has an ip address.
3. Stop and Start VM from API.
4. Check each nic has an ip address.
5. Repeat step 3 and 4 for 10 times.
Priority:

2

Requirement:

network_interface

stress_sriov_iperf()
Description:
This case is to check whether the network connectivity is lost after running
iperf3 for 30 mins.
Steps,
1. Start iperf3 on server node.
2. Start iperf3 for 30 minutes on client node.
3. Do VF connection test.
Priority:

4

Requirement:

node

class Power
Description:
This test suite is to test hibernation in guest VM.
Platform:

Azure, Ready

Area:

power

Category:

functional

verify_hibernation_sriov_network_max_nics()
Description:
This case is to verify vm hibernation with sriov network with max nics.
It has the same steps with verify_hibernation_synthetic_network_max_nics.
Priority:

3

Requirement:

supported_features

verify_hibernation_max_data_disks()
Description:
This case is to verify vm hibernation with max data disks.
It has the same steps with verify_hibernation_synthetic_network_max_nics.
Priority:

3

Requirement:

disk

verify_hibernation_synthetic_network()
Description:
This case is to verify vm hibernation with synthetic network.
Steps,
1. Install HibernationSetup tool to prepare prerequisite for vm
hibernation.
2. Get nics info before hibernation.
3. Hibernate vm.
4. Check vm is inaccessible.
5. Resume vm by starting vm.
6. Check vm hibernation successfully by checking keywords in dmesg.
6. Get nics info after hibernation.
7. Fail the case if nics count and info changes after vm resume.
Priority:

3

Requirement:

supported_features

verify_hibernation_time_sync()
Description:
This case is to verify vm time sync working after hibernation.
Steps,
1. Reset time using hwclock as 1 year after current date.
2. Hibernate and resume vm.
3. Check vm time sync correctly.
Priority:

3

Requirement:

supported_features

verify_hibernation_with_network_workload()
Description:
This case is to verify hibernation with network workload.
Steps,
1. Run iperf3 network benchmark, make sure no issues.
2. Hibernate and resume vm.
3. Run iperf3 network benchmark, make sure no issues.
Priority:

3

Requirement:

supported_features

verify_hibernation_with_storage_workload()
Description:
This case is to verify hibernation with storage workload.
Steps,
1. Run fio benchmark, make sure no issues.
2. Hibernate and resume vm.
3. Run fio benchmark, make sure no issues.
Priority:

3

Requirement:

supported_features

verify_hibernation_with_vm_extension()
Description:
This case is to verify vm hibernation using LinuxHibernateExtension.
Steps,
1. Install LinuxHibernateExtension to prepare prerequisite for vm
hibernation.
2. Get nics info before hibernation.
3. Hibernate vm using Stop-Hibernate.
4. Check vm is inaccessible (deallocated status).
5. Resume vm by starting vm.
6. Check vm hibernation successfully by verifying boot time consistency.
7. Get nics info after hibernation.
8. Fail the case if nics count and info changes after vm resume.
9. Uninstall the extension.
Priority:

2

Requirement:

supported_features[AzureExtension]

verify_hibernation_sriov_network()
Description:
This case is to verify vm hibernation with sriov network.
It has the same steps with verify_hibernation_synthetic_network.
Priority:

3

Requirement:

supported_features

verify_hibernation_with_memory_workload()
Description:
This case is to verify hibernation with memory workload.
Steps,
1. Run stress-ng benchmark, make sure no issues.
2. Hibernate and resume vm.
3. Run stress-ng benchmark, make sure no issues.
Priority:

3

Requirement:

supported_features

verify_hibernation_synthetic_network_max_nics()
Description:
This case is to verify vm hibernation with synthetic network with max nics.
Steps,
1. Install HibernationSetup tool to prepare prerequisite for vm
hibernation.
2. Get nics info before hibernation.
3. Hibernate vm.
4. Check vm is inaccessible.
5. Resume vm by starting vm.
6. Check vm hibernation successfully by checking keywords in dmesg.
6. Get nics info after hibernation.
7. Fail the case if nics count and info changes after vm resume.
Priority:

3

Requirement:

supported_features

class PowerStress
Description:
This test suite is to test hibernation in guest vm under stress.
Platform:

Azure, Ready

Area:

power

Category:

stress

stress_hibernation()
Description:
This case is to verify vm hibernation in a loop.
Priority:

3

Requirement:

supported_features

class RustVmmTestSuite
Description:
This test suite is for executing the rust-vmm/mshv tests
Platform:

Azure, Ready

Area:

rust-vmm

Category:

community

verify_rust_vmm_mshv_tests()
Description:
Runs rust-vmm/mshv tests
Priority:

3

class OpenVmmPlatformSuite
Description:
This test suite validates OpenVMM guests running on a prepared L1 host.
Platform:

Azure, Ready

Area:

openvmm

Category:

functional

verify_openvmm_restart_via_platform()
Description:
This case validates that platform restart keeps the OpenVMM guest
reachable after the restart.
Priority:

5

Requirement:

supported_features[StartStop]

verify_openvmm_stop_start_in_platform()
Description:
This case validates that platform stop/start keeps the OpenVMM guest
reachable for subsequent command execution.
Priority:

5

Requirement:

supported_features[StartStop]

verify_openvmm_guest_boot()
Description:
This case validates that an OpenVMM guest is reachable over SSH and that
the guest booted successfully.
Priority:

5

Requirement:

EnvironmentStatus.Deployed

class OpenVmmUpstreamTestSuite
Description:
This suite runs the upstream OpenVMM vmm_tests from the Linux OpenVMM host.
Platform:

Azure, Ready

Area:

openvmm

Category:

community

verify_openvmm_upstream_vmm_tests()
Description:
Run the upstream OpenVMM vmm_tests flowey pipeline on the Linux x64 host.
Use openvmm_vmm_tests_guest_os=linux|windows|all to scope guest coverage,
and openvmm_vmm_tests_filter for any additional nextest filter expression.
Native Linux hosts automatically exclude PCAT coverage because upstream
PCAT firmware discovery depends on Windows or WSL-hosted firmware paths.
Priority:

2

Requirement:

supported_os[CBLMariner]

OSU Bench
Description:
This test suite runs the OSU Micro-Benchmarks MPI test cases.
Platform:

Azure, Ready

Area:

hpc

Category:

performance

perf_mpi_operations()
Description:
This test case runs GPU/CPU MPI latency.
Steps:
1. Install MVAPICH;
2. Install OSU Micro-Benchmarks;
3. Run GPU/CPU collective/latency tests in a single node.
Priority:

2

Requirement:

supported_features[SerialConsole]

class KdumpCrash
Description:
This test suite is used to verify if kernel crash dump is effect, which is judged
through vmcore file is generated after triggering kdump by sysrq.
It has 7 test cases. They verify if kdump is effect when:
1. VM has 1 cpu
2. VM has 2-8 cpus and trigger kdump on cpu 1
3. VM has 33-192 cpus and trigger kdump on cpu 32
4. VM has 193-415 cpus and trigger kdump on cpu 192
5. VM has more than 415 cpus and trigger kdump on cpu 415
6. crashkernel is set “auto”
7. crashkernel is set “auto” and VM has more than 2T memory
Platform:

Azure, Ready

Area:

kdump

Category:

functional

verify_kdumpcrash_smp()
Description:
This test case verifies if the kdump is effect when VM has 2~8 cpus, and
trigger kdump on the second cpu(cpu1), which is designed by a known issue.
The test steps are same as kdumpcrash_validate_single_core.
Priority:

2

Requirement:

node

verify_kdumpcrash_auto_size()
Description:
This test case verifies if the kdump is effect when crashkernel is set auto.
The test steps are same as kdumpcrash_validate_single_core.
Priority:

3

verify_kdumpcrash_single_core()
Description:
This test case verifies if kdump is effect when VM has 1 cpu.
VM need 2G memory at least to make sure it has enough memory to load crash
kernel.
Steps:
1. Check if vmbus version and kernel configurations support for crash dump.
2. Specify the memory reserved for crash kernel in kernel cmdline, setting the
“crashkernel” option to the required value.
a. Modify the grub config file to add crashkernel option or change the
value to the required one. (For Redhat 8, no need to modify grub config
file. It can specify crashkernel by using grubby command directly)
b. Update grub config
4. If needed, config the dump path.
3. Reboot system to make kdump effect.
4. Check if the crash kernel is loaded.
a. Check if kernel cmdline has crashkernel option and the value is expected
b. Check if /sys/kernel/kexec_crash_loaded file exists and the value is ‘1’
c. Check if /proc/iomem is reserved memory for crash kernel
5. Trigger kdump through ‘echo c > /proc/sysrq-trigger’, or trigger on
specified CPU by using command “taskset -c”.
6. Check if vmcore is generated under the dump path we configure after system
boot up.
Priority:

2

Requirement:

node

verify_kdumpcrash_large_memory_auto_size()
Description:
This test case verifies if the kdump is effect when crashkernel is set auto and
the memory is more than 2T. With the crashkernel=auto parameter, system will
reserved a suitable size memory for crash kernel. We want to see if the
crashkernel=auto can also handle this scenario when the system memory is large.
The test steps are same as kdumpcrash_validate_single_core.
Priority:

3

Requirement:

node

verify_kdumpcrash_on_cpu415()
Description:
This test case verifies if the kdump is effect when VM has more than 415 cpus,
and trigger kdump on the 416th cpu(cpu415), which is designed by a known issue.
The test steps are same as kdumpcrash_validate_single_core.
Priority:

4

Requirement:

node

verify_kdumpcrash_on_cpu192()
Description:
This test case verifies if the kdump is effect when VM has 193~415 cpus, and
trigger kdump on the 193th cpu(cpu192), which is designed by a known issue.
The test steps are same as kdumpcrash_validate_single_core.
Priority:

2

Requirement:

node

verify_kdumpcrash_on_random_cpu()
Description:
This test case verifies if the kdump is effect when VM has any cores, and
trigger kdump on the random cpu.
The test steps are same as kdumpcrash_validate_single_core.
Priority:

1

verify_kdumpcrash_on_cpu32()
Description:
This test case verifies if the kdump is effect when VM has 33~192 cpus and
trigger kdump on the 33th cpu(cpu32), which is designed by a known issue.
The test steps are same as kdumpcrash_validate_single_core.
Priority:

2

Requirement:

node

class FirewalldSuite
Description:
This test suite validates firewalld.
It is a collection of tests which run against
a local firewalld installation.
It runs isolated inside temporary network namespaces.
These tests interact with both iptables & nftables as backend.
The testsuite is provided by the firewalld-test rpm.
Platform:

Azure, Ready

Area:

firewalld

Category:

functional

verify_firewalld()
Description:
This test case runs the complete testsuite.
The set of tests include
1. cli: firewall-cmd client tests
2. dbus: dbus interface tests
3. python: python binding tests
4. features: firewalld daemon functional tests
5. regressions: regression tests
Priority:

3

class LtpTestsuite
Description:
This test suite is used to run Ltp related tests.
Platform:

Azure, Ready

Area:

ltp

Category:

community

verify_ltp_full()
Description:
This test case will run Ltp Full tests.
1. When ltp_source_file (downloaded ltp code) is specified in .yml,
case will use it to extract the tar and run ltp, instead of downloading runtime.
Example:
- name: ltp_source_file
value: <path_to_ltp.tar.xz>
is_case_visible: true
2. When ltp_source_file not in .yml, clone github with ltp_tests_git_tag
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

verify_ltp_lite()
Description:
This test case will run Ltp lite tests in following priority sequence:
1. When ltp_binary_file (prebuilt ltp tar) is specified in .yml, case will
run ltp directly from extracted ltp_binary_file without any configuration.
2. When ltp_source_file (downloaded ltp code) is specified in .yml,
case will use it to extract the tar and run ltp, instead of downloading runtime.
Example:
- name: ltp_source_file
value: <path_to_ltp.tar.xz>
is_case_visible: true
3. When ltp_binary_file/ltp_source_file not in .yml, clone github with
ltp_tests_git_tag
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

class HvModule
Description:
This test suite covers test cases previously handled by LISAv2:
LIS-MODULES-CHECK, VERIFY-LIS-MODULES-VERSION,
INITRD-MODULES-CHECK, RELOAD-MODULES-SMP
It is responsible for ensuring the Hyper V drivers are all present,
are included in initrd, and are all the same version.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_reload_hyperv_modules()
Description:
This test case will reload hyper-v modules for 100 times.
Priority:

1

Requirement:

min_core_count=4

verify_hyperv_modules()
Description:
This test case will
1. Verify the presence of all Hyper V drivers using lsmod
to look for the drivers not directly loaded into the kernel.
Priority:

1

verify_initrd_modules()
Description:
This test case will ensure all necessary hv_modules are present in
initrd. This is achieved by
1. Skipping any modules that are loaded directly in the kernel
2. Use lsinitrd tool to check whether a necessary module is missing
Priority:

1

Requirement:

unsupported_os[BSD]

verify_lis_modules_version()
Description:
This test case will
1. Verify the list of given LIS kernel modules and verify if the version
matches with the Linux kernel release number. (Drivers loaded directly in
to the kernel are skipped)
Priority:

2

class TimeSync
Description:
This test suite is related with time sync.
Platform:

Azure, Ready

Area:

time

Category:

functional

verify_timesync_unbind_clockevent()
Description:
This test is to check -
1. Current clock event name is ‘Hyper-V clockevent’ for x86,
‘arch_sys_timer’ for arm64.
2. ‘Hyper-V clockevent’ or ‘arch_sys_timer’ and ‘hrtimer_interrupt’
show up times in /proc/timer_list should equal to cpu count.
3. when cpu count is 1 and cpu type is Intel type, unbind current time
clock event, check current time clock event switch to ‘lapic’.
Priority:

2

verify_timesync_ptp()
Description:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/time-sync#check-for-ptp-clock-source # noqa: E501
This test is to check -
1. PTP time source is available on Azure guests (newer versions of Linux).
2. PTP device name is hyperv.
3. When accelerated network is enabled, multiple PTP devices will
be available, the names of ptp are changeable, create the symlink
/dev/ptp_hyperv to whichever /dev/ptp entry corresponds to the Azure host.
4. Chrony should be configured to use the symlink /dev/ptp_hyperv
instead of /dev/ptp0 or /dev/ptp1.
Priority:

2

verify_timesync_ntp()
Description:
This test is to check, ntp works properly.
1. Stop systemd-timesyncd if this service exists.
2. Set rtc clock to system time.
3. Restart Ntp service.
4. Check and set server setting in config file.
5. Restart Ntp service to reload with new config.
6. Check leap code using ntpq -c rv.
7. Check local time is synchronised with time server using ntpstat.
Priority:

2

verify_pmu_disabled_for_arm64()
Description:
This test is to check “initcall_blacklist=arm_pmu_acpi_init”
kernel parameter for ARM64 images.
Since Hyper-V right now doesn’t surface a fully functional PMU. It is needed to
have “initcall_blacklist=arm_pmu_acpi_init” to disable the PMU driver
temporarily to fall back to a timer-based sampling instead of PMU-event-based
sampling.
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_timesync_chrony()
Description:
This test is to check chrony works properly.
1. Restart chrony service.
2. Check and set server setting in config file.
3. Restart chrony service to reload with new config.
4. Check chrony sources and sourcestats.
5. Check chrony tracking.
Priority:

2

verify_timesync_unbind_clocksource()
Description:
This test is to check -
1. Check clock source name is one of hyperv_clocksource_tsc_page,
lis_hv_clocksource_tsc_page, hyperv_clocksource, tsc,
arch_sys_counter(arm64).
(there’s a new feature in the AH2021 host that allows Linux guests so use
the plain “tsc” instead of the “hyperv_clocksource_tsc_page”,
which produces a modest performance benefit when reading the clock.)
2. Check CPU flag contains tsc from /proc/cpuinfo.
3. Check clocksource name shown up in dmesg.
4. Unbind current clock source if there are 2+ clock sources, check current
clock source can be switched to a different one.
Priority:

2

verify_timedrift_corrected()
Description:
This test is to verify that timedrift is automatically corrected by chrony
after a time jump.
Steps:
1. Set makestep to 1.0 -1 to allow Chrony to make large adjustments.
Ref: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/time-sync#chrony # noqa: E501
2. Manually change the system clock to a time in the past.
3. Verify that Chrony has corrected the time drift.
Priority:

1

class AzureImageStandard
Description:
This test suite is used to check azure image configuration.
Platform:

Azure, Ready

Area:

azure_image_standard

Category:

functional

verify_omi_version()
Description:
This test verifies the version of the Open Management Infrastructure (OMI)
installed on the system is not vulnerable to the “OMIGOD” vulnerabilities.
The “OMIGOD” vulnerabilities (CVE-2021-38647, CVE-2021-38648,
CVE-2021-38645, CVE-2021-38649) were fixed in OMI version 1.6.8.1.
OMI github: https://github.com/microsoft/omi
Steps:
1. Check if OMI is installed on the system.
a. If OMI is installed, the version can be got by using
“”/opt/omi/bin/omiserver –version”” command.
b. If omiserver command fails, use “”dpkg -l omi | grep omi”” and
“”rpm -q omi”” to double-check whether the OMI package is installed.
c. If all the commands fail, it means OMI is not installed.
2. Verify that the version is 1.6.8.1 or later.
3. Pass if OMI is not installed or the version is secure.
Priority:

1

Requirement:

supported_platform_type[AZURE, QEMU]

verify_client_active_interval()
Description:
This test validates ClientAliveInterval setting in sshd config is present and
set to an appropriate value.
Steps:
1. Examine the sshd_config file to locate the ClientAliveInterval parameter.
The default sshd config file is /etc/ssh/sshd_config. If the file is not
present, use command “find / -name sshd_config” to locate it.
For Ubuntu, the ClientAliveInterval is set in
/etc/ssh/sshd_config.d/50-cloudimg-settings.conf
2. Verify the parameter exists. The test fails if ClientAliveInterval is not
found.
3. Confirm the value is within the acceptable range (> 0 and < 236 ). The test
fails if the value is outside this range. It is recommended to set
ClientAliveInterval to 180. For Azure certification, values between 30 and
235 are acceptable depending on application requirements. For more details,
refer to https://aka.ms/Linux-Testcases.
Priority:

2

Requirement:

supported_platform_type[AZURE, READY, HYPERV]

verify_dhcp_file_configuration()
Description:
This test will verify that dhcp file exists at
/etc/sysconfig/network/dhcp and DHCLIENT_SET_HOSTNAME is set
to no.
Steps:
1. Verify that dhcp file exists.
2. Verify that DHCLIENT_SET_HOSTNAME=”no” is present in the file.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_essential_kernel_modules()
Description:
This test case verifies the enablement of essential kernel modules like wdt and
cifs.
Priority:

1

Requirement:

supported_os[Linux]

verify_resource_disk_readme_file()
Description:
This test will check that the readme file existed in resource disk mount point.
Steps:
1. Obtain the mount point for the resource disk.
If the /var/log/cloud-init.log file is present,
attempt to read the customized mount point from
the cloud-init configuration file.
If mount point from the cloud-init configuration is unavailable,
use the default mount location, which is /mnt.
If none of the above sources provide the mount point,
it is retrieved from the ResourceDisk.MountPoint entry
in the waagent.conf configuration file.
2. Verify that resource disk is mounted from the output of mount command.
3. Verify lost+found folder exists.
4. Verify DATALOSS_WARNING_README.txt file exists.
5. Verify ‘WARNING: THIS IS A TEMPORARY DISK’ contained in
DATALOSS_WARNING_README.txt file.
Priority:

2

Requirement:

supported_platform_type[AZURE]

verify_ifcfg_eth0()
Description:
This test will verify contents of ifcfg-eth0 file on Fedora based distros.
Steps:
1. Read the ifcfg-eth0 file and verify that “DEVICE=eth0”, “BOOTPROTO=dhcp” and
“ONBOOT=yes” is present in network file.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_yum_conf()
Description:
This test will verify content of yum.conf file on Fedora based distros
for version < 6.6.0
Steps:
1. Read the yum.conf file and verify that “http_caching=packages” is
present in the file.
Priority:

2

Requirement:

supported_platform_type[AZURE, READY, HYPERV]

verify_no_swap_on_osdisk()
Description:
This test verifies that there is no swap partition or swap file on the OS disk
Azure’s policy 200.3.3 Linux:
No swap partition on the OS disk. Swap can be requested for creation on the
local resource disk by the Linux Agent. It is recommended that a single root
partition is created for the OS disk.
There should be no Swap Partition or swap file on OS Disk. OS disk has IOPS
limit. When memory pressure causes swapping, IOPS limit may be reached easily
and cause VM performance to go down disastrously, because aside from memory
issues it now also has IO issues.
Steps:
1. Use ‘cat /proc/swaps’ or ‘swapon -s’ to list all swap devices and swap files
If it is a swap file, use ‘df <swap_file>’ to get the partition name.
Note: For FreeBSD, use ‘swapinfo -k’. FreeBSD only supports swap partition.
2. Use ‘lsblk <swap_part> -P -o NAME’ to get the real block device name for
each swap partition. If there is no swap partition, pass the case.
3. Use ‘lsblk’ to identify the OS disk and get all its partitions and logical
devices through matching the mount point ‘/’.
Note: For FreeBSD, if there is no lsblk, install it and run the command
4. Compare if the device name of each swap partition is the same as the device
name of one OS disk partition or logical device. If yes, fail the case.
5. Pass the case if no swap partition is found on the OS disk.
Priority:

1

Requirement:

supported_platform_type[AZURE, QEMU]

verify_network_file_configuration()
Description:
This test will verify that network file exists in /etc/sysconfig and networking
is enabled on Fedora based distros. For Fedora version > 39, it checks if
/etc/NetworkManager/system-connections/ exists and is enabled.
Steps:
1. Verify that network file exists.
2. Verify that networking is enabled in the file.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_python_version()
Description:
This test verifies the version of Python installed on the system.
Steps:
1. Retrieve the Python version.
2. Check if the version is lower than the minimum supported version.
The minimum supported version can be found at:
https://devguide.python.org/versions/
3. Fail the test if the version is lower than the minimum supported version,
otherwise pass.
Priority:

1

Requirement:

supported_platform_type[AZURE, QEMU]

verify_azure_64bit_os()
Description:
This test verifies that the Linux operating system has a 64-bit architecture.
Steps:
1. Retrieve the OS architecture using the Uname tool.
2. Verify that the architecture is either x86_64/amd64 or aarch64/arm64.
3. Fail the test if the architecture is not 64-bit.
Priority:

1

Requirement:

supported_platform_type[AZURE, QEMU]

verify_hv_kvp_daemon_installed()
Description:
This test will check that kvp daemon is installed. This is an optional
requirement for Debian based distros.
KVP daemon is not supported / disabled on CVMs (SNP/TDX) to restrict
host/guest interaction to minimize attack surface.
Steps:
1. Verify that list of running process matching name of kvp daemon
has length greater than zero.
Priority:

2

Requirement:

supported_features

verify_network_manager_not_installed()
Description:
This test will verify that network manager doesn’t conflict with the
waagent on Fedora based distros.
Steps:
1. Get the output of command rpm -q NetworkManager and verify that
network manager is not installed.
Priority:

3

Requirement:

supported_platform_type[AZURE, READY, HYPERV]

verify_udev_rules_moved()
Description:
This test will verify that udev rules have been moved out in CoreOS
and Fedora based distros
Steps:
1. Verify that 75-persistent-net-generator.rules and 70-persistent-net.rules
files are not present.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_grub()
Description:
This test will check the configuration of the grub file and verify that numa
is disabled for Redhat distro version < 6.6.0
Steps:
1. Verify grub configuration depending on the distro type.
2. For Redhat based distros, verify that numa is disabled for versions < 6.6.0
Priority:

1

Requirement:

unsupported_os[BSD]

verify_waagent_version()
Description:
This test verifies the version of the Microsoft Azure Linux Agent (waagent).
Steps:
1. Retrieve the version of waagent.
2. Check if the version is lower than the minimum supported version.
The minimum supported version can be found at:
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/
windows/support-extensions-agent-version
3. Check if auto update is enabled.
4. Fail the test if the version is lower than the minimum supported version
and auto update is not enabled, otherwise pass.
Priority:

1

Requirement:

supported_platform_type[AZURE]

verify_repository_installed()
Description:
This test will check that repositories are correctly installed.
Steps:
1. Verify the repository configuration depending on the distro type.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_boot_error_fail_warnings()
Description:
This test will check error, failure, warning messages from demsg,
/var/log/syslog or /var/log/messages file.
Steps:
1. Get failure, error, warning messages from dmesg, /var/log/syslog or
/var/log/messages file.
2. If any unexpected failure, error, warning messages excluding ignorable ones
existing, fail the case.
Priority:

5

Requirement:

supported_platform_type[AZURE, READY, HYPERV]

verify_os_update()
Description:
Verify if there is any issues in and after ‘os update’
Steps:
1. Run os update command.
2. Reboot the VM and see if the VM is still in good state.
Priority:

2

Requirement:

supported_platform_type[AZURE, READY, HYPERV]

verify_serial_console_is_enabled()
Description:
This test verifies that Serial Console is properly enabled in the kernel
command line.
Steps:
1. Check the kernel command line by “cat proc/cmdline” for the console device
1.1. Expected to see ‘console=ttyAMA0’ for aarch64.
1.2. Expected to see ‘console=ttyS0’ for x86_64.
FreeBSD doesn’t have /proc/cmdline, then check the logs.
2. If there is no expected pattern, get the kernel command line from
/var/log/messages, /var/log/syslog, dmesg, or journalctl output.
3. Check expected setting from kernel command line.
3.1. Expected to see ‘console [ttyAMA0] enabled’ for aarch64.
3.2. Expected to see ‘console [ttyS0] enabled’ for x86_64.
3.3. Expected to see ‘uart0: console (115200,n,8,1)’ for FreeBSD.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_bash_history_is_empty()
Description:
This test verifies that bash/shell history files of all the bash/shell users
are either non-existent or empty in the image.
Steps:
1. Get all the bash/shell users’ main directory from /etc/passwd file.
2. Using command ‘find <user_main_dir> -type f
(-name “.*sh_history” -o -name “.history”)’ to get all the history files.
3. Using command ‘ls -lt <history_file>’ to check if the history file exists.
4. If it doesn’t exist, the test passes as this indicates the image is properly
prepared.
5. If the history file exists, verify it is empty. If not empty, the test
fails as bash history should be cleared.
The history file name of the users of “/bin/bash” and “/bin/sh” is
“.bash_history”. The following shell types and their history file names
are listed below:
/bin/tcsh: .history
/bin/csh: .history
/bin/zsh: .zsh_history
/bin/ksh: .sh_history
/bin/dash: .sh_history
/bin/ash: .sh_history
/bin/pdksh: .sh_history
/bin/mksh: .sh_history
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_default_targetpw()
Description:
This test will verify that Defaults targetpw is not enabled in the
/etc/sudoers file.
If targetpw is set, sudo will prompt for the
password of the user specified by the -u option (defaults to root)
instead of the password of the invoking user when running a command
or editing a file. More information can be found here :
https://linux.die.net/man/5/sudoers
Steps:
1. Get the content of /etc/sudoers file.
2. Verify that Defaults targetpw should be disabled, if present.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

verify_resource_disk_file_system()
Description:
This test will check that resource disk is formatted correctly.
Steps:
1. Get the mount point for the resource disk. If /var/log/cloud-init.log
file is present, mount location is /mnt, otherwise it is obtained from
ResourceDisk.MountPoint entry in waagent.conf configuration file.
2. Verify that resource disk file system type should not be ‘ntfs’.
Priority:

1

Requirement:

supported_platform_type[AZURE]

verify_openssl_version()
Description:
This test verifies the version of OpenSSL installed on the system. Please
refer to https://www.openssl-library.org/source/ for supported versions.
Steps:
1. Retrieve the OpenSSL version.
2. Check if the version is lower than the minimum supported version 3.0.0.
3. If the version is lower than 3.0.0, check if the version is 1.1.1 or 1.0.2.
4. Fail the test if the version is lower than the minimum supported version
and not the versions having extended support, otherwise pass.
Priority:

1

Requirement:

supported_platform_type[AZURE, QEMU]

verify_cloud_init_error_status()
Description:
This test will check ERROR, WARNING messages from /var/log/cloud-init.log
and also check cloud-init exit status.
Steps:
1. Get ERROR, WARNING messages from /var/log/cloud-init.log.
2. If any unexpected ERROR, WARNING messages or non-zero cloud-init status
fail the case.
Priority:

2

Requirement:

supported_platform_type[AZURE, READY, HYPERV]

verify_no_pre_exist_users()
Description:
This test will check no pre added users existing in vm.
Steps:
1. Exclude current user from all users’ list.
2. Fail the case if the password of any above user existing.
3. Fail the case if the key of any user existing.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

class Msr
Description:
Test suite verifies hyper-v platform id is set correctly via hypercall to host.
Theoretically, this could work for any guest which uses hypercalls
on Hyper-V or Azure.
Platform:

Azure, Ready

Area:

msr

Category:

functional

verify_hyperv_platform_id()
Description:
verify platform id is accurate in msr register
Priority:

1

class Dns
Description:
This test suite covers DNS name resolution functionality.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_dns_name_resolution()
Description:
This test case check DNS name resolution by ping bing.com.
Priority:

1

verify_dns_name_resolution_after_upgrade()
Description:
This test case check DNS name resolution by ping bing.com after upgrade system.
Priority:

1

class KernelDebug
Description:
This test suite covers kernel debug functionalities.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_enable_kprobe()
Description:
This test case check VM can be enabled kprobe.
Steps:
1. Check if CONFIG_KPROBE_EVENTS is enabled in kernel config.
2. Check if /sys/kernel/debug/tracing/ is mounted, if not, mount it.
3. Get origin values of /sys/kernel/debug/tracing/kprobe_events and
/sys/kernel/debug/tracing/events/kprobes/my/enable.
4. Write “p:my filp_close” to /sys/kernel/debug/tracing/kprobe_events and
write “1” to /sys/kernel/debug/tracing/events/kprobes/my/enable.
5. Check if /sys/kernel/debug/tracing/kprobe_events and
/sys/kernel/debug/tracing/events/kprobes/my/enable are changed.
6. Write origin values back to /sys/kernel/debug/tracing/kprobe_events and
/sys/kernel/debug/tracing/events/kprobes/my/enable.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, HYPERV, QEMU]

class Vdso
Description:
This test suite is used to test vdso using vdsotest benchmark.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_vdso()
Description:
This test is to check gettime, getres, getcpu and gettimeofday calls are not
being redirected as system calls, leading to performance bottleneck, Linux
systems have a mechanism called vdso which helps in above methods to be executed
in userspace (no syscall).
The kernel selftest can’t be used here for two reasons:
1. need clone all linux source code
2. can’t repro the regression issue https://bugs.launchpad.net/bugs/1977753
Steps:
1. Install vdsotest benchmark.
2. Run vdsotest benchmark.
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

class ZramCompression
Description:
This test suite validates zram compression algorithm support.
It verifies that the kernel can load zram with crypto_zstd and
crypto_lz4 compression backends and that zram devices function
correctly with each algorithm.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_zram_crypto_lz4()
Description:
Verify zram works with the lz4 compression algorithm.
Steps:
1. Load the crypto_lz4 kernel module.
2. Load the zram kernel module with num_devices=1.
3. Set the compression algorithm to lz4 on /dev/zram0.
4. Set the disk size and verify the device is usable.
5. Reset and clean up the zram device.
Priority:

3

verify_zram_crypto_zstd()
Description:
Verify zram works with the zstd compression algorithm.
Steps:
1. Load the crypto_zstd kernel module.
2. Load the zram kernel module with num_devices=1.
3. Set the compression algorithm to zstd on /dev/zram0.
4. Set the disk size and verify the device is usable.
5. Reset and clean up the zram device.
Priority:

3

class CPU
Description:
This test suite is used to run CPU related tests.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_cpu_count()
Description:
This test will check that vCPU count correctness.
Steps :
1. Get vCPU count.
2. Calculate vCPU count by core_per_socket_count * socket_count *
thread_per_core_count.
3. Judge whether the actual vCPU count equals to expected value.
Priority:

1

Requirement:

unsupported_os

verify_l3_cache()
Description:
This test case will check that L3 cache is correctly mapped
to NUMA node.
Steps:
1. Check if NUMA is disabled in commandline. If disabled,
and kernel version is <= 2.6.37, test is skipped as hyper-v
has no support for NUMA : https://t.ly/x8k3
2. Get the mappings using command :
lscpu –extended=cpu,node,socket,cache
3. Each line in the mapping corresponds to one CPU core. The L3
cache of each core must be mapped to the NUMA node that core
belongs to instead of the core itself.
Example :
Correct mapping:
CPU NODE SOCKET L1d L1i L2 L3
8 0 0 8 8 8 0
9 1 1 9 9 9 1
Incorrect mapping:
CPU NODE SOCKET L1d L1i L2 L3
8 0 0 8 8 8 8
9 1 1 9 9 9 9
Priority:

1

Requirement:

unsupported_os[Windows, BSD]

verify_vmbus_interrupts()
Description:
This test will verify if the CPUs inside a Linux VM are processing VMBus
interrupts by checking the /proc/interrupts file.
There are 3 types of Hyper-v interrupts : Hypervisor callback
interrupts, Hyper-V reenlightenment interrupts, and Hyper-V stimer0
interrupts, these types not shown up in arm64 arch.
Hyper-V reenlightenment interrupts are 0 unless the VM is doing migration.
Hypervisor callback interrupts are vmbus events that are generated on all
the vmbus channels, which belong to different vmbus devices. A VM with upto
4 vcpu on Azure/Hyper-V should have a NetVSC NIC, which normally has 4 VMBus
channel and should be bound to all the vCPUs.
Hyper-V Synthetic timer interrupts should be received on each CPU if the VM
is run for a long time. We can simulate this process by running CPU
intensive workload on each vCPU.
Steps:
1. Look for the Hyper-v timer property of each vCPU under /proc/interrupts
2. For Hyper-V reenlightenment interrupt, verify that the interrupt count
for all vCPU are zero.
3. For Hypervisor callback interrupt, verify that at least min(#vCPU, 4)
vCPU’s are processing interrupts.
4. For Hyper-V Synthetic timer, run a CPU intensive command on each vCPU and
verify that every vCPU is processing the interrupt.
Priority:

2

class GDB
Description:
This test suite covers gdb functionality.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_gdb()
Description:
This test case check gdb work well by checking output.
1. compile code with gdb options
2. run gdb with compiled file
3. expect to see ‘Hello World![Inferior 1 (process 1869) exited normally]’
from output
Priority:

2

class Dhcp
Description:
This test suite covers DHCP functionalities.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_dhcp_client_timeout()
Description:
This test case check the timeout setting of DHCP on Azure equals or more
than 300 seconds.
Priority:

1

Requirement:

supported_platform_type[AZURE, READY, QEMU]

class Storage
Description:
This test suite is used to run storage related tests.
Platform:

Azure, Ready

Area:

storage

Category:

functional

verify_os_partition_identifier()
Description:
This test will verify that identifier of root partition matches
from different sources.
Steps:
1. Get the partition identifier from blkid command.
2. Verify that the partition identifier from blkid is present in dmesg.
3. Verify that the partition identifier from blkid is present in fstab output.
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_resource_disk_io()
Description:
This test will check that the file IO operations are working correctly
Steps:
1. Get the mount point for the resource disk. If /var/log/cloud-init.log
file is present, mount location is /mnt, otherwise it is obtained from
ResourceDisk.MountPoint entry in waagent.conf configuration file.
2. Verify that resource disk is mounted from the output of mount command.
3. Write a text file to the resource disk.
4. Read the text file and verify that content is same.
Priority:

1

Requirement:

supported_platform_type[AZURE]

verify_resource_disk_mounted()
Description:
This test will check that the resource disk is present in the list of mounted
devices. Most VMs contain a resource disk, which is not a managed disk and
provides short-term storage for applications and processes. It is intended to
only store data such as page or swap files.
Steps:
1. Get the mount point for the resource disk. If /var/log/cloud-init.log
file is present, mount location is /mnt, otherwise it is obtained from
ResourceDisk.MountPoint entry in waagent.conf configuration file.
2. Verify that “/dev/<disk> <mount_point>` entry is present in
/etc/mtab file and the disk should not be equal to os disk.
Priority:

1

Requirement:

supported_platform_type[AZURE]

verify_hot_add_disk_serial()
Description:
This test case will verify that the standard hdd data disks disks can
be added one after other (serially) while the vm is running.
Steps:
1. Get maximum number of data disk for the current vm_size.
2. Get the number of data disks already added to the vm.
3. Serially add and remove the data disks and verify that the added
disks are present in the vm.
Priority:

2

Requirement:

disk

verify_hot_add_disk_serial_standard_ssd()
Description:
This test case will verify that the standard ssd data disks disks can
be added serially while the vm is running. The test steps are same as
hot_add_disk_serial.
Priority:

2

Requirement:

disk

verify_smb_linux()
Description:
A comprehensive test to verify CIFS module and SMB share functionality between
two Linux VMs.
This test case will
1. Create 2 VMs in Azure
2. Check if CONFIG_CIFS is enabled in KCONFIG
3. Configure one VM as SMB server and create a share
4. Mount the other VM to the SMB share
5. Verify mount is successful
6. Write a test file to the SMB share and read it back to verify IO
7. Clean up the SMB share and unmount
8. repeat steps 4-7 for SMB versions [“2.0”, “2.1”, “3.0”, “3.1.1”]
Priority:

1

Requirement:

supported_os[Debian]

verify_nfsv4_basic()
Description:
This test case will verify mount azure nfs 4.1 on guest successfully.
Refer to https://learn.microsoft.com/en-us/azure/storage/files/files-nfs-protocol#features # noqa: E501
Uses the unified AzureFileShare class with NFS protocol.
Priority:

5

Requirement:

supported_features[AzureFileShare]

verify_swap()
Description:
This test will check that the swap is correctly configured on the VM.
Steps:
1. Check if swap file/partition is configured by checking the output of
swapon -s and lsblk.
2. Check swap status in waagent.conf.
3. Verify that truth value in step 1 and step 2 match.
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_disks_device_timeout_setting()
Description:
This test will check that VM disks are provisioned
with the correct timeout.
Steps:
1. Find the disks for the VM by listing /sys/block/sd*.
2. Verify the timeout value for disk in
/sys/block/<disk>/device/timeout file is set to 300.
Priority:

2

Requirement:

disk

verify_hot_add_disk_parallel()
Description:
This test case will verify that the standard HDD data disks can
be added in one go (parallel) while the vm is running.
Steps:
1. Get maximum number of data disk for the current vm_size.
2. Get the number of data disks already added to the vm.
3. Add maximum number of data disks to the VM in parallel.
4. Verify that the disks are added are available in the OS.
5. Remove the disks from the vm in parallel.
6. Verify that the disks are removed from the OS.
Priority:

2

Requirement:

disk

verify_hot_add_disk_parallel_standard_ssd()
Description:
This test case will verify that the standard ssd data disks disks can
be added serially while the vm is running. The test steps are same as
hot_add_disk_parallel.
Priority:

2

Requirement:

disk

verify_hot_add_disk_serial_random_lun_standard_ssd()
Description:
This test case will verify that the standard ssd data disks disks can
be added serially on random lun while the vm is running.
Steps:
1. Get maximum number of data disk for the current vm_size.
2. Get the number of data disks already added to the vm.
3. Add 1 standard ssd data disks to the VM on random free lun.
4. Verify that the disks are added are available in the OS.
5. Repeat steps 3 & 4 till max disks supported by VM are attached.
6. Remove the disks from the vm from random luns.
7. Verify that 1 disk is removed from the OS.
8. Repeat steps 6 & 7 till all randomly attached disks are removed.
Priority:

2

Requirement:

disk

verify_hot_add_disk_serial_random_lun_premium_ssd()
Description:
This test case will verify that the premium ssd data disks disks can
be added serially on random lun while the vm is running.
Steps:
1. Get maximum number of data disk for the current vm_size.
2. Get the number of data disks already added to the vm.
3. Add 1 premium ssd data disks to the VM on random free lun.
4. Verify that the disks are added are available in the OS.
5. Repeat steps 3 & 4 till max disks supported by VM are attached.
6. Remove the disks from the vm from random luns.
7. Verify that 1 disk is removed from the OS.
8. Repeat steps 6 & 7 till all randomly attached disks are removed.
Priority:

2

Requirement:

disk

verify_hot_add_disk_parallel_premium_ssd()
Description:
This test case will verify that the premium ssd data disks disks can
be added serially while the vm is running. The test steps are same as
hot_add_disk_parallel.
Priority:

2

Requirement:

disk

verify_scsi_disk_controller_type()
Description:
This test verifies scsi disk controller type of the VM.
Steps:
1. Get the disk type of the boot partition.
2. Compare it with hardware disk controller type of the VM.
Priority:

1

Requirement:

disk

verify_nvme_disk_controller_type()
Description:
This test verifies nvme disk controller type of the VM. It requires NVMe
supported VM sizes such as DsV6, EsV6 series. If the image doesn’t support NVMe
or the NVMe driver is not in initramfs, the VM might timeout to provision.
Steps:
1. Get the disk type of the boot partition.
2. Compare it with hardware disk controller type of the VM.
Priority:

1

Requirement:

disk

verify_cifs_basic()
Description:
This test case will
1. Check if CONFIG_CIFS is enabled in KCONFIG
2. Create an Azure File Share
3. Mount the VM to Azure File Share
4. Verify mount is successful
Downgrading priority from 1 to 5. The file share relies on the
storage account key, which we cannot use currently.
Will change it back once file share works with MSI.
TODO: Test this case with storage account reuse changes in
AzureFileShare class (features.py). This test does NOT use
private endpoints (enable_private_endpoint=False by default).
Priority:

5

Requirement:

unsupported_os[BSD, Windows]

verify_hot_add_disk_serial_premium_ssd()
Description:
This test case will verify that the premium ssd data disks disks can
be added serially while the vm is running. The test steps are same as
hot_add_disk_serial.
Priority:

2

Requirement:

disk

class Kvp
Description:
This test suite verify the KVP service runs well on Azure and Hyper-V
platforms. The KVP is used to communicate between Windows host and guest VM.
Platform:

Azure, Ready

Area:

kvp

Category:

functional

verify_kvp()
Description:
Verify KVP daemon installed, running, permission correct.
1. run the KVP client tool and verify that the data pools are created and
accessible.
2. check kvp_pool file permission is 644.
3. verify that the KVP Daemon is running.
4. check kernel version supports hv_kvp.
5. Check if KVP pool 3 file has a size greater than zero.
6. At least 11 items are present in pool 3, and verify record count is
correct.
Priority:

1

Requirement:

supported_features

class SchedCore
Description:
Validates SCHED_CORE (Core Scheduling) kernel functionality.
Requires CONFIG_SCHED_CORE enabled.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_sched_core_basic()
Description:
Verifies basic SCHED_CORE prctl functionality.
Steps:
1. Check CONFIG_SCHED_CORE is enabled
2. Compile and run a test that creates a core scheduling group
3. Verify a valid cookie is returned
Priority:

2

class LsVmBus
Description:
This test suite is used to check vmbus devices and their associated vmbus channels.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_vmbus_devices_channels()
Description:
This test case will
1. Check expected vmbus device names presented in the lsvmbus output.
- Operating system shutdown
- Time Synchronization
- Heartbeat
- Synthetic network adapter
- Synthetic SCSI Controller
- Synthetic IDE Controller (gen1 only)
It expects additional three vmbus device names for non-cvm:
- Data Exchange
- Synthetic mouse
- Synthetic keyboard
2. Check that each netvsc and storvsc SCSI device have correct number of vmbus
channels created and associated.
2.1 Check expected channel count of each netvsc device.
- Legacy logic (before Linux commit 646f071d315b75e87583de290d333478d42ccde1): # noqa: E501
2.1.1 Calculate channel count of each netvsc device.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/hyperv/rndis_filter.c#n1548 # noqa: E501
2.1.2 Cap of channel count of each netvsc device.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/hyperv/hyperv_net.h#n877 # noqa: E501
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/hyperv/rndis_filter.c#n1551 # noqa: E501
=> Expected channel count = min(num of vCPUs, 8).
- New logic (after Linux commit 646f071d315b75e87583de290d333478d42ccde1): # noqa: E501
2.1.3 If vCPU count <= 16, expected channel count = num of vCPUs.
2.1.4 If vCPU count > 16, expected channel count =
min(64, max(16, physical core count / 2)).
Reference:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=646f071d315b75e87583de290d333478d42ccde1
- Test logic:
The code will first validate against the legacy rule.
If actual channel count does not match, it will then apply the new rule.
2.2 Check expected channel count of each storvsc SCSI device is min (num of
vcpu/4, 64).
2.2.1 Calculate channel count of each storvsc SCSI device.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/scsi/storvsc_drv.c#n368 # noqa: E501
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/scsi/storvsc_drv.c#n1936 # noqa: E501
2.2.2 Cap of channel count of each storvsc SCSI device,
it is decided by host storage VSP driver.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/scsi/storvsc_drv.c#n952 # noqa: E501
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_vmbus_devices_channels_bsd()
Description:
This test case will check expected vmbus device names presented in the lsvmbus
output for FreeBSD.
- Hyper-V Shutdown
- Hyper-V Timesync
- Hyper-V Heartbeat
- Hyper-V KBD
- Hyper-V Network Interface
- Hyper-V SCSI
Priority:

1

Requirement:

supported_os[BSD]

verify_vmbus_heartbeat_properties()
Description:
This test case will
1. Looks for the VMBus heartbeat device properties.
2. Checks the properties can be read and that the folder structure exists.
3. Checks that the in_* files are equal to the out_* files
when read together.
4. Checks the interrupts and events values are increasing during
reading them.
Priority:

4

Requirement:

unsupported_os[BSD, Windows]

class Boot
Description:
This test suite is to test VM working well after updating on VM and rebooting.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_boot_with_debug_kernel()
Description:
This test case will
1. Skip testing if the distro is not redhat/centos type, RHEL added this test
case, since they encounter an issue which is seeing call trace when boot
with debug kernel.
2. Skip if kernel-debug package is not available in repos (e.g. HPC images).
3. Install kernel-debug package and set boot with this debug kernel.
4. Reboot VM, check kernel version is debug type.
Priority:

3

Requirement:

supported_os[Redhat, CentOs]

class Provisioning
Description:
This test suite uses to verify if an environment can be provisioned correct or not.
- The basic smoke test can run on all images to determinate if a image can boot and
reboot.
- Other provisioning tests verify if an environment can be provisioned with special
hardware configurations.
Platform:

Azure, Ready

Area:

provisioning

Category:

functional

stress_reboot()
Description:
This case performs a reboot stress test on the node
and iterates smoke test 10 times.
The test steps are almost the same as smoke_test.
The reboot times is summarized after the test is run
Priority:

3

Requirement:

EnvironmentStatus.Deployed

smoke_test_check_serial_console_pattern()
Description:
This case runs a smoke test and checks the serial console output for
an optional pattern with pre-check and post-check validation.
The variable ‘serial_console_pattern’ can be provided to check for
specific patterns. If not provided, defaults to ‘BUG: soft lockup’.
- Pattern can be a string (substring match) or regex pattern string
1. Pre-check: Counts pattern occurrences before smoke test execution.
- Fails if pattern found (count > 0) indicating boot-time issues.
2. Runs standard smoke test operations (reboot, connectivity checks).
3. Post-check: Counts pattern occurrences after smoke test execution.
- Fails if new occurrences detected (post > pre) indicating issues
introduced during test operations.
This two-stage approach distinguishes boot-time issues from test-induced
issues and avoids false positives from pre-existing console content.
This test requires serial console support on the platform.
Priority:

1

Requirement:

supported_features[SerialConsole]

verify_deployment_provision_sriov()
Description:
This case runs smoke test on a node provisioned with sriov.
The test steps are same as smoke_test.
Priority:

1

Requirement:

network_interface

verify_deployment_provision_ephemeral_managed_disk()
Description:
This case runs smoke test on a node provisioned with ephemeral disk.
The test steps are same as smoke_test.
Priority:

1

Requirement:

disk

verify_deployment_provision_standard_ssd_disk()
Description:
This case runs smoke test on a node provisioned with standard ssd disk.
The test steps are same as smoke_test.
Priority:

1

Requirement:

disk

verify_stop_start_in_platform()
Description:
This case runs smoke test on a node provisioned.
The test steps are almost the same as smoke_test except for
executing stop then start from Azure SDK.
Priority:

1

Requirement:

supported_features[StartStop]

verify_deployment_provision_swiotlb_force()
Description:
This test case verifies that the system can boot and provision successfully
with the swiotlb=force kernel parameter enabled. This kernel parameter
forces the use of software I/O TLB for all DMA operations.
This is particularly relevant in Confidential Computing VMs,
where memory is encrypted and direct DMA access isn’t possible.
In such cases, bounce buffering becomes mandatory.
Regression: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=730ff06d3f5cc2ce0348414b78c10528b767d4a3 # noqa
Steps:
1. Set the swiotlb=force kernel parameter in grub configuration
2. Reboot the system to apply the kernel parameter
3. Run smoke test to verify system functionality
4. Verify the system is responsive after reboot
TODO: This test is currently unsupported on CVM because modifying boot
parameters in CVM requires rebuilding, which needs access to kernel image,
modules, and initramfs all unbundled. With just UEFI image, more research
is needed to determine if it’s possible
TODO: Ideally this should run on all UEFI scenarios, not just Grub-based
systems. However, since LISA does not have a common UEFI interface yet,
we skip non-grub scenarios for now.
Priority:

2

Requirement:

supported_features

verify_deployment_provision_synthetic_nic()
Description:
This case runs smoke test on a node provisioned with synthetic nic.
The test steps are same as smoke_test.
Priority:

1

Requirement:

network_interface

verify_deployment_provision_ultra_datadisk()
Description:
This case runs smoke test on a node provisioned with an ultra datadisk.
The test steps are same as smoke_test.
Priority:

1

Requirement:

EnvironmentStatus.Deployed

verify_deployment_provision_premiumv2_disk()
Description:
This case runs smoke test on a node provisioned with premium disk.
The test steps are same as smoke_test.
Priority:

1

Requirement:

supported_features

verify_deployment_provision_premium_disk()
Description:
This case runs smoke test on a node provisioned with premium disk.
The test steps are same as smoke_test.
Priority:

1

Requirement:

disk

smoke_test()
Description:
This case verifies whether a node is operating normally.
Steps,
1. Connect to TCP port 22. If it’s not connectable, failed and check whether
there is kernel panic.
2. Connect to SSH port 22, and reboot the node. If there is an error and kernel
panic, fail the case. If it’s not connectable, also fail the case.
3. If there is another error, but not kernel panic or tcp connection, pass with
warning.
4. Otherwise, fully passed.
Priority:

0

Requirement:

EnvironmentStatus.Deployed

verify_reboot_in_platform()
Description:
This case runs smoke test on a node provisioned.
The test steps are almost the same as smoke_test except for
executing reboot from Azure SDK.
Priority:

2

Requirement:

supported_features[StartStop]

class SerialConsoleSuite
Description:
This tests functionality of connecting to serial console.
Platform:

Azure, Ready

Area:

serial_console

Category:

functional

verify_serial_console()
Description:
The test runs echo back command on serial console and verifies
that the command has been successfully put to the
serial console.
Priority:

3

Requirement:

supported_features[SerialConsole]

class VmResize
Description:
This test suite tests VM behavior upon resizing
Platform:

Azure, Ready

Area:

vm_resize

Category:

functional

verify_vm_resize_decrease()
Description:
This test case stops VM resizes the VM, starts VM and checks if it has
the expected capabilities (memory size and core count) after the resize
Steps:
1. Stop VM
2. Resize VM into smaller VM size
3. Start VM
4. Check the VM’s core count and memory size against their expected values
Priority:

1

Requirement:

supported_features[Resize, StartStop]

verify_vm_hot_resize()
Description:
This test case hot resizes the VM and checks if it has the expected capabilities
(memory size and core count) after the hot resize
Steps:
1. Resize VM into larger VM size
2. Check the VM’s core count and memory size after hot resize
against their expected values
Priority:

1

Requirement:

supported_features[Resize]

verify_vm_resize_increase()
Description:
This test case stops VM resizes the VM, starts VM and checks if it has
the expected capabilities (memory size and core count) after the resize
Steps:
1. Stop VM
2. Resize VM into larger VM size
3. Start VM
4. Check the VM’s core count and memory size against their expected values
Priority:

1

Requirement:

supported_features[Resize, StartStop]

verify_vm_hot_resize_decrease()
Description:
This test case hot resizes the VM and checks if it has the expected capabilities
(memory size and core count) after the resize
Steps:
1. Resize VM into smaller VM size
2. Check the VM’s core count and memory size after hot resize
against their expected values
Priority:

1

Requirement:

supported_features[Resize]

class Floppy
Description:
This test suite ensures the floppy driver is disabled.
The floppy driver is not needed on Azure and
is known to cause problems in some scenarios.
Platform:

Azure, Ready

Area:

core

Category:

functional

verify_floppy_module_is_blacklisted()
Description:
The goal of this test is to ensure the floppy module is not enabled
for images used on the Azure platform.
This test case will
1. Dry-run modprobe to see if floppy module can be loaded
2. If “insmod” would be executed then the module is not already loaded
3. If module cannot be found then it is not loaded
If the module is loaded, running modprobe will have no output
Priority:

1

class CPUStressSuite
Description:
This test suite is used to run cpu related tests under stress.
Platform:

Azure, Ready

Area:

cpu

Category:

stress

stress_cpu_hot_plug()
Description:
This test will check cpu hotplug under stress.
Detailed steps please refer case verify_cpu_hot_plug.
Priority:

3

Requirement:

min_core_count=32

class CPUSuite
Description:
This test suite is used to run cpu related tests, set cpu core 16 as minimal
requreiemnt, since test case relies on idle cpus to do the testing.
Platform:

Azure, Ready

Area:

cpu

Category:

functional

verify_cpu_offline_storage_workload()
Description:
This test will check cpu hotplug with storage workload.
The cpu hotplug steps are same as verify_cpu_hot_plug test case.
Priority:

4

Requirement:

min_core_count=16

verify_cpu_hot_plug()
Description:
This test will check cpu hotplug.
Steps :
1. skip test case when kernel doesn’t support cpu hotplug.
2. set all vmbus channels target to cpu 0.
when kernel version >= 5.8 and vmbus version >= 4.1, code supports changing
vmbus channels target cpu, by setting the cpu number to the file
/sys/bus/vmbus/devices/<device id>/channels/<channel id>/cpu.
then all cpus except for cpu 0 are in idle state.
2.1 save the raw cpu number of each channel for restoring after testing.
2.2 set all vmbus channel interrupts go into cpu 0.
3. collect idle cpu which can be used for hotplug.
if the kernel supports step 2, now in used cpu is 0.
exclude the in used cpu from all cpu list to get idle cpu set which can be
offline and online.
if the kernel doesn’t step 2,
the idle cpu is quite rely on the cpu usage at that time.
4. skip testing when there is no idle cpu can be set offline and online.
5. set idle cpu offline then back to online.
6. restore the cpu vmbus channel target cpu back to the original state.
Priority:

3

Requirement:

min_core_count=32

verify_cpu_offline_channel_add()
Description:
This test will check that the added channels to synthetic network
adapter do not handle interrupts on offline cpu.
Steps:
1. Get list of offline CPUs.
2. Add channels to synthetic network adapter.
3. Verify that the channels were added to synthetic network adapter.
4. Verify that the added channels do not handle interrupts on offline cpu.
Priority:

4

Requirement:

min_core_count=16

verify_cpu_offline_network_workload()
Description:
This test will check cpu hotplug with network workload.
The cpu hotplug steps are same as verify_cpu_hot_plug test case.
Priority:

4

Requirement:

min_core_count=16

class NetworkComponentTest
Description:
This test suite validates the core functionality of network security components
such as conntrack, ipset, and iptables. It ensures that connection tracking,
IP-based filtering, and custom rule management operate as expected
Platform:

Azure, Ready

Area:

network

Category:

functional

verify_net_iptables()
Description:
This test will verify iptables functionality by ensuring that custom chains
and rules can be created with log prefixes
Priority:

2

verify_net_conntrack()
Description:
This test case will validate that conntrack can successfully create a connection
entry for an unknown protocol with a specified connection mark, and verify that
the mark can be reset correctly for such unknown protocol entries.
Priority:

2

verify_net_ipset()
Description:
This test will verify ipset functionality by ensuring IP-based blocking
via iptables is correctly enforced.
Priority:

2

class MdatpSuite
Description:
Test to verify there are no pre-installed copies of mdatp.
Platform:

Azure, Ready

Area:

mdatp

Category:

functional

verify_mdatp_not_preinstalled()
Description:
Check for mdatp endpoint/cloud install, dump config info.
Fails if mdatp is installed in the image.
Raises specific error messages depending on the type of info
found
Priority:

3

Requirement:

supported_platform_type[AZURE]

class Drm
Description:
This test suite uses to verify drm driver sanity.
Platform:

Azure, Ready

Area:

drm

Category:

functional

verify_no_error_output()
Description:
This case is to check this patch
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=19b5e6659eaf537ebeac90ae30c7df0296fe5ab9 # noqa: E501
Step,
1. Get dmesg output.
2. Check no ‘Unable to send packet via vmbus’ shown up in dmesg output.
Priority:

2

Requirement:

supported_features

verify_drm_driver()
Description:
This case is to check whether the hyperv_drm driver registered successfully.
Once driver is registered successfully it should appear in lsmod output.
Steps,
1. lsmod
2. Check if hyperv_drm exist in the list.
Priority:

2

Requirement:

supported_features

verify_connection_status()
Description:
This case is to check connector status using modetest utility for drm.
Step,
1. Install tool modetest.
2. Verify the status return from modetest is connected.
Priority:

2

Requirement:

supported_features

verify_dri_node()
Description:
This case is to check whether the dri node is populated correctly.
If hyperv_drm driver is bind correctly it should populate dri node.
This dri node can be find at following sysfs entry : /sys/kernel/debug/dri/0.
The dri node name (/sys/kernel/debug/dri/0/name) should contain hyperv_drm.
Step,
1. Cat /sys/kernel/debug/dri/0/name.
2. Verify it contains hyperv_drm string in it.
Priority:

2

Requirement:

supported_features

class Gpu
Description:
This test suite runs the gpu test cases.
Platform:

Azure, Ready

Area:

gpu

Category:

functional

verify_load_gpu_driver()
Description:
This test case verifies if gpu drivers are loaded fine.
Steps:
1. Validate if the VM SKU is supported for GPU.
2. Install LIS drivers if not already installed for Fedora and its
derived distros. Reboot the node
3. Install required gpu drivers on the VM and reboot the node. Validate gpu
drivers can be loaded successfully.
Priority:

1

Requirement:

unsupported_os[AlmaLinux, Oracle, Suse]

verify_gpu_cuda_with_pytorch()
Description:
This test case will run PyTorch to check CUDA driver installed correctly.
1. Install PyTorch.
2. Check GPU count by torch.cuda.device_count()
3. Compare with PCI result
Priority:

3

Requirement:

unsupported_os[AlmaLinux, Oracle, Suse]

verify_max_gpu_provision()
Description:
This test case verifies if multiple gpus are detected as PCI devices
Steps:
1. Boot VM with multiple GPUs
2. Verify if GPUs are detected as PCI Devices
3. Reboot VM
4. Verify if PCI GPU device count is same as earlier
Priority:

3

Requirement:

min_gpu_count=8

verify_gpu_adapter_count()
Description:
This test case verifies the gpu adapter count.
Steps:
1. Assert that node supports GPU.
2. If GPU modules are not loaded, install and load the module first.
3. Find the expected gpu count for the node.
4. Validate expected and actual gpu count using lsvmbus output.
5. Validate expected and actual gpu count using lspci output.
6. Validate expected and actual gpu count using gpu vendor commands
example - nvidia-smi
Priority:

2

Requirement:

unsupported_os[AlmaLinux, Oracle, Suse]

verify_gpu_rescind_validation()
Description:
This test case will
1. Validate disabling GPU devices.
2. Validate enable back the disabled GPU devices.
Priority:

2

Requirement:

supported_features

verify_gpu_extension_installation()
Description:
This test case verifies if gpu drivers are installed using extension.
Steps:
1. Install the GPU Driver using Extension.
2. Reboot and check for kernel panic
3. Validate gpu drivers can be loaded successfully.
Priority:

2

Requirement:

unsupported_os[AlmaLinux, Oracle, Suse]

verify_gpu_provision()
Description:
This test case verifies if gpu is detected as PCI device
Steps:
1. Boot VM with at least 1 GPU
2. Verify if GPU is detected as PCI Device
3. Reboot VM
4. Verify if PCI GPU device count is same as earlier
Priority:

1

Requirement:

min_gpu_count=1

class LibbpfToolsSuite
Description:
This test suite validates libbpf-tools package functionality.
libbpf-tools provides eBPF-based observability tools for performance
analysis and troubleshooting.
Platform:

Azure, Ready

Area:

bpf

Category:

functional

verify_libbpf_tools_binaries_executable()
Description:
This test case verifies that key libbpf-tools binaries can be
executed successfully.
Steps:
1. Ensure libbpf-tools package is installed.
2. Test execsnoop tool (traces exec() syscalls).
3. Test opensnoop tool (traces open() syscalls).
4. Test biolatency tool (block I/O latency histogram).
5. Verify each tool can run and produce help output.
Priority:

2

verify_libbpf_tools_package_available()
Description:
This test case verifies that the libbpf-tools package is available
and can be installed on the system.
Steps:
1. Check if libbpf-tools package exists in repositories.
2. Install the package if not already installed.
3. Verify installation was successful.
Priority:

2

class BpfSuite
Description:
This test suite is to confirm bpf support.
Platform:

Azure, Ready

Area:

bpf

Category:

functional

verify_btf_sysfs_exists()
Description:
This test case checks for the presences of the btf sysfs.
It checks if the /sys/kernel/btf/vmlinux file exists and if any loaded kernel
modules have corresponding entries in the /sys/kernel/btf directory.
If both conditions are met, it confirms that BTF (BPF Type Format) data is
available on the system.
Priority:

3

class KVMPerformance
Description:
This test suite is to validate performance of nested VM using FIO tool.
Platform:

Azure, Ready

Area:

nested

Category:

performance

perf_nested_kvm_storage_multidisk()
Description:
This test case is to validate performance of nested VM using fio tool with raid0
configuration of 6 l1 data disk attached to the l2 VM.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_nested_hyperv_storage_multidisk()
Description:
This test case is to validate performance of nested VM using fio tool with raid0
configuration of 6 l1 data disk attached to the l2 VM.
Priority:

3

Requirement:

supported_features[NestedVirtualization]

perf_nested_kvm_ntttcp_private_bridge()
Description:
This test case runs ntttcp test on two nested VMs on same L1 guest
connected with private bridge
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_nested_kvm_ntttcp_different_l1_nat()
Description:
This script runs ntttcp test on two nested VMs on different L1 guests
connected with NAT
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_nested_hyperv_ntttcp_different_l1_nat()
Description:
This script runs ntttcp test on two nested VMs on different L1 guests
connected with NAT
Priority:

3

Requirement:

supported_features[NestedVirtualization]

perf_nested_kvm_storage_singledisk()
Description:
This test case is to validate performance of nested VM using fio tool
with single l1 data disk attached to the l2 VM.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_nested_kvm_netperf_pps_nat()
Description:
This script runs netperf test on two nested VMs on different L1 guests
connected with NAT
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_nested_hyperv_storage_singledisk()
Description:
This test case is to validate performance of nested VM in hyper-v
using fio tool with single l1 data disk attached to the l2 VM.
Priority:

3

Requirement:

supported_features[NestedVirtualization]

class StoragePerformance
Description:
This test suite is to validate premium SSD data disks performance of Linux VM using
fio tool.
Platform:

Azure, Ready

Area:

storage

Category:

performance

perf_standardssd_datadisks_4k()
Description:
This test case uses fio to test data disk performance with 4K block size.
Priority:

3

Requirement:

disk

perf_premium_datadisks_1024k()
Description:
This test case uses fio to test data disk performance using 1024K block size
using libaio as ioengine.
Priority:

3

Requirement:

disk

perf_premiumv2_datadisks_1024k()
Description:
This test case uses fio to test premiumV2 disk performance using
1024K block size.
Priority:

3

Requirement:

supported_features

perf_standardssd_datadisks_1024k()
Description:
This test case uses fio to test data disk performance using 1024K block size.
Priority:

3

Requirement:

disk

perf_premium_datadisks_4k_io_uring()
Description:
This test case uses fio to test premium data disk performance with 4K block size
using io_uring as io engine.
Priority:

3

Requirement:

disk

perf_storage_over_nfs_sriov_tcp_4k()
Description:
This test case uses fio to test performance of nfs server over TCP with
VM’s initialized with SRIOV network interface.
Priority:

3

Requirement:

network_interface

perf_storage_over_nfs_synthetic_tcp_4k()
Description:
This test case uses fio to test performance of nfs server over TCP with
VM’s initialized with synthetic network interface.
Priority:

3

Requirement:

network_interface

perf_storage_generic_fio_test()
Description:
This test case uses fio to test data disk performance.
This will give flexibility to run FIO by runbook param.
If nothing is passed, it will run FIO with default param.
There is no system resource info on FIO-Man-page, FIO-readdocs.
We have faced OOM with 512 MB memory.
We deploy host azure VM with 64 GB in pipeline.
So, Keeping memory need as 2 GB.
Priority:

3

Requirement:

node

perf_resource_disk_1024k()
Description:
This testcase uses fio to test resource disk performance using 1024K block size.
Priority:

3

Requirement:

disk

perf_premiumv2_datadisks_4k()
Description:
This test case uses fio to test premiumV2 disk performance with 4K block size.
Priority:

3

Requirement:

supported_features

perf_premium_datadisks_4k()
Description:
This test case uses fio to test premium data disk performance with 4K block size
using libaio as ioengine.
Priority:

3

Requirement:

disk

perf_premium_datadisks_io()
Description:
This test case uses fio to test vm with 24 data disks.
Priority:

3

Requirement:

disk

perf_ultra_datadisks_4k()
Description:
This test case uses fio to test ultra disk performance with 4K block size.
Priority:

3

Requirement:

disk

perf_ultra_datadisks_1024k()
Description:
This test case uses fio to test ultra disk performance using 1024K block size.
Priority:

3

Requirement:

disk

perf_premium_datadisks_1024k_io_uring()
Description:
This test case uses fio to test premium data disk performance with 4K block size
using io_uring as io engine.
Priority:

3

Requirement:

disk

perf_storage_over_nfs_synthetic_udp_4k()
Description:
This test case uses fio to test performance of nfs server over UDP with
VM’s initialized with synthetic network interface.
Priority:

3

Requirement:

network_interface

perf_resource_disk_4k()
Description:
This test case uses fio to test resource disk performance using 4K block size.
Priority:

3

Requirement:

disk

perf_storage_over_nfs_sriov_udp_4k()
Description:
This test case uses fio to test performance of nfs server over UDP with
VM’s initialized with SRIOV network interface.
Priority:

3

Requirement:

network_interface

class NetworkPerformance
Description:
This test suite is to validate linux network performance
for various NIC passthrough scenarios.
Platform:

Azure, Ready

Area:

network passthrough

Category:

performance

perf_tcp_max_pps_passthrough_host_guest()
Description:
This test case uses sar to test passthrough network PPS (Packets Per Second)
when running netperf with multiple ports. Run netperf client on VM
and server on physical host.
Priority:

3

Requirement:

unsupported_os[Windows]

perf_udp_1k_ntttcp_passthrough_two_guest()
Description:
This test case uses ntttcp to test passthrough udp network throughput
between two guest VMs.
Priority:

3

Requirement:

supported_platform_type

perf_tcp_iperf_passthrough_host_guest()
Description:
This test case uses iperf3 to test passthrough tcp network throughput.
Run iperf server on physical server and client on VM
Priority:

3

Requirement:

unsupported_os[Windows]

perf_tcp_ntttcp_passthrough_host_guest()
Description:
This test case uses ntttcp to test tcp network throughput.
We will run nttcp server of physical host and client on VM
Priority:

3

Requirement:

supported_platform_type

perf_tcp_ntttcp_passthrough_two_guest()
Description:
This test case uses ntttcp to test passthrough tcp network throughput
between two guest VMs.
Priority:

3

Requirement:

supported_platform_type

perf_udp_iperf_passthrough_host_guest()
Description:
This test case uses iperf3 to test passthrough udp network throughput.
Run iperf server on physical host and client on vm with udp mode
Priority:

3

Requirement:

unsupported_os[Windows]

perf_tcp_iperf_passthrough_two_guest()
Description:
This test case uses iperf3 to test passthrough tcp network throughput.
Priority:

3

Requirement:

unsupported_os[Windows]

perf_udp_iperf_passthrough_two_guest()
Description:
This test case uses iperf3 to test passthrough udp network throughput.
Priority:

3

Requirement:

unsupported_os[Windows]

perf_tcp_single_pps_passthrough_host_guest()
Description:
This test case uses sar to test passthrough network PPS (Packets Per Second)
when running netperf with single port. Test will consider VM as
client node and physical host as server node.
Priority:

3

Requirement:

unsupported_os[Windows]

perf_tcp_single_pps_passthrough_two_guest()
Description:
This test case uses sar to test passthrough network PPS (Packets Per Second)
when running netperf with single port. Test will consider VM as
server node and host as client node.
Priority:

3

Requirement:

unsupported_os[Windows]

perf_tcp_max_pps_passthrough_two_guest()
Description:
This test case uses sar to test passthrough network PPS (Packets Per Second)
when running netperf with multiple ports. Test will consider VM as
server node and host as client node.
Priority:

3

Requirement:

unsupported_os[Windows]

perf_udp_1k_ntttcp_passthrough_host_guest()
Description:
This test case uses ntttcp to test passthrough udp network throughput.
Priority:

3

Requirement:

supported_platform_type

class NvmePerformace
Description:
This test suite is to validate NVMe disk performance of Linux VM using fio tool.
Platform:

Azure, Ready

Area:

nvme

Category:

performance

perf_nvme()
Description:
This test case uses fio to test NVMe disk performance
using ‘libaio’ as ioengine
Priority:

3

Requirement:

supported_features

perf_nvme_io_uring()
Description:
This test case uses fio to test NVMe disk performance
using ‘io_uring’ as ioengine.
Priority:

3

Requirement:

supported_features[Nvme]

class NetworkPerformace
Description:
This test suite is to validate linux network performance.
Platform:

Azure, Ready

Area:

network

Category:

performance

perf_tcp_iperf_synthetic()
Description:
This test case uses iperf3 to test synthetic tcp network throughput.
Priority:

3

Requirement:

network_interface

perf_sockperf_latency_udp_synthetic()
Description:
This test case uses sockperf to test synthetic network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_tcp_ntttcp_sriov()
Description:
This test case uses ntttcp to test sriov tcp network throughput.
Priority:

3

Requirement:

node

perf_sockperf_latency_udp_synthetic_busy_poll()
Description:
This test case uses sockperf to test synthetic network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_tcp_ntttcp_synthetic()
Description:
This test case uses ntttcp to test synthetic tcp network throughput.
Priority:

3

Requirement:

node

perf_udp_1k_ntttcp_synthetic()
Description:
This test case uses ntttcp to test synthetic udp network throughput.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_tcp_single_pps_synthetic()
Description:
This test case uses sar to test synthetic network PPS (Packets Per Second)
when running netperf with single port.
Priority:

3

Requirement:

network_interface

perf_tcp_ntttcp_128_connections_synthetic()
Description:
This test case uses ntttcp to test synthetic tcp network throughput for
128 connections.
Priority:

2

Requirement:

network_interface

perf_tcp_max_pps_sriov()
Description:
This test case uses sar to test sriov network PPS (Packets Per Second)
when running netperf with multiple ports.
Priority:

3

Requirement:

network_interface

perf_sockperf_latency_tcp_synthetic_busy_poll()
Description:
This test case uses sockperf to test synthetic network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_tcp_latency_synthetic()
Description:
This test case uses lagscope to test synthetic network latency.
Priority:

2

Requirement:

network_interface

perf_udp_1k_ntttcp_sriov()
Description:
This test case uses ntttcp to test sriov udp network throughput.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_sockperf_latency_tcp_sriov_busy_poll()
Description:
This test case uses sockperf to test sriov network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_tcp_single_pps_sriov()
Description:
This test case uses sar to test sriov network PPS (Packets Per Second)
when running netperf with single port.
Priority:

3

Requirement:

network_interface

perf_sockperf_latency_tcp_synthetic()
Description:
This test case uses sockperf to test synthetic network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_tcp_latency_sriov()
Description:
This test case uses lagscope to test sriov network latency.
Priority:

2

Requirement:

network_interface

perf_sockperf_latency_udp_sriov_busy_poll()
Description:
This test case uses sockperf to test sriov network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_sockperf_latency_udp_sriov()
Description:
This test case uses sockperf to test sriov network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_sockperf_latency_tcp_sriov()
Description:
This test case uses sockperf to test sriov network latency.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_udp_iperf_sriov()
Description:
This test case uses iperf to test sriov udp network throughput.
Priority:

3

Requirement:

network_interface

perf_tcp_max_pps_synthetic()
Description:
This test case uses sar to test synthetic network PPS (Packets Per Second)
when running netperf with multiple ports.
Priority:

3

Requirement:

network_interface

perf_tcp_iperf_sriov()
Description:
This test case uses iperf3 to test sriov tcp network throughput.
Priority:

3

Requirement:

network_interface

perf_udp_iperf_synthetic()
Description:
This test case uses iperf to test synthetic udp network throughput.
Priority:

3

Requirement:

network_interface

class PerfToolSuite
Description:
This test suite is to generate performance data with perf tool.
Platform:

Azure, Ready

Area:

perf_tool

Category:

performance

perf_epoll()
Description:
This test case uses perf tool to measure the epoll performance.
The steps are:
1. Run perf epoll benchmark 20 times.
3. Calculate the average, min, max operations of the 20 runs.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

perf_messaging()
Description:
This test case uses perf tool to measure the messaging performance.
The steps are:
1. Run perf messaging benchmark 20 times.
3. Calculate the average, min, max time of the 20 runs.
Priority:

3

Requirement:

unsupported_os[BSD, Windows]

class LibvirtTckSuite
Description:
Runs the libvirt TCK (Technology Compatibility Kit) tests. It is a suite
of functional/integration tests designed to test a libvirt driver’s complicance
with API semantics, distro configuration etc.
More info: https://gitlab.com/libvirt/libvirt-tck/-/blob/master/README.rst
Platform:

Azure, Ready

Area:

libvirt

Category:

community

verify_libvirt_tck()
Description:
Runs the Libvirt TCK (Technology Compatibility Kit) tests with the default
configuration i.e. the tests will exercise the qemu driver in libvirt.
Priority:

3

class Utilities
Description:
This suite includes utility test cases and not validations.
Platform:

Azure, Ready

Area:

utility

Category:

functional

utility_tools_install()
Description:
This test case will install the tools
passed as parameter ‘case_tool_install’
Priority:

5

class MshvHostInstallSuite
Description:
This test suite is to test VM working well after updating Microsoft Hyper-V on VM
and rebooting.
Platform:

Azure, Ready

Area:

mshv

Category:

functional

verify_mshv_install_succeeds()
Description:
This test case will
1. Update to new MSHV components over old ones in a
pre-configured MSHV image
2. Reboot VM, check that mshv comes up
The test expects the directory containing MSHV binaries to be passed in
the mshv_binpath variable.
Priority:

2

class Dom0SecureBootTestSuite
Description:
This test suite covers the secure boot flow for
Dom0 AzureLinux nodes.
Platform:

Azure, Ready

Area:

mshv

Category:

functional

verify_mshv_secure_boot_succeeds()
Description:
This test verifies secure boot succeeds
on an Azure Linux Dom0 node.
Steps:
1. On first boot, install the Dom0 components
(e.g. kernel-mshv, mshv, mshv-bootloader-lx, hvloader)
2. Reboot the VM (The Dom0 components should be loaded)
3. Await the VM to be ready by checking TCP port connectivity
4. Verify that secure boot is enabled by checking
journalctl for “Secure boot enabled”
5. Verify that the Dom0 stack is NOT running by checking
journalctl for “Hyper-V: running as root partition”
NOTE: The Dom0 stack is currently not secure boot signed,
so it will not run in secure boot mode.
Priority:

2

Requirement:

supported_platform_type[AZURE]

class MshvHostStressTestSuite
Description:
This test suite contains tests that are meant to be run on the
Microsoft Hypervisor (MSHV) root partition.
Platform:

Azure, Ready

Area:

mshv

Category:

stress

stress_mshv_vm_create()
Description:
Stress the MSHV virt stack by repeatedly creating and destroying
multiple VMs in parallel. By default creates VMs with 1 vCPU and
1 GiB of RAM each. Number of VMs createdis equal to the number of
CPUs available on the host. By default, the test is repeated 25
times. All of these can be configured via the variable
“mshv_vm_create_stress_configs” in the runbook.
Priority:

4

class MshvHostTestSuite
Description:
This test suite contains tests that should be run on the
Microsoft Hypervisor (MSHV) root partition. This test suite contains tests
to check health of mshv root node.
Platform:

Azure, Ready

Area:

mshv

Category:

functional

verify_mshvlog_is_active()
Description:
With mshv_diag module loaded, ensure mshvlog.service starts and runs
successfully on MSHV root partitions. Also confirm there are no errors
reported by mshv_diag module in dmesg.
Lastly, check if logfile from mshvlog.service is not empty.
Priority:

4

verify_mshvtrace_tool()
Description:
Ensure mshvtrace tool is present, can be executed, and produces
output on the MSHV root partition.
The test checks:
1. mshvtrace binary exists and is executable
2. Running mshvtrace with –help returns expected output
3. Running mshvtrace for a short duration produces a non-empty trace file
Priority:

4

verify_mshv_crash()
Description:
This test case will
1. Remove lockdown=integrity from the dom0 boot config if present
2. Configure kdump and reboot the VM into the regular FRE hypervisor build
3. Generate a crash by writing a magic value to the mshv hvdbg debugfs node
(/sys/kernel/debug/mshv/hvdbg) and verify that a kdump is produced
Priority:

2

class CdromSuite
Description:
Tests to check the behavior of the virtual cdrom device in VMs.
Platform:

Azure, Ready

Area:

cdrom

Category:

functional

verify_cdrom_device_status_code()
Description:
Test to check the installation ISO is unloaded
after provisioning and rebooting a new VM.
Priority:

2

Requirement:

supported_platform_type[AZURE, HYPERV]

class AzureDiskEncryption
Description:
Tests for the Azure Disk Encryption (ADE) extension
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_azure_disk_encryption_provisioned()
Description:
Runs the ADE extension and verifies the extension
provisioned successfully on the remote machine.
Priority:

1

Requirement:

supported_platform_type[AZURE]

verify_azure_disk_encryption_enabled()
Description:
Runs the ADE extension and verifies it
fully encrypted the remote machine successfully.
Priority:

3

Requirement:

min_core_count=4

class LinuxPatchExtensionBVT
Description:
Test for Linux Patch Extension
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_vm_assess_patches()
Description:
Verify walinuxagent or waagent service is running on vm. Perform assess
patches to trigger Microsoft.CPlat.Core.LinuxPatchExtension creation in
vm. Verify status file response for validity.
Priority:

1

verify_vm_install_patches()
Description:
Verify walinuxagent or waagent service is running on vm. Perform
install patches to trigger Microsoft.CPlat.Core.LinuxPatchExtension
creation in vm.
Verify status file response for validity.
Priority:

3

class VmSnapsotLinuxBVTExtension
Description:
Test for VMSnapshot extension
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_vmsnapshot_extension()
Description:
Create a restore point collection for the virtual machine.
Create application consistent restore point on the restore point
collection.
Validate response of the restore point for validity.
Attempt it a few items to rule out cases when VM is under changes.
Priority:

1

Requirement:

supported_features[AzureExtension]

verify_exclude_disk_support_restore_point()
Description:
Runs a script on the VM
The script takes the responsibility of distinguishing the various ditros into
supported or unsupported for selective billing feature.
The test would be passed in both the cases, just that the information helps in
clearly classifying the distro, when the test runs on various distros.
Priority:

2

Requirement:

unsupported_os[BSD, Windows]

class MetricsExtension
Description:
This test is a BVT for MDM MetricsExtension
Platform:

Azure, Ready

Area:

MetricsExtension

Category:

functional

verify_metricsextension()
Description:
Verify whether MetricsExtension is installed, running,
and uninstalled successfully
Priority:

1

Requirement:

supported_platform_type[AZURE, READY]

class ApplicationHealthExtension
Description:
Tests for the Application Health Extension (AHE) on Linux
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_application_health_extension()
Description:
Installs and verifies the Application Health Extension (AHE).
Checks logs for expected message.
Deletes the VM Extension.
Priority:

1

Requirement:

supported_features[AzureExtension]

class AzurePerformanceDiagnostics
Description:
Tests for the Azure Performance Diagnostics VM Extension
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_azure_performance_diagnostics()
Description:
Installs and runs the Azure Performance Diagnostics VM Extension.
Verifies a report was created and uploaded to the storage account.
Deletes the VM Extension.
Downgrading priority from 1 to 5. The extension relies on the
storage account key, which we cannot use currently.
Will change it back once the extension works with MSI.
Priority:

5

Requirement:

supported_features[AzureExtension]

class GenericVmExtension
Description:
Generic test for validating VM extension install and uninstall. Extension publisher, type, and version are provided via runbook variables.
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_vm_extension_install_uninstall()
Description:
Generic test case that installs a VM extension specified via runbook
variables, verifies provisioning succeeds, uninstalls the extension,
and confirms the VM is still reachable afterwards.
Required runbook variables:
- extension_publisher (e.g. “Microsoft.Azure.Monitor”)
- extension_type (e.g. “AzureMonitorLinuxAgent”)
- extension_version (e.g. “1.0”)
Priority:

3

Requirement:

unsupported_os

class AzureKeyVaultExtensionBvt
Description:
BVT for Azure Key Vault Extension
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_key_vault_extension()
Description:
The following test case validates the Azure Key Vault Linux
* Extension while creating the following resources:
* A Key Vault
* Two certificates in the Key Vault
* Retrieval of the certificate’s secrets
through SecretClient class from Azure SDK.
* Installation of the Azure Key Vault Linux Extension on the VM.
* Installation of the certs through AKV extension
* Rotation of the certificates
* Printing the cert after rotation from the VM
* Deletion of the resources
Priority:

1

Requirement:

supported_features[AzureExtension]

class AzureMonitorAgentLinuxExtension
Description:
Tests for the Azure Monitor Agent Linux VM Extension
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_azuremonitoragent_linux()
Description:
Installs and runs the Azure Monitor Agent Linux VM Extension.
Deletes the VM Extension.
Priority:

1

Requirement:

supported_features[AzureExtension]

class AzSecPack
Description:
BVT for Azure Security Pack.
Azure Security Pack includes core security features that provide security logging
and monitoring coverage for the service.
This test suite validate if Azure security pack can be installed, uninstalled
successfully, and check if the autoconfig is configured successfully.
This test requires your subscription is within AutoConfig scope. It manually enables
the AzSecPack AutoConfig on the Linux VM. The steps are:
1. Add resource tag for AzSecPack
2. Create an assign user assigned managed identity AzSecPack to the VM
3. Add Azure VM extensions for AMA and ASA to the VM
If the subscription is within AutoConfig scope, the AutoCoonfig onboarding method
is recommended. It needs adding resoure tag for AzSecPack, creating and assigning
UserAssigned Managed Identity AzSecPack AutoConfig to the ARM resources.
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_azsecpack()
Description:
Verify whether Azure security pack can be installed, uninstalled
successfully, and check if the autoconfig is configured successfully.
Priority:

1

Requirement:

unsupported_os[BSD]

class CVTTest
Description:
This test is used to validate the functionality of ASR driver.
Platform:

Azure, Ready

Area:

cvt

Category:

functional

verify_asr_by_cvt()
Description:
this test validate the functionality of ASR driver by verifying
integrity of a source disk with respect to a target disk
Downgrade the case priority from 3 to 5 for its instability.
Priority:

5

Requirement:

disk

verify_asr_by_cvt_no_extension()
Description:
Validate ASR driver functionality without using VM extensions.
Downloads driver tarball and CVT binaries directly, loads driver
via insmod, and runs the CVT test suite. If the driver is already
loaded, skips driver download and installation.
Priority:

3

Requirement:

disk

class NetworkWatcherExtension
Description:
Tests for the Azure Network Watcher VM Extension
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_azure_network_watcher()
Description:
Installs and runs the Azure Network Watcher VM Extension.
Deletes the VM Extension.
Priority:

1

Requirement:

supported_features[AzureExtension]

class WaAgentBvt
Description:
BVT for VM Agent
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_vm_agent()
Description:
Runs the custom script extension and verifies it executed on the
remote machine.
Priority:

1

Requirement:

unsupported_os[FreeBSD]

class CustomScriptTests
Description:
This test suite tests the functionality of the Custom Script VM extension.
File uri is a public Azure storage blob uri unless mentioned otherwise.
File uri points to a linux shell script unless mentioned otherwise.
It has 12 test cases to verify if CSE runs as intended when provided:
1. File uri and command in public settings
2. Two file uris and command for downloading second script in public settings
3. File uri and command in both public and protected settings (should fail)
4. File uri without a command or base64 script (should fail)
5. Both base64 script and command in public settings (should fail)
6. File uri and base64 script in public settings
7. File uri and gzip’ed base64 script in public settings
8. File uri and command in protected settings
9. Private file uri without sas token or credentials (should fail)
10. Private file uri with storage account credentials
11. Private sas file uri and command in public settings
12. File uri (pointing to python script) and command in public settings
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_public_script_run()
Description:
Runs the Custom Script VM extension with a public Azure storage file uri.
Downgrading priority from 1 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_second_public_script_run()
Description:
Runs the Custom Script VM extension with 2 public file uris passed in
and second script being run. Verifies second script created.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_script_in_both_settings_failed()
Description:
Runs the Custom Script VM extension with public file uri and command
in both public and protected settings.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_base64_script_with_command_run()
Description:
Runs the Custom Script VM extension with a base64 script
and command with no file uris.
Priority:

3

verify_public_script_protected_settings_run()
Description:
Runs the Custom Script VM extension with public file uri and command in
protected settings.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_public_script_with_base64_script_run()
Description:
Runs the Custom Script VM extension with a base64 script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_public_python_script_run()
Description:
Runs the Custom Script VM extension with a public Azure storage file uri
pointing to a python script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_private_sas_script_run()
Description:
Runs the Custom Script VM extension with private Azure storage file uri
with a sas token.
Priority:

3

verify_public_script_without_command_run()
Description:
Runs the Custom Script VM extension without a command and a script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_private_script_with_storage_credentials_run()
Description:
Runs the Custom Script VM extension with private Azure storage file uri
without a sas token but with storage account credentials.
Downgrading priority from 3 to 5. The extension relies on the
storage account key, which we cannot use currently.
Priority:

5

verify_public_script_with_gzip_base64_script_run()
Description:
Runs the Custom Script VM extension with a gzip’ed base64 script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_private_script_without_sas_run_failed()
Description:
Runs the Custom Script VM extension with private Azure storage file uri
without a sas token.
Priority:

3

class RunCommandV1Tests
Description:
This test suite tests the functionality of the Run Command v1 VM extension.
** Same set of tests as CSE **
It has 12 test cases to verify if RCv1 runs successfully when provided:
1. File uri and command in public settings
2. Two file uris and command for downloading second script in settings
3. File uri and command in both public and protected settings (should fail)
4. File uri without a command or base64 script (should fail)
5. Both base64 script and command in public settings (should fail)
6. File uri and base64 script in public settings
7. File uri and gzip’ed base64 script in public settings
8. File uri and command in protected settings
9. Private file uri without sas token or credentials (should fail)
10. Private file uri with storage account credentials
11. Private sas file uri and command in public settings
12. File uri (pointing to python script) and command in public settings
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_base64_script_with_command_run_failed()
Description:
Runs the Run Command v1 VM extension with a base64 script
and command with no file uris.
Priority:

3

verify_public_script_with_base64_script_run()
Description:
Runs the Custom Script VM extension with a base64 script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_public_script_protected_settings_run()
Description:
Runs the Run Command v1 VM extension with public file uri and command in
protected settings.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_private_script_without_sas_run_failed()
Description:
Runs the Run Command v1 VM extension with private Azure storage file uri
without a sas token.
Priority:

3

verify_script_in_both_settings_failed()
Description:
Runs the Run Command v1 VM extension with public file uri and command
in both public and protected settings.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_public_script_without_command_run_failed()
Description:
Runs the Run Command v1 VM extension without a command and a script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_private_script_with_storage_credentials_run()
Description:
Runs the Run Command v1 VM extension with private Azure storage file uri
without a sas token but with storage account credentials.
Downgrading priority from 3 to 5. The extension relies on the
storage account key, which we cannot use currently.
Priority:

5

verify_private_sas_script_run()
Description:
Runs the Run Command v1 VM extension with private Azure storage file uri
with a sas token.
Priority:

3

verify_public_python_script_run()
Description:
Runs the Run Command v1 VM extension with a public Azure storage file uri
pointing to a python script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_second_public_script_run()
Description:
Runs the Run Command v1 VM extension with 2 public file uris passed in
and second script being run. Verifies second script created.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_public_script_with_gzip_base64_script_run()
Description:
Runs the Run Command v1 VM extension with a gzip’ed base64 script.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_public_script_run()
Description:
Runs the Run Command v2 VM extension with a public Azure storage file uri.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

class VMAccessTests
Description:
This test suite tests the functionality of the VMAccess VM extension.
Settings are protected unless otherwise mentioned.
OpenSSH format public keys correspond to ssh-rsa keys.
It has 8 test cases to verify if VMAccess runs successfully when provided:
1. Username and password
2. Username and OpenSSH format public key
3. Username with both a password and OpenSSH format public key
4. Username with no password or ssh key (should fail)
5. Username and certificate containing public ssh key in pem format
6. Username and SSH2 format public key
7. Username to remove
8. Username, OpenSSH format public key, and valid expiration date
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_remove_username_run()
Description:
Runs the VMAccess VM extension with a username to remove.
Priority:

3

verify_no_password_and_ssh_key_run_failed()
Description:
Runs the VMAccess VM extension without a password and OpenSSH public key.
Priority:

3

verify_ssh2_key_run()
Description:
Runs the VMAccess VM extension with an SSH2 public key.
Priority:

3

verify_valid_password_run()
Description:
Runs the VMAccess VM extension with a valid username and password.
Priority:

1

verify_openssh_key_run()
Description:
Runs the VMAccess VM extension with an OpenSSH public key.
Priority:

3

verify_valid_expiration_run()
Description:
Runs the VMAccess VM extension with an OpenSSH public key
and valid expiration date.
Priority:

3

verify_password_and_ssh_key_run()
Description:
Runs the VMAccess VM extension with both a password and OpenSSH public key.
Priority:

3

verify_pem_certificate_ssh_key_run()
Description:
Runs the VMAccess VM extension with a certificate containing a public ssh key
in pem format.
Priority:

3

class RunCommandV2Tests
Description:
This test suite tests the functionality of the Run Command v2 VM extension.
It has 12 test cases to verify if RCv2 runs successfully when provided:
1. Pre-existing available script hardcoded in CRP
2. Custom shell script
3. Script with a named parameter
4. Script with an unnamed parameter
5. Script with a named protected parameter
6. Public storage blob uri that points to the script
7. Storage uri pointing to script without a sas token (should fail)
8. Storage sas uri that points to script
9. Command with a timeout of 1 second (should pass)
10. Command that should take longer than 1 second, but with a
timeout of 1 second (should fail)
11. Provided a different valid user to run a command with
12. Provided a different invalid user to run a command with (should fail)
Platform:

Azure, Ready

Area:

vm_extension

Category:

functional

verify_sas_uri_script_run()
Description:
Runs the Run Command v2 VM extension with a storage sas uri pointing
to the script in blob storage.
Priority:

3

verify_public_uri_script_run()
Description:
Runs the Run Command v2 VM extension with a public uri pointing to the
script in blob storage.
Downgrading priority from 3 to 5. Due to the requirement for blob public access,
which is restricted for security reasons.
Priority:

5

verify_script_run_with_valid_user()
Description:
Runs the Run Command v2 VM extension with a different valid user on the VM.
Priority:

3

verify_script_run_with_unnamed_parameter()
Description:
Runs the Run Command v2 VM extension with an unnamed public parameter
passed to a custom shell script.
Priority:

3

verify_private_uri_script_run_failed()
Description:
Runs the Run Command v2 VM extension with a private storage uri pointing
to the script in blob storage. No sas token provided, should fail.
Priority:

3

verify_script_run_with_timeout()
Description:
Runs the Run Command v2 VM extension with a timeout of 0.1 seconds.
Priority:

3

verify_script_run_with_invalid_user()
Description:
Runs the Run Command v2 VM extension with a different invalid user on the VM.
Priority:

3

verify_script_run_with_timeout_failed()
Description:
Runs the Run Command v2 VM extension with a timeout of 1 second.
Priority:

3

verify_existing_script_run()
Description:
Runs the Run Command v2 VM extension with a pre-existing ifconfig script.
Priority:

1

verify_custom_script_run()
Description:
Runs the Run Command v2 VM extension with a custom shell script.
Priority:

3

verify_script_run_with_named_parameter()
Description:
Runs the Run Command v2 VM extension with a named public parameter
passed to a custom shell script.
Priority:

3

verify_script_run_with_protected_parameter()
Description:
Runs the Run Command v2 VM extension with a named protected parameter
passed to a custom shell script.
Priority:

3

class KselftestTestsuite
Description:
This test suite is used to run kselftests.
Platform:

Azure, Ready

Area:

kselftest

Category:

community

verify_kselftest()
Description:
This test case runs linux kernel self tests on Mariner VMs.
Cases:
1. When a tarball is specified in .yml file, extract the tar and run kselftests.
Example:
- name: kselftest_file_path
value: <path_to_kselftests.tar.xz>
is_case_visible: true
2. When a tarball is not specified in .yml file, clone Mariner kernel,
copy current config to .config, build kselftests and generate a tar.
For both cases, verify that the kselftest tool extracts the tar, runs the script
run_kselftest.sh and redirects test results to a file kselftest-results.txt.
Customization:
Users can customize the test by specifying the
kselftest_include_test_collections and kselftest_skip_tests variables
in the runbook. For example:
- kselftest_include_test_collections: A comma-separated list of collections
to run (e.g., “bpf,net,timers”).
- kselftest_skip_tests: A comma-separated list of tests to skip
(e.g., “net:test_tcp,test_udp”).
Priority:

3

Requirement:

min_core_count=16

class CloudHypervisorTestSuite
Description:
This test suite is for executing the tests maintained in the
upstream cloud-hypervisor repo.
Platform:

Azure, Ready

Area:

cloud-hypervisor

Category:

community

verify_cloud_hypervisor_live_migration_tests()
Description:
Runs cloud-hypervisor live migration tests.
Priority:

3

Requirement:

node

verify_cloud_hypervisor_performance_metrics_tests()
Description:
Runs cloud-hypervisor performance metrics tests.
Priority:

3

verify_cloud_hypervisor_integration_tests()
Description:
Runs cloud-hypervisor integration tests.
Priority:

3

Requirement:

node

class SanitySuite
Description:
Basic sanity checks to ensure the test VM is not compromised when using non-marketplace images.
Platform:

Azure, Ready

Area:

sanity

Category:

functional

verify_vm_not_compromised()
Description:
Run comprehensive integrity checks only on non-marketplace images to detect obvious compromise indicators including: unsafe file permissions, missing critical files, SSH security issues, and user account anomalies. All checks are conservative to avoid false positives.
Priority:

3

Requirement:

supported_platform_type[AZURE]

class StressNgTestSuite
Description:
A suite for running the various classes of stressors provided
by stress-ng.
Platform:

Azure, Ready

Area:

stress-ng

Category:

stress

stress_ng_memory_stressors()
Description:
Runs stress-ng’s ‘memory’ class stressors for 60s each.
Priority:

4

stress_ng_vm_stressors()
Description:
Runs stress-ng’s ‘vm’ class stressors for 60s each.
Priority:

4

stress_ng_io_stressors()
Description:
Runs stress-ng’s ‘io’ class stressors for 60s each.
Priority:

4

stress_ng_network_stressors()
Description:
Runs stress-ng’s ‘network’ class stressors for 60s each.
Priority:

4

multi_vm_stress_test()
Description:
Multi-VM stress test using stress-ng jobfiles.
Executes stress-ng jobfiles across multiple VMs
(VMs are deployed via runbook configuration).
Each VM in the environment runs the specified stress-ng jobfiles
to stress host CPU and memory resources simultaneously.
Required runbook variables:
- stress_ng_jobs: Jobfile(s) to execute on each VM
Optional runbook variables for VM deployment:
- stress_ng_node_count: Number of VMs to deploy
- stress_ng_cpu_count: CPU cores per VM
- stress_ng_memory_mb: Memory per VM in MB
Note: This test requires an environment with at least 2 nodes for
meaningful multi-VM stress testing.
Priority:

4

Requirement:

min_memory_mb=1024

stress_ng_cpu_stressors()
Description:
Runs stress-ng’s ‘cpu’ class stressors for 60s each.
Priority:

4

stress_ng_jobfile()
Description:
Runs a stress-ng jobfile. The path to the jobfile must be specified
using a runbook variable named “stress_ng_jobs”. For more info about
jobfiles refer:
https://manpages.ubuntu.com/manpages/jammy/man1/stress-ng.1.html
Priority:

5

class TlbStressTestSuite
Description:
TLB (Translation Lookaside Buffer) stress testing suite.
This test suite focuses on creating intensive TLB pressure to reveal
performance degradation under heavy virtual memory operations.
TLB stress testing is crucial for:
- Validating TLB performance under memory pressure scenarios
- Detecting performance regressions in virtual memory subsystems
- Stress testing VM environments with intensive memory operations
- Benchmarking TLB efficiency across different CPU architectures
The suite combines custom TLB flush programs with stress-ng stressors
to create comprehensive TLB pressure through frequent memory
unmapping/remapping operations.
Platform:

Azure, Ready

Area:

mshv

Category:

stress

stress_tlb_basic()
Description:
Execute basic TLB stress test with custom memory pressure.
This test creates intensive TLB pressure through rapid memory
mapping/unmapping operations combined with stress-ng VM stressors.
Validates system stability under heavy TLB activity.
Priority:

4

Requirement:

min_memory_mb=1024

stress_tlb_stressng()
Description:
Comprehensive TLB stress test with performance monitoring.
This test combines custom TLB flush operations with stress-ng stressors
to create maximum TLB pressure while monitoring performance degradation.
Features baseline/stress comparison with configurable thresholds to detect
performance regressions in virtual memory subsystems.
Priority:

3

Requirement:

min_memory_mb=2048

class XdpFunctional
Description:
This test suite is to validate XDP functionality.
Platform:

Azure, Ready

Area:

xdp

Category:

functional

verify_xdp_community_test()
Description:
It runs all tests of xdp-tools. Check the official site for more
details.
https://github.com/xdp-project/xdp-tools
Priority:

3

verify_xdp_with_different_mtu()
Description:
It validates XDP with different MTU
1. Check current image supports XDP or not.
2. change MTU to 1500, 2000, 3506 to test XDP.
Priority:

3

Requirement:

min_count=2

verify_xdp_multiple_nics()
Description:
It validates XDP with multiple nics.
1. Check current image supports XDP or not.
2. Install and validate xdpdump.
Priority:

3

Requirement:

min_nic_count=3

verify_xdp_action_drop()
Description:
It validates the XDP with action DROP.
1. start tcpdump with icmp filter.
2. start xdpdump.
3. run ping 5 times.
4. check tcpdump with 5 packets.
Priority:

2

Requirement:

min_count=2

verify_xdp_synthetic()
Description:
It validates the XDP works with Synthetic network.
The test step is the same as verify_xdp_basic, but it run once only.
Priority:

2

Requirement:

network_interface

verify_xdp_action_tx()
Description:
It validates the XDP with action TX.
1. start tcpdump with icmp filter.
2. start xdpdump.
3. run ping 5 times.
4. check tcpdump with 5 packets, because the icmp is replied in xdp
level.
Priority:

2

Requirement:

min_count=2

verify_xdp_basic()
Description:
It validates the basic functionality of XDP. It runs multiple times to
test the load/unload. It includes below steps,
1. Check current image supports XDP or not.
2. Install and validate xdpdump.
Priority:

1

verify_xdp_sriov_failsafe()
Description:
It validates the XDP works with Synthetic network when SRIOV is
disabled.
1. Test in SRIOV mode.
2. Disable the SRIOV.
3. Test in Synthetic mode.
Priority:

2

Requirement:

network_interface

verify_xdp_action_aborted()
Description:
It validates the XDP with action ABORT.
1. start tcpdump with icmp filter.
2. start xdpdump.
3. run ping 5 times.
4. check tcpdump with 5 packets.
Priority:

3

Requirement:

min_count=2

verify_xdp_remove_add_vf()
Description:
It validates the XDP works with VF hot add/remove from API.
1. Run xdp dump to drop and count packets.
2. Remove VF from API.
3. Run xdp dump to drop and count packets.
5. Add VF back from API.
6. Run xdp dump to drop and count packets.
Priority:

3

Requirement:

network_interface

class XdpPerformance
Description:
This test suite is to validate XDP performance.
Platform:

Azure, Ready

Area:

xdp

Category:

performance

perf_xdp_rx_drop_multithread_sriov()
Description:
This case tests the XDP drop performance by measuring Packets Per Second
(PPS) and received rate with multiple send threads.
* If the received packets rate is lower than 90% the test case fails.
* If the PPS is lower than 1M, the test case fails.
Priority:

3

Requirement:

network_interface

perf_xdp_ntttcp_latency()
Description:
This case compare and record latency impact of XDP component.
The test use ntttcp to send tcp packets. And then compare the latency
with/without XDP component. If the gap is more than 40%, the test case
fails.
Priority:

3

Requirement:

network_interface

perf_xdp_tx_forward_multicore_sriov()
Description:
This case tests the packet forwarded rate of XDP TX forwarding on the
multi core SRIOV networking.
Refer to perf_xdp_tx_forward_singlecore_synthetic for more details.
The threshold of this test is lower than standard, it’s 85%. Because the
UDP packets count is big in this test scenario, and easy to lost.
Priority:

3

Requirement:

network_interface

perf_xdp_tx_forward_singlecore_synthetic()
Description:
This case tests the packet forwarded rate of the XDP TX forwarding on
the single core Synthetic networking. The pktgen samples in Linux code
base is used to generate packets.
The minimum cpu count is 8, it makes sure the performance is won’t too
low.
Three roles in this test environment, 1) sender is to send packets, 2)
the forwarder is to forward packets to receiver, 3) and the receiver is
used to receive packets and drop.
Finally, it checks how many packets arrives to the forwarder or
receiver. If it’s lower than 90%, the test fails. Note, it counts the
rx_xdp_tx_xmit (mlx5), rx_xdp_tx (mlx4), or dropped count for synthetic
nic.
Priority:

3

Requirement:

network_interface

perf_xdp_tx_forward_multicore_synthetic()
Description:
This case tests the packet forwarded rate of XDP TX forwarding on the
multi core Syntethic networking.
Refer to perf_xdp_tx_forward_singlecore_synthetic for more details.
Priority:

3

Requirement:

network_interface

perf_xdp_tx_forward_singlecore_sriov()
Description:
This case tests the packet forwarded rate of XDP TX forwarding on the
single core SRIOV networking.
Refer to perf_xdp_tx_forward_singlecore_synthetic for more details.
Priority:

3

Requirement:

network_interface

perf_xdp_lagscope_latency()
Description:
This case compare and record latency impact of XDP component.
The test use lagscope to send tcp packets. And then compare the latency
with/without XDP component. If the gap is more than 40%, the test case
fails.
Priority:

3

Requirement:

network_interface

perf_xdp_rx_drop_singlethread_sriov()
Description:
This case tests the XDP drop performance by measuring Packets Per Second
(PPS) and received rate with single send thread.
see details from perf_xdp_rx_drop_multithread_sriov.
Priority:

3

Requirement:

network_interface

class KexecSuite
Description:
Test suite for kexec functionality.
Validates kernel’s ability to load and execute a new kernel
without going through BIOS/firmware reboot.
Platform:

Azure, Ready

Area:

kexec

Category:

functional

verify_kexec_reboot_direct()
Description:
Test kexec reboot via direct kexec -e command.
Validates raw kernel kexec execution without systemd involvement.
Tests the core kexec mechanism where the new kernel is executed
immediately without running shutdown scripts.
Priority:

3

verify_kexec_reboot_systemd()
Description:
End-to-end kexec reboot test.
Validates that the system can:
1. Load a new kernel image via kexec
2. Execute kexec reboot (bypassing firmware)
3. Successfully boot into the kexec’d kernel
4. Maintain system health after kexec reboot
This test verifies the core kexec functionality by performing
a controlled kernel-to-kernel reboot and validating the transition.
Priority:

3

class InfinibandSuite
Description:
Tests the functionality of infiniband.
Platform:

Azure, Ready

Area:

hpc

Category:

functional

verify_ping_pong()
Description:
This test case will
1. Identify the infiniband devices and their cooresponding network interfaces
2. Run several ping-pong tests to check RDMA / Infiniband functionality
Priority:

1

Requirement:

unsupported_os[BSD, Windows]

verify_open_mpi()
Description:
This test case will
1. Ensure RDMA is setup
2. Install Open MPI
3. Set up ssh keys of server/client connection
4. Run MPI pingpong tests
5. Run other MPI tests
Priority:

4

Requirement:

unsupported_os[BSD, Windows]

verify_hpc_over_sriov()
Description:
This test case will
1. Determine whether the VM has Infiniband over SR-IOV
2. Ensure waagent is configures with OS.EnableRDMA=y
3. Check that appropriate drivers are present
Priority:

2

Requirement:

unsupported_os[BSD, Windows]

verify_hpc_over_nd()
Description:
This test case will
1. Determine whether the VM has Infiniband over Network Direct
2. Ensure waagent is configures with OS.EnableRDMA=y
3. Check that appropriate drivers are present
Priority:

2

Requirement:

unsupported_os[BSD, Windows]

verify_mvapich_mpi()
Description:
This test case will
1. Ensure RDMA is setup
2. Install MVAPICH MPI
3. Set up ssh keys of server/client connection
4. Run MPI pingpong tests
5. Run other MPI tests
Priority:

4

Requirement:

unsupported_os[BSD, Windows]

verify_ibm_mpi()
Description:
This test case will
1. Ensure RDMA is setup
2. Install IBM MPI
3. Set up ssh keys of server/client connection
4. Run MPI pingpong tests
Priority:

4

Requirement:

unsupported_os[BSD, Windows]

verify_intel_mpi()
Description:
This test case will
1. Ensure RDMA is setup
2. Install Intel MPI
3. Set up ssh keys of server/client connection
4. Run MPI pingpong tests
5. Run other MPI tests
Priority:

4

Requirement:

unsupported_os[BSD, Windows]

verify_ib_naming()
Description:
This test case will
1. List all available network interfaces
2. Check if InfiniBand cards are present
3. Ensure the first InfiniBand card is named starting with “ib0”
Priority:

2

Requirement:

unsupported_os[BSD, Windows]

class CVMSuite
Description:
This test suite ensures correct configuration and allowed devices for CVM
Platform:

Azure, Ready

Area:

ACC_CVM

Category:

functional

verify_isolation_config()
Description:
This case verifies the isolation config on guest
Steps:
1. Call dmesg to get output
2. Find isolation config in output
3. Check to ensure config a is 0x1
4. Check to ensure config b is 0xba2
Priority:

1

Requirement:

supported_features

verify_lsvmbus()
Description:
This case verifies that lsvmbus only shows devices
that are allowed in a CVM guest
Steps:
1. Call lsvmbus
2. Iterate through list returned by lsvmbus to ensure all devices
listed are included in valid_class_ids
Priority:

1

Requirement:

supported_features

class ACCBasicTest
Description:
This Basic Validation Test (BVT) suite validates the availability of Secure Guard
Extensions (SGX) on a given
platform.
Platform:

Azure, Ready

Area:

ACC_BVT

Category:

functional

verify_sgx()
Description:
This case verifies if the VM is SGX Enabled.
Steps:
1. Add keys and tool chain from Intel-SGX, LLVM and Microsoft repositories.
2. Install DCAP driver if missing.
3. Install required package.
4. Run Helloworld and Remote Attestation tests.
Priority:

1

Requirement:

supported_features

class CVMAzureHostTestSuite
Description:
This test suite is for azure host vm pre-checks
for nested-cvm cases.
Platform:

Azure, Ready

Area:

cvm

Category:

functional

verify_azure_vm_snp_enablement()
Description:
Runs Dmesg tool to get kernel logs
and verify if azure vm is snp enabled.
Priority:

3

Requirement:

supported_features

class CVMBootTestSuite
Description:
This test suite covers some common scenarios related to
CVM boot on Azure.
Platform:

Azure, Ready

Area:

cvm

Category:

functional

verify_encrypted_root_partition()
Description:
This test verifies that TPM enrollment is done correctly on
a CVM with encrypted root partition
Priority:

2

Requirement:

supported_platform_type[AZURE]

verify_boot_success_after_component_upgrade()
Description:
This test case verifies that a CVM can still boot if any boot
component is upgraded.
Steps:
1. On first boot, check current PCR values for PCR4 and PCR7
2. Get current boot components versions (e.g. shim, grub, systemd-boot, uki)
3. Run a package upgrade to update boot components
4. Get new boot components versions to see if anything has changed
5. Reboot the CVM, make sure the CVM can boot up again
6. PCR4 should change if any of the boot components is upgraded
7. PCR7 may change (for example, if a signing certificate is changed)
Priority:

1

Requirement:

supported_platform_type[AZURE]

class AzureCVMAttestationTestSuite
Description:
This test suite is for generating CVM attestation report only for azure cvms.
Platform:

Azure, Ready

Area:

cvm

Category:

functional

verify_azure_cvm_attestation_report()
Description:
Runs get-snp-report tool to generate
and create attestation report for azure cvm.
Priority:

3

Requirement:

supported_platform_type[AZURE]

verify_nested_cvm_attestation_report()
Description:
Runs get-snp-report tool to generate
and verify attestation report for nested cvm.
Priority:

3

Requirement:

supported_platform_type[CLOUD_HYPERVISOR]

class NestedCVMAttestationTestSuite
Description:
This test suite is for generating and verifying
CVM attestation report only for nested cvms.
Platform:

Azure, Ready

Area:

cvm

Category:

functional

verify_azure_cvm_attestation_report()
Description:
Runs get-snp-report tool to generate
and create attestation report for azure cvm.
Priority:

3

Requirement:

supported_platform_type[AZURE]

verify_nested_cvm_attestation_report()
Description:
Runs get-snp-report tool to generate
and verify attestation report for nested cvm.
Priority:

3

Requirement:

supported_platform_type[CLOUD_HYPERVISOR]

class VirtualClient
Description:
This test suite runs the performance test cases with Virtual Client.
Platform:

Azure, Ready

Area:

virtual_client

Category:

performance

perf_vc_postgresql()
Description:
This test is to run PostgreSQL workload testing with Virtual Client.
Priority:

3

Requirement:

disk

perf_vc_redis()
Description:
This test is to run redis workload testing with Virtual Client.
Priority:

2

Requirement:

min_count=2