Proxmox VE Guide: Deploying Linux, Windows 11, and LXC Containers

Proxmox VE gives a home lab two useful ways to run workloads: full virtual machines with their own kernels, and lightweight Linux Containers that share the Proxmox host kernel. Choosing the right one—and configuring storage, networking and drivers correctly—matters more than simply clicking Create VM.

This guide shows the workflow I use to deploy Linux VMs, Windows 11 VMs and LXC containers in my own lab. My installation media is stored centrally on a Synology DS224+, while the compute runs on Proxmox. If you are setting up your first node, start with my Proxmox VE installation and initial setup guide.

VM or LXC: which should you choose?

Workload	Best starting point	Reason
Windows 11	Virtual machine	Windows needs its own kernel, UEFI and TPM
Linux desktop or appliance	Virtual machine	Strong isolation and broad compatibility
Small Linux service	Unprivileged LXC	Low overhead and fast startup
Docker host	VM for the simplest isolation	Fewer nesting and kernel-feature complications
Trusted, lightweight Docker lab	LXC can work	Efficient, but nesting and permissions require care

I use VMs when compatibility and isolation are the priority. I use LXC for trusted Linux services where the lower memory and storage overhead is genuinely useful.

Open the Proxmox web interface safely

Proxmox VE is normally managed at:

https://<proxmox-host-or-ip>:8006

A new host normally presents a self-signed certificate. Only continue if the address is your expected Proxmox host on the trusted local network. Do not train yourself to ignore certificate warnings on unfamiliar addresses; replace the default certificate or use a trusted internal certificate once the lab is established.

The “No valid subscription” message does not prevent Proxmox VE from working. It indicates that the host is not using the paid enterprise repository and support subscription; it is not a failed installation.

Plan storage before creating guests

Proxmox storage can have different content types. An ISO must be placed on storage that permits ISO image content, while VM disks require storage that permits Disk image. Container templates, backups and snippets are separate content types again.

My Synology NAS provides a central location for installation media. In Datacenter → Storage, check that the relevant share is enabled on the intended node and allows the correct content type. Keeping ISOs on the NAS avoids maintaining duplicate copies on every hypervisor, but it should not be confused with guest-disk or backup storage.

To upload an ISO:

1. Select an ISO-capable storage entry beneath the node.
2. Open ISO Images.
3. Choose Upload, or Download from URL when using a trusted official download address.
4. Confirm the uploaded filename and size before using it.

If NFS storage behaves differently from the rest of the lab, my Synology NFSv3 troubleshooting notes cover one real compatibility issue I encountered.

Create a Linux virtual machine

Click Create VM and work through the wizard. The following is a sensible baseline rather than a universal prescription.

General and operating system

• Give the VM a clear name that describes its purpose.
• Select the Linux ISO from the correct storage.
• Record the automatically assigned VM ID if other tools will refer to it.

System, disk and CPU

• Use VirtIO SCSI single as the SCSI controller for a modern Linux guest.
• Create the disk on the storage intended for active VM data, not the ISO library.
• Enable discard only when the complete storage chain supports it.
• Start with two CPU cores and increase them from observed demand.
• host CPU type exposes host features and can improve performance, but a common CPU model is safer when live migration between dissimilar nodes matters.

Memory and network

• 2 GB is adequate for many server installations; desktop environments and larger applications need more.
• Use the VirtIO network model for a modern Linux guest.
• Select the bridge that reaches the required network, normally vmbr0 in a simple installation.
• Use VLAN tagging only when the switch and Proxmox bridge are already configured for it.

After installing Linux, install and enable the QEMU guest agent inside the VM, then enable QEMU Guest Agent in the VM options. This gives Proxmox cleaner shutdown behaviour and better guest information.

Create a Windows 11 virtual machine

Windows 11 needs a little more preparation because the installer expects UEFI, Secure Boot-capable hardware and TPM 2.0, while the most efficient Proxmox disk and network devices use VirtIO drivers.

Required installation media

• The Windows 11 ISO from Microsoft.
• The current VirtIO driver ISO from the Fedora VirtIO project.

Recommended VM settings

• Operating system type: Microsoft Windows 11/2022.
• Machine: q35.
• BIOS: OVMF (UEFI).
• Add an EFI disk on persistent storage and enable pre-enrolled keys when the wizard offers them.
• Add a TPM state disk using version 2.0.
• Allocate at least two cores, 4 GB RAM and 64 GB storage; increase these for the intended workload.
• Use VirtIO SCSI for the main disk and VirtIO for networking.

Add the VirtIO ISO as a second CD/DVD drive before booting the installer. If Windows Setup cannot see the disk, choose Load driver, browse the VirtIO media and select the appropriate storage driver for the Windows version and architecture. After Windows starts, install the remaining VirtIO drivers and guest tools so that networking, ballooning, shutdown and other integrations work correctly.

Do not disable Windows 11 checks simply to make the wizard finish. A virtual TPM and UEFI configuration are straightforward in Proxmox and leave the guest in a much cleaner state for future updates.

Deploy an LXC container

Download a container template through the storage entry’s CT Templates view, then click Create CT. Choose an unprivileged container unless the workload has a specific, understood requirement for privileged access.

• Set a hostname that matches the service role.
• Use SSH keys where possible and protect any root password.
• Start with modest CPU, memory and disk allocations; LXC resources are easy to adjust later.
• Attach it to the correct bridge and choose DHCP or a deliberate static address.
• Leave nesting disabled unless software inside the container actually needs it.

About Docker and community helper scripts

Community helper scripts can make deployment extremely fast, but a command copied into the Proxmox shell executes with extensive control over the host. Read the script, understand what repository it uses, check recent project activity and keep a backup before running it. “Popular” is not the same as official or risk-free.

Docker inside an unprivileged LXC can be efficient, but it introduces nesting, cgroup and device-permission considerations. For important or less-trusted workloads, I prefer a small Linux VM as the Docker boundary. For trusted lab services where efficiency matters, LXC may be an acceptable trade-off once those limitations are understood.

Post-deployment checks

1. Confirm the guest receives the expected IP address and can reach its gateway and DNS server.
2. Install guest updates before exposing services.
3. Verify clean shutdown and restart from the Proxmox interface.
4. Check that monitoring identifies the new guest correctly.
5. Create and test a backup job; a snapshot alone is not an independent backup.
6. Document the VM or CT ID, hostname, IP address, storage and purpose.

Before a major platform upgrade, use my Proxmox backup checklist. For the wider design behind my host, storage and service layout, see Proxmox VE as the RealmLabs infrastructure foundation.

Final result

The finished deployment process is repeatable rather than improvised: choose VM or LXC deliberately, place installation media and guest disks on the correct storage, configure the appropriate virtual hardware, install guest drivers and agents, then verify networking, shutdown and backups.

That foundation makes later services much easier to maintain. The goal is not merely to get a guest running—it is to understand how it is connected, where its data lives and how it will be recovered when something eventually breaks.