Deploy a VyOS OVA with VMware Tools

I built a custom VyOS OVA with VMware Tools so I could redeploy a lab router without repeating the ISO installation. The appliance supports first-boot administrator credentials and optional router configuration; this post explains what is included, the deployment steps and my validation limits.

The community image used for this project did not include VMware Tools, so I built a custom OVA with open-vm-tools installed and enabled. VyOS documents official OVA downloads for supporting users; this project provides a custom lab appliance rather than an official community OVA. See the VyOS VMware installation documentation.

In this post I am going through what is included in the OVA, how the first boot works, and what I tested before sharing it. This is a community lab appliance, not a production-hardened router or an officially supported VyOS image.

What is included

The appliance was built from the locally retained VyOS 2026.03 (circinus) ISO. It is a fresh build, not the older rolling image I had previously used. The default hardware is small enough for the lab, but you should size it for your own workload.

Without an injected configuration, eth0 uses DHCP and SSH is enabled. The OVA does not include a production firewall policy. The configuration examples and generator provide a starting point for VLANs, DHCP, NAT, and BGP; those examples still need to be adapted to your network.

Download and requirements

The guide and rebuild files are in the VyOS folder on GitHub. The OVA is distributed as a GitHub Release asset because it is too large for a normal repository file. Start with the folder README for the download link and SHA-256 checksum.

For deployment, you need vCenter access, an ESXi host with capacity for the VM, a datastore, and the port groups you intend to use for WAN and LAN. Start on an isolated test network. PowerCLI is only needed if you use the supplied deployment script.

My original VyOS deployment post covers the earlier ISO-based process. This OVA packages the installation so the next deployment can start from the template.

Deploy the OVA

1. Download the OVA and compare its SHA-256 hash with the published checksum. In PowerShell, use Get-FileHash .\VyOS-Router.ova -Algorithm SHA256.
2. In vCenter, select Deploy OVF Template and choose the downloaded OVA.
3. Enter a VM name, then select the inventory location, compute resource, and datastore.
4. Map WAN and LAN to the intended port groups. Keep the deployment isolated until you have checked the configuration.
5. Under Customize template, enter the administrator username and password. The username defaults to vyos; you can choose another valid username. Passwords must be 12–128 characters without control characters.
6. Complete the deployment and inspect the VM before powering it on. For the validation described below, both network adapters were disconnected before the first boot.
7. Power on the VM and allow first-boot customization to finish. The appliance reboots once to apply the login. Log in through the console with the credentials you supplied.
8. Review the interfaces, addresses, firewall policy, and routing before connecting it to your intended networks.

One detail to watch: the bootstrap account is vyos/vyos until customization completes. A manual import that supplies no login properties or configuration retains that account. Do not expose a freshly imported appliance to an untrusted network.

The browser wizard steps describe the intended workflow. The live deployment tests used PowerCLI against vCenter, rather than clicking through the wizard.

What happens on first boot

The deployment fields reach the guest through the standard VMware OVF environment. The first-boot script waits until the persistent VyOS configuration is available, validates the supplied username and password, and writes a salted SHA-512 password hash into the configuration.

If I choose a different username, the default vyos account is removed. If I keep vyos, its password is replaced. After the configuration is written, the appliance records completion and reboots. Changing the deployment properties later is not a password-reset method.

The masked password field is also not encrypted storage. Privileged administrators can read VM deployment metadata. Only the hash is written to the active guest configuration, but you should still protect the VM settings and avoid redistributing a configured VM with credentials in its metadata.

Deploying with a configuration file

The included PowerCLI script can supply a complete config.boot before the VM is powered on. It stores the file in guestinfo.vyos.config-b64, which the guest reads during first-boot customization. The supplied administrator credentials override that account’s password in the injected configuration.

The rebuild kit includes the deployment script, a configuration generator, and examples. Use your own vCenter, datacenter, cluster, datastore, and network names. The -NoPowerOn option is useful when you want to inspect the imported VM before it boots.

Base64 is not encryption. Once the configuration has applied successfully, remove the configuration payload from the VM’s advanced settings. Do not commit private configurations or saved credentials back to GitHub.

What caught me out

The first issue was startup order. VMware Tools can be running before VyOS has finished initializing its persistent configuration. Applying the login too early is not reliable. The customization now starts from the VyOS post-configuration hook, after /config is mounted.

The second issue was test coverage. Local Workstation tests exercised the guest script, but they did not prove that a real vCenter import would deliver the deployment properties. I followed those tests with two fresh imports of the exact OVA through vCenter.

The live test also caught a PowerCLI dependency check and swapped datacenter/cluster defaults in the deployment script. The public copy uses generic example targets, so those values need to be set for your environment rather than copied from mine.

Validation and limitations

The first vCenter deployment used a new routeradmin account. Login and sudo worked, the default account was removed, and vyos/vyos was rejected. The second kept the vyos username with a new password and injected the router test configuration. The new password worked, the old password was rejected, and the expected hostname, VLAN, and BGP configuration were present.

Both guests had active VMware Tools and VyOS router services with no failed systemd units. The configured guest also had active Kea DHCP and FRR services. I rebooted both guests again and repeated the checks to confirm that the credentials and configuration persisted. Both temporary VMs and their disks were removed afterward.

All of those tests used disconnected network adapters. They do not prove live DHCP exchanges, NAT forwarding, VLAN connectivity, or BGP peering. Those are the next checks before using the appliance for actual routing. The retained ISO’s checksum was recorded, but independent publisher signature verification was not performed.

Final thoughts

This gives me a repeatable starting point for a lab router with VMware Tools already in place and a login I can set at deployment. The deployment path has been tested, but the network policy and traffic tests still belong to each environment.

The VyOS project on GitHub includes the download information, deployment guidance, rebuild kit, and validation scope. Start in an isolated lab, review the defaults, and test the traffic you actually need before putting it in the forwarding path.