This is a real lab deployment of the NetScaler VPX 15.1 Tech Preview. It is not a supported production recipe, and 15.1 is absolutely not something I would put in front of users today.

I have deployed enough NetScaler appliances over the years to know roughly how the story normally goes: import the virtual appliance, give it some CPU and memory, configure the NSIP, save the configuration, move on.

This one decided to be more interesting.

NetScaler 15.1 is a major change because VPX is moving from FreeBSD to Linux. I wanted to see how the official KVM image behaved on Proxmox, not in theory, but on an actual host with an actual static address and a configuration that survives reboot.

The good news is that it works. The less good news is that the obvious provisioning method did not.

The small and reasonable plan

I was not trying to build a complicated topology. The goal was deliberately boring:

  • import the official NetScaler VPX 15.1 KVM image into Proxmox;
  • allocate 2 vCPU and 4 GB of RAM;
  • use a VirtIO network interface;
  • configure a static NSIP, gateway, hostname and two DNS servers;
  • enable a serial console so I could see what the appliance was doing;
  • keep automatic startup disabled because this is still a Tech Preview.

The final VM runs on Proxmox with a 20 GB QCOW2 disk, SeaBIOS, the classic PC machine type and a VirtIO NIC. The appliance reports NetScaler 15.1 build 1.58.

Nothing exotic. That was the idea, anyway.

Importing the appliance

The download contains the KVM disk image and the definition supplied by NetScaler. Before importing anything, I verified the archive and vendor checksums.

Yes, this was a lab. I still checked them. An ADC terminates sensitive traffic and usually ends up holding certificates, authentication configuration and a generous amount of trust. Blindly importing an appliance image because it came from a familiar download page is a habit worth avoiding.

The Proxmox side was straightforward:

  1. extract the QCOW2 image;
  2. upload it to a storage that supports imported disks;
  3. create an empty VM without an installation ISO;
  4. import and attach the disk;
  5. configure CPU, memory, network and serial console;
  6. boot it and watch what happens.

I started with the Q35 machine type. The appliance booted, but during troubleshooting I moved back to the classic PC machine type to stay closer to the generic KVM definition. Q35 was not proven to be the problem. Removing unnecessary variables was simply the sensible thing to do.

ConfigDrive looked perfect

NetScaler 15.1 includes cloud-init and lists ConfigDrive as a supported data source. Proxmox knows how to generate ConfigDrive metadata, including hostname, SSH public keys and static network configuration.

On paper, this was exactly what I wanted. No manual console session, no temporary address, no image modification. Create the VM, attach the drive, boot, done.

The generated data looked correct. It contained the intended address, netmask, gateway, hostname, DNS servers and SSH key. I presented it using IDE, SCSI and VirtIO controllers, just in case the attachment method mattered.

NetScaler ignored every version of it.

Each boot ended in the same place: factory-default management address, default hostname, no imported SSH key. I waited, rebooted and checked the generated metadata again. This was not cloud-init taking its time. The appliance simply was not consuming the ConfigDrive produced by Proxmox.

This is where the Tech Preview label earns its keep. A feature being present does not mean every implementation and hypervisor combination has already been validated.

I could have spent the afternoon trying a fourth virtual controller. That would have been stubbornness disguised as troubleshooting.

The workaround that actually worked

NetScaler already has its own native configuration format, and the appliance knows exactly what to do with ns.conf. Instead of trying to persuade cloud-init, I decided to give NetScaler the configuration it already understands.

I first made a separate copy of the vendor QCOW2. The original image stayed untouched, and every previous Proxmox disk was retained as a rollback point. Preview software is not the right place for heroic confidence.

Using qemu-nbd, I attached the copied image to a local NBD device and mounted its flash partition. Inside the persistent nsconfig location, I prepared:

  • an ns.conf containing the initial network configuration;
  • an SSH authorized key for secure first access;
  • the first-boot marker expected by the Linux appliance.

The essential NetScaler configuration was refreshingly ordinary:

The addresses below use the RFC 5737 TEST-NET range. They are documentation examples, not addresses from my infrastructure.

set ns config -IPAddress 192.0.2.15 -netmask 255.255.255.0
set ns hostName adc15-lab
add route 0.0.0.0 0.0.0.0 192.0.2.1
add dns nameServer 192.0.2.53
add dns nameServer 192.0.2.54

I then unmounted the partition cleanly, detached the NBD device and ran qemu-img check before putting the disk anywhere near the VM.

The customized copy was uploaded to Proxmox and attached as the boot disk.

Next boot: success.

The appliance appeared directly on the intended NSIP. SSH key authentication worked. The management interface came up. The route and DNS configuration were present. No temporary console gymnastics and no dependence on the factory-default management network.

Sometimes the least fashionable solution is the one that respects the product best.

The checks that mattered

A ping is not a deployment validation. It only proves that something answered ICMP at least once.

I checked the appliance as if I planned to keep it:

  • the NSIP was active with the expected mask;
  • the default route existed and reported UP;
  • both DNS servers were present;
  • SSH public-key authentication worked for the administrator;
  • HTTP and HTTPS management services answered;
  • the NITRO API accepted authenticated sessions;
  • the running configuration matched the intended state;
  • the configuration saved successfully;
  • a reboot did not lose the network settings.

One detail remained odd. NetScaler initially showed both DNS entries as DOWN even though the servers answered DNS queries correctly from the network.

I noted it and carried on. In a preview build, a questionable health state is something to investigate. It is not a reason to rebuild two healthy DNS servers just to make the dashboard prettier.

Rotate the default password immediately

The first authenticated NITRO request returned a useful warning: the default nsroot password still needed to be changed.

I replaced it with a generated password, stored the credential in a password manager and opened a fresh NITRO session to verify it.

Preloading an SSH public key is not a substitute for rotating the built-in administrator password. The key protects one access path. The default password remains a default password until you change it.

What I would do next time

If I had to repeat this deployment tomorrow, I would keep it simple:

  • use the classic PC machine type from the start;
  • try Proxmox ConfigDrive once, because a later build may fix it;
  • stop testing ConfigDrive once the appliance clearly ignores valid metadata;
  • work only on a copy of the vendor QCOW2;
  • preload both ns.conf and an SSH public key;
  • validate the modified image with qemu-img check;
  • retain rollback disks until configuration and reboot tests pass;
  • leave automatic startup disabled for the Tech Preview.

The biggest time saver is knowing when to stop debugging the elegant solution and switch to the native one.

Final verdict

NetScaler VPX 15.1 does run on Proxmox. Once the native configuration is in place, it behaves like a proper NetScaler appliance. Boot is fast, the KVM image is usable and the new Linux foundation is very visible once you start exploring the system.

The rough edge is first-boot provisioning. Proxmox ConfigDrive was the obvious answer, generated correct data and still went completely unnoticed by build 1.58. Preloading ns.conf into a copied QCOW2 solved the problem cleanly while preserving the original image for rollback.

Would I use it now to prepare deployment tooling, migration procedures, monitoring and operational knowledge for the Linux-based future of NetScaler? Absolutely. That is exactly what a Tech Preview is good for.

References