Akzium_Blog - Akzium

Preserve Legacy Windows OS Activation After VMware to Proxmox Migration

9/2/2026

Migrating a Windows VM from VMware to Proxmox? Don't Lose Your Windows Server Activation. Microsoft retired telephone activation as of December 2025. Users are redirected to an online portal (aka[.]ms/aoh) that requires a Microsoft Account. You log in, type in your Installation ID (generated on the server by running slui 4), and it attempts to generate a Confirmation ID for you. If you have a Retail or Volume License (MAK) key and you are simply doing a clean install or an offline activation on the exact same hardware, the portal will generally work. It will process the Installation ID and hand back a Confirmation ID to activate the server.

An already-activated (non-KMS) Windows stores its activation in tokens.dat, which rode along with the VM's disk during the conversion. At boot, Windows re-validates that stored activation against the current hardware locally. Match the SMBIOS UUID (plus MAC/SMBIOS strings) to what VMware presented, and the existing activation re-validates with zero server contact.

Here's how to do it (assuming a Retail / MAK / Volume license):

Step 1 — Check your license type. In the guest, run slmgr /dlv. If it's KMS, it re-activates automatically — you're done. If it's Retail or MAK, keep going.

Step 2 — Grab the original UUID from your .vmx. Find the uuid.bios line, e.g.: uuid.bios = "56 4d 59 5c 4c 56 4b 10-b8 e0 66 84 d3 2d 01 63"

Step 3 — Fix the byte order: SMBIOS stores the first three UUID fields little-endian. Reverse the byte order within groups 1–3 only. Those example bytes become: 5c594d56-564c-104b-b8e0-6684d32d0163 Copying the raw string left-to-right gives the WRONG UUID and breaks activation.

Step 4 — Apply it in Proxmox. Edit /etc/pve/qemu-server/<VMID>.conf and set: smbios1: uuid=5c594d56-564c-104b-b8e0-6684d32d0163
**(Or enter it via the web UI under Options → SMBIOS settings.)

Step 5 — Match the MAC address. Copy ethernet0.address from the .vmx onto your net0 line so the NIC identity carries over too. (*note: you can preserve the ethernet MAC address during the VMw-to-Pmx conversion)

Step 6 — Verify inside the guest. Boot the VM and run: wmic path win32_computersystemproduct get uuid.
Confirm it matches your target, then check slmgr /xpr.

One caveat: if your .vmx contains SMBIOS.reflectHost = "TRUE", the VM was mirroring the physical ESXi host's SMBIOS (common with OEM/ROK licenses).

In that case you'll need to replicate the host's manufacturer strings and its SLIC/MSDM ACPI table instead — a different process.

And remember: you own the license. If a MAK/Retail key still shows unactivated after matching the hardware, online reactivation is completely legitimate.

Moving off VMware doesn't have to mean re-licensing your legacy Windows Server OS, but there's some techical work involved in making it function properly.

VirtIO Drivers for Windows Operating Systems

8/31/2026

If you're still running older versions of Windows Server OS (2003/2008/2012) and are needing an archived copy of the VirtIO drivers for Windows - the download site is fedorapeople[.]org/groups/virt/virtio-win/direct-downloads/archive-virtio/. The fedorapeople[.]org domain is used by the virtio-win project, which is an open-source initiative sponsored by Red Hat and the Fedora Project. This repository hosts the paravirtualized network, storage, and balloon memory drivers necessary for running Windows virtual machines efficiently on KVM/Qemu-based hypervisors including Proxmox VE.

Some older drivers are only available in .vfd (virtual floppy drive) format or as device driver files (.sys, .inf, .cat, .dll, .pdb). For example, the virtio .iso that contains drivers compatible with Windows Server 2008 are in this format, there is no .MSI or .EXE installer.

So, to install these device drivers you have to launch Device Manager via Start > Run > devmgmt[.]msc and navigate to Devices. Expand the list and find devices with yellow exclamation marks - typically ethernet controllers, PCI devices. In the case of the ethernet devices Right-Click the Ethernet Controller and select Update Device Driver Software. Then choose Browse My Computer for the driver software. Point it to the mounted .ISO and browse to NetKVM\wlh\amd64 folder and install the updated device driver. Repeat for other devices (example: Memory Balloon driver is in Balloon\wlh\amd64 which typically shows up as "Unknown PCI device". *note: avoid memory ballooning in production environments.

Once all of the device drivers are updated - reboot the VM. You may also need to go back and clean up "ghost" adapters that are left over from a VMware to Proxmox conversion. Go back into Device Manager > View > Show Hidden Devices and remove/uninstall any devices that are greyed-out in the device list.

If you're migrating Windows OS server VMs from VMware to Proxmox, in many cases the VM will only boot at first if you change the HDD type to SATA. Once it boots, you install the VirtIO drivers and add a small 1Gb Single-SCSI volume and reboot. Once you've rebooted, Windows will detect the SCSI disk and virtual device. Shut down Windows. Remove the test SCSI disk. Change the disks from SATA to Virtio-Single-SCSI by first Detaching the disk, and then reattach by click on Unused Disk, Edit, and then change Bus/Device to SCSI. Navigate to Options, Boot Order, change the boot order to put the SCSI device first, and make sure to check the Enabled box next to the disk. The Windows server VM should boot and use the drive as SCSI rather than SATA - with a nice performance improvement.

Proxmox rSysLog: Setting up rsyslog on Proxmox VE

7/14/2026

Syslog (System Logging Protocol) is a standard protocol used by network devices, operating systems, and applications to generate and send diagnostic messages. These logs contain timestamps, severity levels, and specific data about system events, security warnings, configuration changes, or service failures.Tools like rsyslog (an enhanced, modular version of syslog) act as the delivery service. They process those event messages locally and can be configured to forward them over the network. In this post I'll cover the installation and setup of rsyslog. Some platforms such as OpenObserve have deprecated support for rsyslog in favor of syslog-ng. I'll cover that in a separate post.

Why Configure Proxmox to Send Rsyslog Data to a Central Server?

By default, Proxmox VE (which is based on Debian) manages system logs locally via systemd-journald. However, installing rsyslog and forwarding those logs to a centralized syslog server or log aggregator (such as Kiwi Syslog, or Splunk) offers critical operational benefits:

Post-Crash Troubleshooting and Diagnostics: If a Proxmox host experiences a severe hardware failure, kernel panic, or sudden lockup, the local logs often become inaccessible or get corrupted. Offloading logs in real-time ensures you can review the exact moments leading up to the crash from a separate machine.

Tamper-Resistant Security and Auditing: If a Proxmox node is compromised, a malicious actor's first move is often to clear or modify local log files to hide their tracks. Centralized logging preserves an immutable audit trail outside of the attacker's reach.

Centralized Infrastructure Monitoring: Managing logs across a Proxmox cluster (or alongside other firewalls, switches, and servers) is tedious if you have to log into each machine individually. Centralization brings all data under one dashboard.

Proactive Alerting and Long-Term Storage: Central log aggregators allow you to write advanced rules to trigger immediate alerts (e.g., failed SSH logins, hard drive smart errors, or high cluster fencing events). They also let you store massive historical backlogs without consuming valuable local storage on your hypervisor boot drives.

Here are the setup steps for installing and activating rsyslog on each of your Proxmox nodes.

Go to a System prompt:
apt update
apt install --no-install-recommends rsyslog -y
systemctl enable --now rsyslog
##Set (uncomment by removing # and change ForwardToSyslog=yes
nano /etc/systemd/journald.conf
ForwardToSyslog=yes

Ctrl+o and enter to save, Ctrl+x to exit nano

systemctl restart systemd-journald

##Verify /var/log/syslog is growing
tail -f /var/log/syslog

##Create the forwarding configuration
nano /etc/rsyslog.d/10-syslogserver.conf

# Kiwi syslog forwarding
*.* action(
type="omfwd"
target="<COLLECTOR_IP>"
port="<PORT>"
protocol="tcp" ##(or "udp" depending on syslog server requirements)
template="RSYSLOG_SyslogProtocol23Format"
OR
template=RSYSLOG_TraditionalForwardFormat"
##do not use both template lines - use the one required by your syslog server. Kiwi requires Traditional (RFC 3164). Solutions like Adlumin require Protocol23 (RFC 5424).##
queue.type="LinkedList"
queue.filename="kiwi_fwd"
queue.maxdiskspace="1g"
queue.saveonshutdown="on"
action.resumeRetryCount="-1"
)
##Ctrl+o and enter to save, Ctrl+x to exit nano editor
## Validate and restart:
rsyslogd -N1
systemctl restart rsyslog
systemctl status rsyslog

##Test:
logger -t kiwi-test "proxmox-node1 syslog forwarding test $(date)"

systemctl status rsyslog
journalctl -u rsyslog -n 50 --no-pager
ls -la /var/spool/rsyslog

##this should send data to your syslog server. If your Proxmox firewall is enabled, don't forget to create an outbound exception for the IP and Port to your syslog server.##

pveproxy web-UI access logs live in /var/log/pveproxy/access.log, not the journal, so they won't be picked up by the configuration above. If you want your syslog server to track auth/UI access, add an imfile input:

nano /etc/rsyslog.d/10-syslogserver.conf

##place the following text at the top of the 10-syslogserver.conf file, above the action block, and restart rsyslog##

module(load="imfile")
input(type="imfile"
File="/var/log/pveproxy/access.log"
Tag="pveproxy"
Severity="info"
Facility="local6")

Ctrl+o and enter to save, Ctrl+x to exit nano.

systemctl restart rsyslog
systemctl status rsyslog

Updating Windows Secure Boot Cert for Proxmox-hosted VMs

6/27/2026

Windows Secure Boot Certificate Remediation for Proxmox VE Windows VMs

This runbook documents a safe process for remediating the Windows Secure Boot certificate expiration / Microsoft UEFI 2011-to-2023 certificate transition for a Windows virtual machine running on Proxmox VE 9.2 or later.
Scope

Applies to Windows VMs running on Proxmox VE that use OVMF/UEFI firmware with Secure Boot enabled.

This process covers:

Suspending BitLocker before Secure Boot key changes
Enrolling the updated Microsoft UEFI 2023 certificates in the Proxmox VM EFI disk
Triggering or verifying the Windows-side Secure Boot servicing process
Verifying update status
Re-enabling BitLocker protection

Important Concepts
1. Proxmox certificate enrollment updates the VM's virtual UEFI/OVMF Secure Boot certificate store.
2. This does not automatically guarantee that Windows has completed its own Secure Boot servicing process.
3. Windows may still need to deploy the 2023 Secure Boot certificates and install the PCA2023-signed boot manager.
4. If BitLocker is enabled, Secure Boot certificate/key changes can trigger BitLocker recovery because TPM measured-boot values may change.
5. In most cases, BitLocker should be suspended, not decrypted or permanently disabled.

Pre-Change Checklist
[ ] Confirm the VM uses UEFI/OVMF firmware.
[ ] Confirm Secure Boot is enabled for the VM.
[ ] Confirm the VM has an EFI disk.
[ ] Confirm the VM has a current backup.
[ ] Confirm the backup includes the VM's EFI disk.
[ ] Confirm the Windows BitLocker recovery key is documented and accessible.
[ ] Confirm you have administrative access inside Windows.
[ ] Confirm you have Proxmox administrative access.
[ ] Schedule a maintenance window.
[ ] Notify users/application owners as appropriate.

Step 1 - Check BitLocker Status
Start the Windows VM and log in.
Open PowerShell as Administrator and run:
manage-bde -status
Check whether drive C: or any other attached volumes are BitLocker protected.
To view protectors for C:, run:
manage-bde -protectors -get C:
If additional protected data drives exist, repeat the relevant commands for each protected drive.

Step 2 - Suspend BitLocker Protection
Do not decrypt the drive unless there is a separate operational reason to do so.
Suspend BitLocker protection on C::
manage-bde -protectors -disable C: -RebootCount 0
Alternative PowerShell cmdlet:
Suspend-BitLocker -MountPoint "C:" -RebootCount 0

Why use -RebootCount 0?
This prevents BitLocker protection from automatically resuming after a single reboot. That is useful because the Secure Boot servicing process may require more than one reboot.
If there are other BitLocker-protected volumes, suspend protection on those volumes as well.

Step 3 - Gracefully Shut Down the VM
From inside Windows, perform a normal shutdown.
Do not simply power off the VM unless Windows is hung or unavailable.

Step 4 - Enroll Updated Certificates in Proxmox
Use either the Proxmox GUI or the Proxmox CLI.
Option A - Proxmox Web GUI
1. In the Proxmox web interface, select the Windows VM.
2. Go to the Hardware tab.
3. Select the EFI Disk.
4. Click Disk Action.
5. Click Enroll Updated Certificates.
6. Confirm the action.
7. Start the VM after the enrollment completes.
Option B - Proxmox CLI
1. Make sure the VM is powered off.
2. Open the shell on the Proxmox node.
3. Run the following command, replacing <VMID> with the actual VM ID:
qm enroll-efi-keys <VMID>
Example:
qm enroll-efi-keys 104
4. Start the VM after the command completes.

Notes
- The Proxmox warning commonly references the marker ms-cert=2023k.
- If the VM is missing the 2023 Microsoft certificates, Proxmox may display a warning about outdated UEFI certificates.
- The CLI method requires the VM to be shut down.

Step 5 - Start Windows
Boot the Windows VM normally.
Expected result:
- Windows should boot normally.
- BitLocker should not prompt for a recovery key if protection was properly suspended.
- If BitLocker recovery still appears, use the documented recovery key.

Step 6 - Trigger or Verify Windows Secure Boot Servicing
The Proxmox certificate enrollment updates the VM firmware certificate store, but Windows still needs to complete its own Secure Boot update process.

Windows uses the Secure-Boot-Update scheduled task:
\Microsoft\Windows\PI\Secure-Boot-Update

For IT-managed or manual deployment, Microsoft documents using the AvailableUpdates registry value.
Open PowerShell as Administrator and run:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
-Name AvailableUpdates `
-Type DWord `
-Value 0x5944

Then run the scheduled task:
Start-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update"

Reboot as required.
The Secure Boot servicing process may require more than one reboot.

Step 7 - Verify Windows Secure Boot Update Status
After Windows has rebooted, open PowerShell as Administrator and run:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
-Name UEFICA2023Status,UEFICA2023Error,UEFICA2023ErrorEvent
Expected successful status:
UEFICA2023Status : Updated
Common status values:
- NotStarted
- InProgress
- Updated
If the status is InProgress, allow the servicing process to continue and reboot again if required.
If an error is shown, record:
- UEFICA2023Error
- UEFICA2023ErrorEvent
- Any related Windows Event Viewer entries
Step 8 - Re-Enable BitLocker Protection
After confirming that Windows boots normally and Secure Boot servicing is complete, re-enable BitLocker protection.
Command-line option:
manage-bde -protectors -enable C:
PowerShell option:
Resume-BitLocker -MountPoint "C:"
Verify status:
manage-bde -status
Confirm that protection is enabled again.
Step 9 - Final Validation
Perform the following checks:
[ ] Windows boots normally.
[ ] No BitLocker recovery prompt appears.
[ ] BitLocker protection is enabled again.
[ ] Secure Boot remains enabled.
[ ] Windows Secure Boot servicing status shows Updated, if applicable.
[ ] Applications/services start normally.
[ ] Event Viewer does not show new Secure Boot or BitLocker errors.
[ ] Backup system recognizes the VM normally after the change.
[ ] Change-control ticket is updated with results.

Rollback / Recovery Notes
If the VM fails to boot after certificate enrollment:
1. Do not repeatedly force power off the VM without capturing the error.
2. Record the exact boot error message.
3. Confirm whether the VM is using OVMF/UEFI and Secure Boot.
4. Confirm whether the EFI disk is present.
5. Confirm whether the correct VMID was used for CLI enrollment.
6. Attempt boot repair only after confirming a valid backup exists.
7. If BitLocker recovery appears, enter the documented recovery key.
8. If necessary, restore the VM from backup, including the EFI disk.
Change-Control Summary
Enroll updated Microsoft UEFI 2023 Secure Boot certificates for Windows VM running on Proxmox VE and verify Windows Secure Boot servicing status.

Risk:
Secure Boot certificate/key changes may alter TPM measured-boot values and trigger BitLocker recovery if BitLocker protection is not suspended first.

Mitigation:
- Confirm current VM backup.
- Confirm BitLocker recovery key.
- Suspend BitLocker protection before certificate enrollment.
- Enroll updated Proxmox EFI certificates while VM is powered down.
- Verify Windows Secure Boot servicing status.
- Resume BitLocker after successful validation.

Commands Summary
Check BitLocker:
manage-bde -status
manage-bde -protectors -get C:
Suspend BitLocker:
manage-bde -protectors -disable C: -RebootCount 0
Alternative:
Suspend-BitLocker -MountPoint "C:" -RebootCount 0
Enroll Proxmox EFI keys:
qm enroll-efi-keys <VMID>
Set Windows Secure Boot update registry value:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
-Name AvailableUpdates `
-Type DWord `
-Value 0x5944
Run Windows Secure Boot update task:
Start-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update"
Verify Windows Secure Boot servicing:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
-Name UEFICA2023Status,UEFICA2023Error,UEFICA2023ErrorEvent
Resume BitLocker:
manage-bde -protectors -enable C:
Alternative:
Resume-BitLocker -MountPoint "C:"

Source References
Proxmox forum - UEFI 2011 certificates expire in June 2026:
https://forum.proxmox.com/threads/uefi-2011-certificates-expire-in-june-2026.183799/

Proxmox VE 9.2 release announcement:
https://forum.proxmox.com/threads/proxmox-virtual-environment-9-2-available.183742/

Microsoft - Secure Boot troubleshooting guide:
https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d

Microsoft - Registry key updates for Secure Boot Windows devices with IT-managed updates:
https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

Microsoft - manage-bde protectors command:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/manage-bde-protectors

Proxmox Networking Linux Bridge vs OVS Bridge

6/1/2026

Proxmox virtual switches and networking demystified: Trunk-mode Ports and Access-mode Ports

One common question regarding Proxmox network setup is WHICH of the options to use when creating Proxmox network interfaces when you need to pass multiple VLANs across a Trunk-mode switch port versus simple access-mode port setups.

Here's a quick cheat sheet:

Trunk mode required:

Linux VLAN interfaces (eno1.10, bond0.20)
Physical NIC (eno1)
└── VLAN interface (eno1.10)
└── Linux Bridge (vmbr10)
└── VM vNICs

VLAN-tagged OVS IntPorts
Physical NIC (eno1)
└── OVS Bridge (ovsbr0)
├── OVS Port (eno1) ← uplink, trunk to switch
└── OVS IntPort (vlan10) ← internal port, tagged VLAN 10
└── Linux Bridge (vmbr10) ← optional, for VM attachment
└── VM vNICs

Trunk mode optional These can run as simple access bridges or VLAN-aware bridges depending on how you configure them:

Linux Bridges
Physical NIC (eno1) ← trunk port on switch
└── Linux Bridge (vmbr0) ← VLAN-aware bridge
├── eno1 (uplink port, trunk)
├── VM vNIC (VLAN 10) ← tagged or untagged per port config
└── VM vNIC (VLAN 20) ← tagged or untagged per port config

OVS Bridges
Physical NIC (eno1) ← trunk port on switch
└── OVS Bridge (ovsbr0) ← single bridge, all VLANs
├── eno1 (uplink port, trunk)
├── VM vNIC (port tagged VLAN 10)
├── VM vNIC (port tagged VLAN 20)
└── VM vNIC (trunk port, multiple VLANs)

Access-mode switch port connections:

A Linux Bridge itself can have multiple IP addresses (small configuration with management and corosync on the same bridge for example).

Physical NIC (eno1) ← access port on switch (single VLAN)
└── Linux Bridge (vmbr0) ← simple bridge, no VLAN awareness
├── eno1 (uplink port)
├── VM vNIC (VM1)
└── VM vNIC (VM2)

vmbr0 ← bridge interface itself gets IPs
├── 192[.]168[.]10[.]1/24 ← primary IP (host management)
└── 192[.]168[.]10[.]2/24 ← secondary IP (additional host service)

An OVS Bridge is different than a Linux Bridge in that while OVS is just a Layer-2 virtual switch, you can't assign an IP directly to the OVS bridge itself, you need an OVS IntPort for that.

Physical NIC (eno1) ← access port on switch (single VLAN)
└── OVS Bridge (ovsbr0) ← single broadcast domain
├── eno1 (uplink port)
├── OVS IntPort (ovsbr0-mgmt) ← internal interface exposed to kernel
│ ├── 192[.]168[.]10[.]1/24 ← primary IP
│ └── 192[.]168[.]10[.]2/24 ← secondary IP alias
├── VM vNIC (VM1)
└── VM vNIC (VM2)

A Linux Bond or an OVS Bond can connect using Access Mode or Trunk Mode.

Get this one decision right before you touch anything else, and the rest of your Proxmox network config starts to make a lot more sense.

CISA SCuBA Goggles and SCuBA Gear

4/24/2026

In 2023 the Cybersecurity and Infrastructure Security Agency (CISA[.]gov) introduced their Secure Cloud Business Applications (SCuBA) project with two sub-projects: SCuBA Gear for M365 and SCuBA Goggles for Google Workspace.

These secure configuration baselines (SCBs) for Microsoft 365 (M365) and Google Workspace (GWS) provide easily adoptable recommendations that complement an organization’s unique requirements and risk tolerance levels. The baselines include automation features to help federal agencies, businesses and organizations rapidly assess their M365 and GWS services.

ScubaGear is a no-cost assessment tool that verifies M365 tenant configuration alignment to the policies described in SCuBA’s secure configuration baselines. CISA has made this tool and the baselines available to all agencies and private sector organizations seeking security improvements. Visit CISA’s GitHub and PowerShell Gallery to view the M365 baselines and download the ScubaGear assessment tool.

ScubaGoggles is a no-cost assessment tool that verifies a GWS organization’s configuration conforms to the policies in SCuBA’s secure configuration baselines. ScubaGoggles provides a breakdown of security vulnerabilities in GWS, allowing organizations to see where changes should be made to their configuration. CISA has made this tool and the baselines available to all agencies and private sector organizations seeking security improvements. Visit CISA’s GitHub or Python Package Index page to view the GWS baselines and download the ScubaGoggles assessment tool.

Source: CISA[.]gov: https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project

Deploying IBM Virtual HMC (vHMC) 11 on Proxmox

4/11/2026

IBM Virtual Hardware Management Console 11 (vHMC-11) Dashboard Example

IBM only provides instructions for deploying the Virtual Hardware Management Console on KVM running on Red Hat or Ubuntu, neither of which will probably be running in most datacenters that have an IBM Power system.

So, we undertook the task of figuring out how to deploy the new vHMC version 11 on Proxmox and the IBM instructions for KVM deployment are of no help for this endeavor. After downloading the ~6.8GB IBM vHMC tar.gz file, you'll need to unzip to a folder, resulting in a nearly 13GB .tar file. Don't try to expand this file unless you have about 510GB (yes, gigabytes) of extra disk space on your PC. If you DO have that extra space, the .tar file expands into a 500GB disk1.img file and four other files (see image below)

Files in the IBM vHMC 11 for KVM tar archive

If you have the extra disk space on the PC to expand the .tar file you can then use WinSCP to secure copy the file over to the Proxmox server, again taking care to make sure you have enough disk space (510GB EXTRA Gigabytes) to /tmp or /var/tmp.

In our case, we needed a "bridge" to park the expanded tar archive so we elected to use a NAS storage device that supported both SMB/CIFS as well as NFS 4.x.

Then, on the Proxmox server we mounted the shared folder as an NFS mount on the Proxmox server (see image below) which created three subfolders: images, import, and template . After mounting the shared folder on the NAS to the PC and using an archive extraction tool we unzipped the files to the shared folder's subfolder named IMPORT.

Proxmox - mount NFS storage

Next, you need to create a virtual machine definition on the Proxmox server, but on the tab for Disk you remove the default disk, creating a VM definition with CPU, RAM and networking but no pre-provisioned disk space. Now that the VM is created, notate the VM ID number, in our example here the ID is 101.

Now, we will use the QM IMPORTDISK command to convert the disk1.img file into a Proxmox QEMU disk image file.

Select the Proxmox server node you want to use for the import, click on >SHELL to get a command line, and navigate to the mounted NFS share:

cd /mnt/pve/vz/INSERT_NFS_NAME_HERE/import

If you do a ls -la command you will see the files extracted from the .tar file

List of files from vHMC .tar archive

The syntax for the import command is as follows:

qm importdisk VMID /LOCATION_OF_img_FILE/disk1.img TargetStorageName

In our example the command is as follows, which places the converted .img file onto our internal ZFS storage array:

qm importdisk 101 /mnt/pve/synnas01/import/disk1.img pxmxsvr1ZFS

***(remember, do NOT leave the SHELL environment until the import is COMPLETE or it will abort the command)***

qm import disk command example to import .img file

Once the disk1.img file has been imported you can go back to the Proxmox manager and select your VM and go to the Hardware tab. You will see a device name Unused Disk 0.

Click on the Unused Disk 0 and select EDIT from the top menu, which will initiate the Add Unused Disk wizard. Click on ADD and the imported disk will now be added to the new vHMC virtual machine.

Once this process is complete, you can edit any other VM hardware items as needed. The base vHMC image configures four (4) network adapters within the virtual machine. Eth0 is intended to be the management interface and Eth1 is the primary interface for the HMC port vLAN. In smaller environments your vHMC and the Power System HMC port may be configured on the same VLAN. Adjust the quantity of network adapters as needed. IBM's default recommendation is for (4) virtual CPUs and 16GB of RAM.

Once these items are modified as necessary, there is one more order of business to tend to: adjusting the BOOT ORDER of the devices so that the VM will boot when you start it.

Navigate to Options -> Boot Order, and check the box for Enabled next to the scsi0 disk, then grab the hamburger menu next to the #3 and drag the scsi0 device to the top of the boot order list. Then click OK.

Change VM virtual disk boot order

Click on START to power on your new vHMC virtual machine and then >Console to watch the boot process. Once the boot cycle completes (yes, it takes FOREVER to boot) then you can log into the management GUI (hscroot / abc123) and begin the configuration process for setting up the network(s) devices.

Your mouse will NOT work on the two initial setup questions that pop up, you will need to use the keyboard arrow keys and the TAB key.

*note: network changes will not take effect until the vHMC is rebooted.

IBM vHMC 11 login screen

IBM vHMC 11 Main Dashboard

Multiple DHCP Scopes in Windows Server DHCP

2/5/2026

If you're using a Windows server as a DHCP server, you can configure multiple DCHP scopes for different VLANs.

There are two main concepts to understand for this setup:

1) Each scope needs a route to reach the intended VLAN via the route setting in the scope;

2) Your core switch that controls your VLAN settings needs to have a "helper IP" set to know where to route DHCP requests on each VLAN. In addition to these settings, the DCHP server's assigned VLAN and static IP address must have the ability to reach each VLAN segment that it is serving via inter-VLAN routing if the DCHP server only has a single network interface.

So, don't put your DCHP server on a VLAN with other servers or devices that should not be reachable by endpoint devices that it is servicing for DCHP requests. For example, don't put your DCHP server on your servers VLAN and have it serve up DCHP requests for your Guest Wifi VLAN.

Also, just a quick note about the Filters setting. Filters are applied to the entire DHCP server instance, not on a per-scope basis. If you enable ALLOW filtering, only those MAC addresses listed in the Allow filter list will get an IP address via DCHP. All other DHCP requests will be denied. If you enable DENY filtering, any MAC address in the Deny filter list will be denied an IP address while all other devices will be assigned an IP.

Installing Uptime Kuma on Ubuntu 24.04

5/5/2025

These instructions assume the installation of Ubuntu 24.04 has already been done. The example USERID for the Ubuntu login will be UbuntuUser. The example USERID for the Uptime Kuma admin screen will be KumaAdmin. Adjust instructions accordingly.

Log in to the Ubuntu instance and launch a terminal window.
In our example, this will put us in the /home/UbuntuUser folder.
Verify your folder ID by typing pwd at the terminal command promt

sudo apt-get update -y

sudo apt-get upgrade -y

sudo apt-get install nodejs -y

sudo node -v to check the nodejs installed version

sudo apt-get install git -y

sudo git clone https://github.com/louislam/uptime-kuma.git

You can verify the git clone process by typing ls -l at the prompt which should now show an uptime-kuma folder

sudo apt-get install npm --no-install-recommends

at the /home/InsertUserIDHere prompt type: cd uptime-kuma

sudo npm run setup
*this will install uptime-kuma

sudo npm install pm2 -g

**PM2 is a production process manager for Node.js applications with a built-in load balancer. It allows you to keep applications alive forever, to reload them without downtime, and to facilitate common system admin tasks.

sudo pm2 install pm2-logrotate

*You should see output similar to the image below:

Verify your location is still /home/InsertUserIDhere

cd uptime-kuma
*type pwd to verify location is /home/InsertUserIDHere/uptime-kuma

sudo pm2 start server/server.js --name uptime-kuma

*You should see output similar to the image below:

If you do not see this output, then type:

sudo pm2 status

Now, type:

sudo pm2 startup

sudo pm2 save

cd /etc/systemd/system

sudo nano pm2-root.service

find the line labeled Environment=PATH=....

go to the end of the line

add the following: :/home/InsertUserIDHere/uptime-kuma/server
*note: be sure to include the : and do not put a space after the end of the previous entry on the line

Ctrl+O to write file edits to disk. Ctrl+X to exit nano editor

Now, we'll install the Nginx web server:

sudo apt-get install nginx -y

sudo nano /etc/nginx/conf.d/kuma.conf

Add the following lines:

server {
listen 80;
servername kuma.example.com;
location / {
proxy_pass http://localhost:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}

Ctrl+O to write file to disk. Ctrl+X to exit nano editor.

Now, copy the kuma.conf file to /etc/nginx/sites-available folder by typing:

sudo cp /etc/nginx/conf.d/kuma.conf /etc/nginx/sites-available/kuma
*note: leave the .conf off of the target filename

Now, create a symbolic link in the /etc/nginx/sites-enabled folder to the kuma file in the /etc/nginx/sites-available folder

sudo ln -s /etc/nginx/sites-available/kuma /etc/sites-enabled/kuma

Verify the link by:
cd /etc/nginx/sites-enabled
sudo ls -la
There should be a kuma symbolic link file in the /etc/nginx/sites-enabled folder

Remove the Nginx default website link
cd /etc/nginx/sites-enabled
sudo rm /etc/nginx/sites-enabled/default
sudo ls -la

Reboot the host:
sudo reboot

Now, you should be able to navigate within the Kuma host linux system using a browser to:
http://localhost:3001

This will bring up the initial setup Kuma administrator login screen.

**NOTE: Be careful in choosing your admin USERID here as there is not a simple process for changing this ID once it is created and written into the SQLlite database.

Remove Ghost Network Adapters in Windows

4/19/2025

Ghost adapters left behind by physical-to-virtual conversions have been an issue since the early days of virtualization. The Great VMWare Exodus has brought this issue back into the limelight as Broadcom customers begin to abandon VMware in favor of more customer-friendly Type 1 Hypervisor companies.

If you're preparing to migrate a VMware virtual machine over to, let's say a KVM-based Type-1 Hypervisor environment, there are several preparation steps that should be undertaken, the first of which will be to change the network adapter from a static IP addresss to a DHCP address, and to remove the VMware Tools. If you forget to remove VMware tools prior to conversion, the converted VM may not boot. If you forget to manipulate the network LAN adapter settings, you could end up with a "ghost" adapter, one that has entries in the Windows registry, but that does not show up in device manager. If you also forgot to change the static IP address to a DHCP address, the static IP could be "trapped" by the ghosted adapter and Windows will give you error messages saying another adapter already has that IP address.

Here's how to "reveal" those ghosted adapters so you can clean up the mess left behind by a hypervisor platform migration.

1. Launch a command prompt as administrator in the VM.
2. Run: set devmgr_show_nonpresent_devices=1 (press enter)
3. Launch Device Manager (devmgr.msc or devmgmt.msc)
4. In Device Manager -> View select "Show Hidden Devices"
5. Scroll down to Network Devices and expand
6. Ghost adapters will be greyed out - right click and Uninstall
7. Select Action -> Scan for Hardware Changes to refresh device list
8. Repeat as necessary until all ghost adapters are removed

Windows OS Hub has a write-up on this process here: https://woshub.com/remove-hidden-ghost-network-adapter-windows/

Interworks has a blog post about the topic here:
https://interworks.com/blog/ijahanshahi/2014/08/21/removing-hidden-device-device-manager/

The official VMware-to-Proxmox conversion instructions are here:
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE

Scale Computing has their own SC//Migrate toolkit to make VMware to Scale migrations easy:
https://www.scalecomputing.com/resources/sc-migrate-data-sheet