In my last post we went over installing a Proxymox host and we did a fair bit of managing already… ok mostly just storage but we had to manage the host after the initial install of the base OS. This should be pretty obvious, it’s a web interface, which is stated right on the Console output after you install. All the commands in the previous blog could have all been done from the direct system console, but also via remote SSH.
So, first act is to change the update repo, by removing the enterprise ones and adding the no-sub repo for updates. This alone won’t resolve the nagging pop up when you log in about having no subscription. to get rid of that:
Remove the annoying subscription pop-up
- Open the Shell terminal from your Proxmox web UI or connect via SSH as root.
- Navigate to the widget toolkit directory:
cd /usr/share/javascript/proxmox-widget-toolkit/Make a backup copy of
proxmoxlib.js:cp proxmoxlib.js proxmoxlib.js.bak - Open the file in a text editor like
nano:nano proxmoxlib.js - Search for the text
active(pressCtrl + Win nano). - Locate the conditional check that looks for an active status, which typically contains
!== 'active'or!reslogic. Change the inequality exclamation mark!to make it an equality check== 'active'(removing the!so it evaluates positively instead of triggering the warning when inactive). Alternatively, comment out or bypass the function call according to your specific Proxmox minor version. - Save the file (
Ctrl + O, thenEnter) and exit (Ctrl + X). - Restart the Proxmox proxy service to apply the change:
systemctl restart pveproxy.service - Perform a hard refresh or clear your browser cache (
Ctrl + F5)
System Resources
I basically just click on the host summary tab. or a VMs summary tab.
Or install “glances” on the terminal shell.
Networking
I know, I know, you’re probably screaming about authentication and user management, groups, permissions. probably yelling “RBAC!!” I’m gonna stick to using root for now and concentrate on infrastructure stuff for now.
When configuring Proxmox in a multi-subnet or VLAN environment, you quickly run into the limitations of the Linux kernel’s “Weak Host Model,” which handles routing very differently than enterprise firewalls like Palo Alto Networks (PAN-OS). Unlike zone-based firewalls that use policy-based forwarding to automatically reply out of the same interface a packet arrived on, Linux relies strictly on destination-based routing tables. This becomes a major trap if you assign identical or overlapping subnets to multiple network interfaces; even if you physically unplug a network cable, the Linux kernel holds onto that dead route at the top of its table. This causes traffic to be shoved down a disconnected interface, resulting in frustrating “No Route to Host” errors and dropped connections, even when your other live interface is perfectly configured.
Furthermore, setting up multi-homed access to the Proxmox Web UI introduces asymmetric routing challenges, as Linux only permits a single global default gateway by default. If traffic arrives on a secondary VLAN interface, Proxmox will mistakenly attempt to send the reply back out the primary management gateway, causing firewalls to log “aged out” or “incomplete” states due to the routing mismatch. To resolve this, administrators must either use the CLI to inject custom policy-based routing rules (ip rule and separate routing tables) into the network configuration file or cleanly isolate their subnets by stripping duplicate IP layers off disconnected bridges. Additionally, when testing these secondary access points, remember that the Proxmox web service strictly binds to its local hosts configuration and requires explicit HTTPS formatting over port 8006 (https://<IP>:8006) to successfully initialize a session.
That’s a long winded way to say that when I was trying to keep the flat home network (untagged) ip address on the Proxmox server, while also giving it a virtual interface attached to another VLAN tagged subnet. It wouldn’t connect (or it wouldn’t load) the web interface from my home untagged network, even though it was routed, and tagged properly on all network devices along the network path.
So from what I can tell:
a “Linux Bridge” is like a vmware vSwitch. You define the physical connection the host has to these bridges.
a “Linux VLAN” is like a VMK. This is where you define another IP address the host can use. You select which device by defining VLAN raw device, which seem you can pic the physical NIC or the bridge, I don’t know the implication if you pic the nic when its already configured for a bridge though… I’m still learning here.
When you edit a VMs NIC settings you pick a bridge, and you can define what vlan the traffic will be at the VMs NIC settings, this is like the VMPG on ESXi.
Did I break updates from this… yup looks like it.. DNS works.. but can’t reach out anywhere or yeah.. locked down subnet, that was easily fixed.
Edited a VM NIC settings, change bridge, added VLAN Tag. Disconnect, power on VM, apply static IP, change to connect, yup.. works just fine.
Interacting with VMs
Virt-Viewer and Virt-Manager
PVE has the web console built right in, so you can just manage the VM directly that way. I like being able to have an app window for the connection much like VMRC for VMware. Which PVE has, called Virt-viewer, get it here: Virtual Machine Manager. I installed the Winx64 binaries.
One trick I like to do is connect a USB stick to my main mgmt machine, then copy files to it, then to a VM if I need to get files on to said VM if the VM is an offline only machine.
Since I deployed this VM from a generalized image I had created I needed to pick a storage controller that I knew would be natively available to the image I was using so I stuck with the LSI, I installed virt-viewer so SPICE as my GPU, and again a native supported NIC, so the E1000.
As you can also see, they are all generic drivers, but.. working:
So as you see, not terrible, but also not crazy, I know those 3 SSDs can perform better then these results since I did an I/O test on them via the host backend, so I’m assuming I have so loss in the virtual bus controller (the LSI 53C) or the standard Windows drivers. So, the first thing I want to test is installed the guest tools, will they change how devices show in the device manger, and will there be any performance increases?
Spice Guest Tools
So downloaded them on the guest VM from “www.spice-space.org/download.html”
not sure what was up with the serial driver, but I just accepted it:
Well…
Windows Main Device? No USB Trick for you!
- Even after all that, the video drivers showed up without basic drivers, and I can move in and out of the VM in the virt-viewer with having to press CTRL+ALT+R. That’s Good.
- The Storage device in device manager still shows generic SATA ACHI so I don’t believe I’ll get any better I/O results.
- Attempting to add a SPICE USB port to the VM hardware worked but…
after shutting down the VM and power it back on, the device list wasn’t greyed out and showed one free channel. but picking any of my devices…
ok… this might be cause my mgmt machine is Windows?
I want to like PVE, but there are a lot of little niche things that are pissing me off about it. Then when you want to use SPICE with virt-viewer, it downloads a spice.vv file that you have to open, which auto deletes when the VM is shutdown or close (haven’t tested this). just feels like weird UX. anyway…
Storage Controller vs Virtual Hard Drives
I changed the SCSI controller from LSI 53C to VirtIO SCSI Single. But when I booted the VM back up I still saw the same generic SATA ACHI Controller. I felt like there was some ignorance on my part so I asked AI for any insights, it informed me to add a drive cause the type on the actual virtual disk could still be bound to the old type. So I temp added a disk (just for testing) and changed the connection from SATA to SCSI and checked the dev mgmt and ran a test and the performance was a fair bit better…
compared to
| Benchmark Test | Metric Type | Performance Change | Percentage Increase |
|---|---|---|---|
| Seq1M-Q8T1 | Read | 433 MB/s → 651 MB/s | +50.3% |
| Write | 56 MB/s → 95 MB/s | +69.6% | |
| Seq1M-Q1T1 | Read | 400 MB/s → 511 MB/s | +27.8% |
| Write | 51 MB/s → 54 MB/s | +5.9% | |
| Ran4K-Q32T1 | Read | 14 MB/s → 136 MB/s | +871.4% |
| Write | 7 MB/s → 7 MB/s | 0.0% (No Change) | |
| Ran4K-Q1T1 | Read | 6 MB/s → 13 MB/s | +116.7% |
| Write | 1.5 MB/s → 2 MB/s | +33.3% |
- Massive Random Read Improvement: The biggest leap is in Ran4K-Q32T1 Read, sky-rocketing by 871.4%. This means heavy multi-threaded background random tasks will feel exponentially faster.
- Solid Sequential Gains: Large file transfers (Seq1M) see a great bump, with reads improving by roughly 28% to 50%, and multi-queued writes jumping by nearly 70%.
- Lagging Write Speeds: Random deep-queue writes (Ran4K-Q32T1) didn’t improve at all, and sequential single-thread writes (Seq1M-Q1T1) only crawled up by 5.9%.
That’s a bit improvment, I need to get the base OS HDD on this new type to gain the performance increase. Do to that:
Swap the Real Drive to SCSI
- In the Proxmox Hardware tab, select the 1 GB dummy disk you just made and click Detach. Then select the detached unused disk and click Remove.
- Select your main Windows boot disk (currently sitting on
sata0oride0) and click Detach. It will immediately drop down to the bottom of the hardware list as an Unused Disk 0. - Double-click that Unused Disk 0. (I don’t know why double click seemed the only option I couldn’t see any action items at the top)
- In the pop-up window, change the Bus/Device dropdown to SCSI (it will likely assign
scsi0). Click Add.
Fix the Boot Order
- Go to the VM’s Options tab in Proxmox.
- Double-click Boot Order.
- Check the box for your newly reattached scsi0 drive and drag/button it to the very top of the list so it is the primary boot device. Click OK.
Yeah for some reason it wasn’t checked off, so reattaching a vHDD has this implication something I didn’t instinctively had to do, in the snip above I unchecked net boot and checked off the scsi0.
