Skip to main content
Skip to main contentPeresvet Learning Center

Virtual Machines

Introduction​

This guide describes how to create a virtual machine for Peresvet ST in Proxmox VE 8. It covers one configuration:

  • Without PCI Passthrough — using virtual VirtIO interfaces for functional testing.

System Requirements​

General Requirements​

  • Proxmox VE 8 virtualization platform;
  • Ubuntu Server 24.04 LTS guest operating system;
  • Linux kernel 5.15;
  • at least 32 GB of RAM for the VM;
  • at least 16 physical CPU cores with a 2 GHz base clock for the VM;
  • at least 16 RX/TX queues on the network adapter;
    • Many virtual clusters configure only one RX/TX queue by default. This limits performance and restricts the software to one core. The RX/TX queue count must be at least equal to the VM core count.
  • at least 64 GB of free disk space.

Limitations​

  • Peresvet ST on a VM has several limitations:
    • stateful traffic generation can use at most one /24 IPv4 subnet; stateless plugins are not restricted in this way;
    • overall performance, especially for stateful scenarios, is much lower than on a Peresvet ST appliance;
    • VM deployment is recommended for functional testing.
  • Internet access is required while configuring the virtualization cluster, creating the VM, and installing Peresvet ST.
  • Currently, only VM operation without PCI Passthrough and with the VIRTIO driver is supported by this guide.

Without PCI Passthrough (VirtIO)​

Performance: up to 5 Gbps (stateless UDP, 1,400-byte packets).

Architecture​

This configuration uses:

  • eth0 — primary Proxmox management interface;
  • eth1 — secondary network interface;
  • vmbr0 — bridge to the external network (public IP);
  • vmbr1 — bridge to the internal network (10.10.10.0/24).

Configuration Without PCI Passthrough (VirtIO)

Configuring a Network Bridge​

Configuring the Internal Network​

Edit /etc/network/interfaces:

nano /etc/network/interfaces

Make sure that vmbr1 is configured:

auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0

Applying the Configuration​

ifreload -a

Optional: Configuring NAT for the Internal Network​

# Enable routing
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

# Add a NAT rule
iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE

# Persist the rules
apt install iptables-persistent -y
netfilter-persistent save

Creating a Virtual Machine​

VM Parameters​

Create a VM in the Proxmox web interface with these settings:

  • General: enter a VM name.
  • OS: select the uploaded Ubuntu ISO.
  • System: Machine: q35; BIOS: OVMF (UEFI); EFI storage: local; select Qemu Agent.
  • Disks: 64 GB or as required.
  • CPU: Cores: 16; Type: host.
  • Memory: 32768 MB.
  • Network: Bridge: vmbr1; Model: VirtIO (paravirtualized); under Advanced, set multiqueue equal to the VM core count (16).

Adding a Second Network Interface​

Important: Add the second interface BEFORE beginning Ubuntu installation.

  • After creating the VM but before starting it, select VM → Hardware → Add → Network Device.
  • Under Advanced, set multiqueue equal to the VM core count (16).
  • Set Bridge to vmbr1 and Model to VirtIO.
  • Click Add.

Installing Ubuntu​

  • Start the VM and open its console.
  • During network configuration, two interfaces appear: enp6s18 (first VirtIO) and enp6s19 (second VirtIO).

Network Configuration During Installation​

First interface (enp6s18)—management:

  • Method: Manual
  • Subnet: 10.10.10.0/24
  • Address: 10.10.10.101
  • Gateway: 10.10.10.1
  • Name servers: 8.8.8.8,8.8.4.4

Second interface (enp6s19)—DPDK:

  • It can remain unconfigured; Peresvet ST configures it later.

Post-Installation Check​

# Check interfaces
ip a

# Check routing
ip route

After creating the VM, install Peresvet ST with the installation wizard.

Enabling RSS​

RSS (Receive Side Scaling) distributes inbound traffic among multiple NIC RX queues, normally one per CPU core. Peresvet ST, through the DPDK virtio PMD, attempts to enable RSS at startup. In a VM, virtio RSS must be enabled explicitly in the VM configuration; otherwise, the agent log contains:

VIRTIO_DRIVER: virtio_dev_configure(): RSS support requested but not supported by the device
ETHDEV: Port0 dev_configure = -95
Important for Stateful Scenarios

After RSS configuration failed, trying without RSS, the agent starts without RSS. This mode is suitable for stateless traffic and single-core stateful scenarios. Multi-core stateful TCP/HTTP results can be incorrect because return traffic can arrive on a queue and core that do not contain the session state. This causes TCP drops, differences between client and server HTTP counters, and unpredictable test results.

For multi-core stateful scenarios, enable virtio RSS, use SR-IOV/PCI Passthrough, or restrict the task to one core.

Prerequisite: The VM network interface must have at least as many queues (multiqueue) as VM cores; see Creating a Virtual Machine. RSS without multiple queues provides no benefit.

Enable RSS in layers. Continue to the next step only if the previous one does not remove dev_configure = -95.

Step 1: Enable RSS on the Virtio Device​

On the Proxmox host, add RSS/hash to the VM's QEMU arguments, replacing <VMID> with the VM ID:

qm set <VMID> --args "-global virtio-net-pci.rss=on -global virtio-net-pci.hash=on"
  • -global applies the setting to all virtio-net-pci devices in the VM.
  • QEMU must support eBPF RSS, which is included in Proxmox VE 8.
  • Important: qm set --args replaces the complete args string. If it already contains arguments, inspect qm config <VMID> | grep args and combine them into one string.

Arguments are read only when the QEMU process starts, so perform a complete stop/start; rebooting inside the guest is insufficient:

qm stop <VMID> && qm start <VMID>

Step 2: If RSS Still Does Not Activate, Disable Vhost (Software RSS)​

Cause: With vhost=on, the default, QEMU delegates RSS hashing to vhost-net through an eBPF program. If the host kernel or vhost-net does not support eBPF RSS, the feature is silently withheld from the guest and rss=on has no effect.

Solution: Disable vhost for the required netdev so QEMU calculates RSS in software. First identify the interface ID:

qm showcmd <VMID> --pretty | grep -- -netdev
# -netdev type=tap,id=net0,...   ← management interface
# -netdev type=tap,id=net1,...   ← DPDK interface

Add -set netdev.<id>.vhost=off for the DPDK interface, normally net1:

qm set <VMID> --args "-global virtio-net-pci.rss=on -global virtio-net-pci.hash=on -set netdev.net1.vhost=off"
qm stop <VMID> && qm start <VMID>

Important: vhost is a netdev (backend) property, not a device property. Use exactly -set netdev.<id>.vhost=off. -global virtio-net-pci.vhost=off does not work; the device has no such property, and the VM fails to start with Property 'virtio-net-pci.vhost' not found.

Software RSS removes hardware vhost acceleration from the data path and therefore provides lower throughput. This is acceptable for VM-based functional testing.

Step 3: Hardware RSS Through SR-IOV / PCI Passthrough​

For full RSS at hardware speed, pass a physical NIC's virtual function (VF) into the VM through SR-IOV, or pass through the complete physical port with PCI Passthrough. The NIC then provides RSS without QEMU/vhost limitations. This is a separate configuration; the current guide covers VirtIO only.

Checking RSS​

After starting the VM and Peresvet ST, the primary criterion is that the agent log no longer contains dev_configure = -95 or RSS support requested but not supported.

Before binding the interface to DPDK, check the RSS indirection table inside the guest:

ethtool -x <iface>

After Peresvet ST binds the interface to DPDK (vfio-pci driver), it disappears from /sys/class/net, and ethtool no longer shows it. This is normal.

Troubleshooting​

Common Problems​

Problem: The VM Does Not Obtain an Address Through DHCP​

Cause: vmbr1 has no DHCP server.

Solution: Configure a static IP address as described in this guide.

Problem: Ubuntu Installation Hangs at “curtin command in-target”​

Cause: A slow update mirror or network problem.

Solution: Wait 15–20 minutes. If there is no progress, reboot the VM; the system normally starts correctly.

Problem: dev_configure = -95 / “RSS support requested but not supported” in the Agent Log​

Cause: Virtio RSS is not enabled for the VM, so the guest device does not expose VIRTIO_NET_F_RSS. The agent does not fail: it switches to non-RSS mode and continues, but inbound traffic is not distributed among multiple queues and cores. This is unsuitable for multi-core stateful TCP/HTTP because test results can be incorrect.

Solution: Enable RSS in the VM configuration; see Enabling RSS.

Performance Recommendations​

VirtIO Configuration​

Buffer optimization: Increase buffer sizes:

echo 'net.core.rmem_max=134217728' >> /etc/sysctl.conf
echo 'net.core.wmem_max=134217728' >> /etc/sysctl.conf
sysctl -p
Last updated by daniil