[TUTORIAL] Converting a Linux Desktop PC into a Proxmox Server — Preserving Full Desktop Functionality via Native OS in LXC

[FredGrekov]

Concept​

The goal: turn an existing Linux desktop into a Proxmox node without losing the working environment. No OS reinstall, no VM. The native MX-23 installation, residing on its own SSD partitions, is mounted and launched as a privileged LXC container inside Proxmox.

The same physical disk partitions serve two modes:

• Native boot: GRUB entry → MX-23 loads as a regular desktop OS.​
• Proxmox mode: GRUB entry → Proxmox loads → MX-23 auto-starts as LXC container 230 with full access to GPU, input devices, audio, and the filesystem.​

Hardware: Intel X58 / Xeon X5650 / AMD RX-560 4GB / 32GB RAM Proxmox VE: 9.2 (on a native SSD partition, booted via shared GRUB) Guest OS: MX-23

IMPORTANT !: It is intended for experimentation and personal use and is not recommended for critical or production environments.
Use it only if you understand and accept the associated security and reliability risks.

Key Challenges and Solutions​

Most of the work is concentrated in the LXC container config file. Since I am not a Linux/PVE "Sensei" - I worked from advice and, after failures, from AI assistants (various ones).

0. Preparing the PC. Installing Proxmox on the PC's Disk​

0.0-- Useful/required: a separate Live-GParted flash drive (Ventoy + GParted ISO).

0.0 On the PC's SSD, free up a few dozen GB and create an LVM partition there. On my SSD — which has many partitions for multiple OSes — I deleted an old unused one and reshuffled GParted to carve out 44 GB. If there is no free space but some partitions have enough slack, booting from Live-GParted lets you easily (though not quickly) rearrange partitions and allocate what you need. Besides LVM, it makes sense to leave a bit of space (1 GB+) for relocating the Proxmox EFI partition.

After changing partitions in GParted — it is useful/necessary to verify the modified partitions (e.g. with GParted itself) and reboot into your native OSes.

0.1 Install Proxmox natively from their ISO to an additional disk. A small spare SSD works fine, but requires opening the case. I didn't have one (summer in the countryside)... so I installed onto a spare 16 GB flash drive. In the PC BIOS, keep the primary boot pointing at the native GRUB; to boot from the Proxmox flash drive, use the BIOS Boot Menu.

0.2 Add a Proxmox boot entry to the native GRUB by copying from the Proxmox grub.conf into the native OS grub.conf, so it boots from the flash drive for now. To avoid "reading tea leaves" — it is useful to consult an AI on how to correctly form this entry for your specific PC configuration and boot setup. You can also copy the EFI partition from the flash drive and try setting up a chainload entry in the native GRUB, or copy the needed entries directly if the bootloaders are compatible. For me they were not (old PC), so AI advice simplified things considerably.

0.3 Boot into Proxmox and move (migrate) the Proxmox LVM partition entirely to the PC's SSD, into the LVM created earlier, using standard LVM commands/utilities (AI advice helps navigate the dark here):

lsblk // lvs // vgs // pvcreate // vgextend // pvmove // vgreduce // pvremove // lvresize ...

For faster transfer — a USB 3.x connection is recommended.

You can also remove the swap logical volume from the Proxmox LVM group if the PC has a native swap — this reclaims 2 GB for PVE storage:


swapoff /dev/pve/swap
lvremove /dev/pve/swap

Then add the native swap to the host's fstab.

If everything goes smoothly, the flash drive will have an empty LVM partition left. Once Proxmox boots normally from the native GRUB, the flash drive is no longer needed and can be removed.

0.4 For convenient subsequent configuration of both PVE and the native OS — installing a light desktop and favorite tools on Proxmox is worthwhile. I installed XFCE, which pulled in everything needed for X. The only "overhead" is disk space, if you don't use those X tools afterward. After this, the default Proxmox boot will land in X, and if you keep X on Proxmox, you should add a separate console-mode Proxmox GRUB entry to the shared GRUB. It can also be useful to install a console mouse driver on both host and guest — it will work in console-mode Midnight Commander.

0.5 On the Proxmox host OS — it is useful/necessary to mount all partitions used by the native OS. Even if there is only root. While rootfs can apparently be mounted from a raw partition — having native OS filesystems accessible via host mount points is convenient and also guards against double-mounting the same partition simultaneously. This is easily done by copying fstab lines from the native OS into the host's fstab. In my case, MX has separate mounts for: home partition, other OS partitions, NTFS, Steam. The "reverse" variant — mounting the PVE LVM into the native OS — may also be useful, though it lacks the dynamic Proxmox filesystems.

1. Initial LXC Config and rootfs from a Native Partition​

To set up the needed LXC config initially, you can create a standard LXC with an OS template type matching your native OS, specify the passthrough and mount entries, and set the primary disk size to 1 GB. That's what I did, starting "in complete darkness" — but that disk is not needed for the guest to operate, and there is no way to remove it afterward. So it may be better to start from scratch, adding mandatory or needed lines based on some test config example. This description also omits network and other infrastructure options.

Proxmox GUI expects rootfs to point to a managed volume. To use a raw partition, bypass the GUI and write directly to the LXC config:

rootfs: /mnt/mx23root,size=0

size=0 disables quota management. The partition must be mounted on the host before the container starts.

Other partitions in my example are mounted like this:

mp0: /mnt/mx23home,mp=/home,shared=1

lxc.mount.entry: /mnt/DATA mnt/DATA none bind,optional,create=dir

lxc.mount.entry: /mnt/Steam-Linux mnt/Steam-Linux none bind,optional,create=dir

Both approaches work fine, and I never managed to get a clear explanation from AI about the advantages of each. I used MP for home on the assumption that PVE manages it more explicitly in that mode.


Since MX-23 is not a standard Proxmox template, and it is important to preserve its native settings, set:

ostype: unmanaged

This prevents Proxmox from trying to modify network configs or /etc/hostname inside the container. It does, however, somewhat limit its "service" capabilities in certain LXC config options.

2. GID When Passing Through /dev/... Devices​

When passing through /dev/... devices, they carry group permissions. These matter when services running as non-root — such as lightdm or render — access those devices. For root and root-owned services, this is irrelevant.

So you need to compare GIDs between the host and the guest. When there are GID mismatches in the groups used by passed-through devices, there are three ways to resolve the "conflict":

• Use lxc.hook.autodev:... with chown root:{GID} /dev/... — but if X is running on PVE, after starting our LXC those permissions will change for both.​
• Use GID settings in mount options — but because of unmanaged, not all variants work.​
• The simplest, most transparent, reliable and safe approach (though I hesitated for several weeks before trying it): use standard commands inside the guest OS to change the GID numbers for the affected groups to match the host's values. When conflicts arise with existing GIDs, shift them further in a chain.​

The "safe" assumption holds because most of these groups are tied specifically to /dev/... devices and will not affect access to ordinary filesystems.

3. AMD GPU Passthrough to LXC​

The situation with Intel is similar; with Nvidia it is probably a bit more involved, but installing the drivers on the host OS after setting up X should make it straightforward.

For LXC (unlike passthrough to a VM) there is no need to blacklist amdgpu on the host. The host must initialize the GPU and create device nodes that the container will bind-mount.

lxc.cgroup2.devices.allow: c 226:0 rwm # /dev/dri/card0
lxc.cgroup2.devices.allow: c 226:128 rwm # /dev/dri/renderD128

lxc.mount.entry: /dev/dri/card0 dev/dri/card0 none bind,optional,create=file,gid=44
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file,gid=993

4. Framebuffer​

lxc.cgroup2.devices.allow: c 29:0 rwm
lxc.cgroup2.devices.allow: c 235:0 rwm # /dev/kfd (ROCm/Vulkan compute)
lxc.mount.entry: /dev/kfd dev/kfd none bind,optional,create=file,gid=993
lxc.mount.entry: /dev/fb0 dev/fb0 none bind,optional,create=file,gid=44

For RX-560 (Polaris gfx803): ROCm 6.x officially dropped support for this GPU. Use Mesa RADV + Vulkan instead — works excellently for both display (X11) and compute (llama.cpp Vulkan backend).

5. Input Devices (Keyboard, Mouse)​

lxc.cgroup2.devices.allow: c 13:* rwm

lxc.mount.entry: /dev/input dev/input none bind,optional,create=dir

6. Audio (ALSA) and WebCam​

lxc.cgroup2.devices.allow: c 116:* rwm

lxc.mount.entry: /dev/snd dev/snd none bind,optional,create=dir
lxc.mount.entry: /dev/v4l dev/v4l none bind,optional,create=dir

=====

For other hardware, PCs and OSes, the device numbers and passthrough lines may differ. For example, webcam passthrough is not covered here. Check the relevant ls* commands on the PVE host.

=====

7. Virtual Terminal Allocation (the Display Manager Problem)​

The Proxmox host occupies VT1 (TTY1) — text console — and the standard other TTYs. If the guest LightDM also tries to start on VT1, it sees Seat0 with CanGraphical=no and refuses to launch X11. On top of that, for the guest OS to work as a desktop, it needs at least one "own" TTY for X and another for a text console.

Solution: force the guest display manager to a freed VT and pass the corresponding TTY devices into the container. In the host OS systemd configuration, limit its TTYs to two. The host X VT can optionally be shifted from TTY7 to something else, e.g. TTY6. In the guest OS systemd and Xorg configuration, limit its TTYs to four and direct the DM to, for example, TTY3. This can be done while still in the native boot of the guest OS.

lxc.cgroup2.devices.allow: c 4:3 rwm

lxc.cgroup2.devices.allow: c 4:4 rwm

lxc.mount.entry: /dev/tty0 dev/tty0 none bind,optional,create=file

lxc.mount.entry: /dev/tty3 dev/tty3 none bind,optional,create=file

lxc.mount.entry: /dev/tty4 dev/tty4 none bind,optional,create=file

In /etc/lightdm/lightdm.conf inside the container:

[LightDM]

minimum-vt=3

Critical: always pass through /dev/tty0 — both host and guest use it to identify the currently active TTY!

Result: Proxmox console on Alt+F1 and Alt+F2, MX-23 XFCE desktop on Alt+F3, its text console on Alt+F4. Clean separation.

At this stage it makes sense to use the lxc.init option to start the container in console-only mode. To test X, you can run startx from the guest console or via pct enter .... After testing, revert lxc.init to the standard startup.

8. udev and /sys — The Most Critical Point for Xorg Input via udev!​

This is the step that will cost the most debugging time — both yours and any AI's — if missed.

udev inside the container requires read-write access to /sys. Without it, udev does not start properly! Symptoms:

• /proc/bus/input/devices correctly lists all input devices (kernel level, always works)​
• LightDM Seat0 shows CanGraphical=no​
• X11 cannot find keyboard or mouse​

Fix: lxc.mount.auto: sys:rw gives the container a properly mounted /sys with write access.

lxc.mount.auto: sys:rw

Also mandatory: lxc.autodev: 1 — the container gets a fresh /dev populated by the host's udev rules.

=====

Final Working LXC Config (Key Lines)​

arch: amd64
stype: unmanaged

hostname: MX-23-1

memory: 11111
cores: 5
swap: 512

cmode: tty
console: 1
tty: 4
lxc.tty.max: 2

features: nesting=1,fuse=1

lxc.apparmor.profile: unconfined
lxc.seccomp.profile: /etc/pve/lxc/bypass.seccomp # - The content of this file is below...
lxc.mount.auto: proc:rw sys:rw
lxc.autodev: 1


rootfs: /mnt/mx23root,size=0
mp0: /mnt/mx23home,mp=/home,shared=1

..........

File content: bypass.seccomp:
2
blacklist
# Allow EVERYTHING! Not just... ioctl for VT
# ioctl allow
# Allow basic resource management calls
# sysinfo allow

- It might make sense to enable these options in some cases.

..........

What Works Inside the LXC Container​

• Full XFCE desktop on a physical monitor (via bound TTYs)​
• AMD RX-560 hardware acceleration (Mesa RADV / Vulkan)​
• Keyboard and mouse (full udev enumeration after /sys fix)​
• All data partitions (NTFS, ext4) via bind-mount​
• ALSA audio​
• Steam + Proton games (Vulkan, native libraries)​
• All native MX-23 applications, AppImages, scripts​
• Docker installed natively works great inside LXC; however, for running Docker containers installed in LXC mode when booting natively into MX-23 — AppImages need to be used​
• Scripts that directly control the RX-560 fan via /sys/.../proc/... work perfectly inside LXC​
• Network via veth bridge (note: guest IP may change)​
• Hardware sensors (lm-sensors) — according to the PVE kernel! For example, in LXC the amdgpu-500 sensor exposes more parameters than in the native boot​

What Does Not Work in LXC​

• Loading new kernel modules (insmod/modprobe) — kernel is shared with the host​
• Mounting loop devices​

Bonuses from Running a Desktop OS Inside Proxmox LXC​

Compared to a purely native install, running the desktop as an LXC container under Proxmox gives several operational advantages essentially for free:

Any guest runs on the latest PVE kernel. For example, native MX-23 on Debian 12 uses kernel 6.1 — but inside LXC it runs happily on kernel 6.8+!

Snapshots before risky operations. Before updating drivers, the kernel, or major packages — one command (pct snapshot 230 before-kernel-update). Roll back in 30 seconds, no live USB needed.

Resource adjustment without rebooting. During heavy server tasks, reduce CPU cores or RAM for the desktop container via the Proxmox GUI or pct set, then restore afterward. No restart required.

Parallel containers alongside the desktop. On the same hardware, separate LXC containers can run database servers, AI inference (Ollama, llama.cpp), development environments — isolated from the desktop OS.

Console always available. Even if X11 inside the container crashes completely, the Proxmox web console (noVNC) gives access to the container's TTY — no KVM switch or physical keyboard needed.

Clean separation of "desktop" and "server". The Proxmox host stays minimal (no GUI). The desktop OS lives in a container that can be stopped, cloned, or rolled back to a snapshot independently.

Conclusion​

Two non-obvious blockers in this setup, not described in standard documentation (due to which all AIs — Gemini, the esteemed GPT, and the venerable Claude — mercilessly tortured my defenseless intellect for over a month!):

1. udev requires /sys with write access inside the container — lxc.mount.auto: sys:rw resolves this. Without it, input devices and the display manager fail silently in ways that look externally like GPU or TTY problems.

2. TTY allocation between the host and guest display managers must be explicit — pass specific /dev/ttyN devices, crucially including /dev/tty0, and configure minimum-vt in LightDM accordingly.

Everything else follows standard Linux, kernel, device passthrough, Proxmox, and LXC documentation.

 

[Sviat]

Hi,

In addition to the security concerns, the option to disable swap makes this guide even more attractive to people who are looking for a bit of an “adventure.”

I’m absolutely not against knowledge sharing, as long as people are aware of the potential risks and can make an informed decision before trying something like this.

Since the author doesn’t currently mention this in the post, perhaps it would be helpful to add a clearly visible note such as:

IMPORTANT: It is intended for experimentation and personal use and is not recommended for critical or production environments.
Use it only if you understand and accept the associated security and reliability risks.

@FredGrekov, if you don’t mind sharing, I’d also be very interested to hear about your experience with this setup.

 

[Johannes S]

Why? If you want to use vms on your desktop virt-manager or Virtualbox are easier to setup and use.
Alternative you could use incus which can also be installed on mon-debian systems.
And if you want to go full-virtualized for security concerns qubes-os is a system designed for that particular usecase.

 

[FredGrekov]

Hi,

In addition to the security concerns, the option to disable swap makes this guide even more attractive to people who are looking for a bit of an “adventure.”

I’m absolutely not against knowledge sharing, as long as people are aware of the potential risks and can make an informed decision before trying something like this.

Since the author doesn’t currently mention this in the post, perhaps it would be helpful to add a clearly visible note such as:

IMPORTANT: It is intended for experimentation and personal use and is not recommended for critical or production environments.
Use it only if you understand and accept the associated security and reliability risks.

@FredGrekov, if you don’t mind sharing, I’d also be very interested to hear about your experience with this setup.

Greetings, Sensei!
Thank you for your comments; I agree and appreciate the feedback!

I’ve added the suggested warning and clarified some configuration options, as I didn't have this specific PC on hand when I wrote the article.

However, the article's title—along with the implied topic and context regarding PCs and Proxmox (PVE) homelabs—clearly steers enthusiasts toward experimentation and personal use.

Also, the article doesn't suggest *disabling* the swap file entirely, but rather replacing it with the host PC's native swap file (if one already exists). This helps free up a bit of valuable LVM space.

My experience with this setup has been very positive. I am replying right now from this very PC, and MX is running as an LXC container within Proxmox. Even though it has been allocated less than half of this very old PC's resources, I notice better responsiveness in both the system and the display. This might be due to the newer, more optimized Proxmox kernel—especially regarding the GPU driver.

 

[FredGrekov]

Чому? Якщо ви хочете використовувати vms на робочому столі virt-manager або Virtualbox, їх легше налаштувати та використовувати.
Альтернативою можна використовувати incus, який також можна встановити на мон-дебіальні системи.
І якщо ви хочете повністю віртуалізуватися з міркувань безпеки, qubes-os - це система, розроблена для цього конкретного випадку використання.

Thanks for the advice Johannes S.

Indeed, VMS environments - both virt-manager and Virtualbox - are wonderful systems, and I "talked" with them for many years when I worked .... )

For example, under virt-manager I configured and launched Windows as a VM from native partitions, on Virtualbox it was easier, almost standard. it was even easier—almost a standard feature—in VirtualBox. That made migrating users from Windows to Linux much smoother...

However, if we're talking about a HomeLab—where resources are limited and the hardware is aging—and the focus of your experiments is the current trend of "Modern AI," then PVE is the "best of the best"! Especially with a resource like "ttec" available! ) It allows for an almost "zero-install" setup for heaps of interesting software.
Sure, one could look at Docker—and those AI tools strongly suggested that path too... But, as we say in Odesa, "That's a whole different ball game..." ))

That said, there's nothing stopping you from running it inside one or more LXC containers.
It actually happened automatically for me: Docker, natively installed on MX-23, continued working perfectly "out of the box" inside its LXC containers!

And under such resource constraints, it would be impossible, senseless, and against the "Master of the House's" rules to simply dedicate a GPU—even an old or weak one—solely to the desktop workstation without utilizing it for AI/LLM tasks!
The "VM" approach completely monopolizes the GPU!
LXC, on the other hand, transparently shares the GPU among all the "Tensor-hungry" processes—within the limits of its capabilities, of course...

 

[Johannes S]

However, if we're talking about a HomeLab—where resources are limited and the hardware is aging—and the focus of your experiments is the current trend of "Modern AI," then PVE is the "best of the best"! Especially with a resource like "ttec" available! ) It allows for an almost "zero-install" setup for heaps of interesting software.

I don't know any resource called "ttec". If you mean ttecks helper scripts: After tteck passed away it evolved to a community-maintained project. Personally however I think that these helper scripts are NOT a good resource for beginners except if they want to learn shell scripting.
Basically they do lot of non-supported stuff (like running docker inside lxcs or putting openmediavault in lxcs: https://forum.openmediavault.org/in...ccess-additional-drives-via-proxmox-with-lxc/ ) and lure beginners in setting things up they don't understand and get bitten later ( https://forum.proxmox.com/threads/vm-shots-down-and-starts-on-its-own.143821/, https://forum.proxmox.com/threads/vm-stop-and-start-every-5-minutes.152586/ https://forum.proxmox.com/threads/vm-resetting-after-every-6-minutes.127110/ ) I'm not a fan of making shooting yourself in the foot easier. Instead people should use the right tool for the right job, ProxmoxVE isn't desktop virtualization and propably never will be.

If you want to play around with local models you don't need ProxmoxVE, you just needs a capable GPU and a way to setup the local models which can easily be done with docker. Putting ProxmoxVE on it just adds additional complexity (the joys of GPU passtrhrough) without any benefit.

I also don't see why limited resources and aging hardware are any argument in favour of such a setup, if your hardware resources are constrained it's even more a good idea just not to bother with ProxmoxVE but just use the Linux distribution of your preference together with docker and maybe virt-manager or Virtualbox for 1-2 playground VMs.

Sure, one could look at Docker—and those AI tools strongly suggested that path too... But, as we say in Odesa, "That's a whole different ball game..." ))

Why? It doesn't matter whether you use some docker-compose file or some helper script for setup, you won't learn anything in both cases.

 

[FredGrekov]

I don't know any resource called "ttec". If you mean ttecks helper script:s After tteck passed away it evolved to a community-maintained project. Personally however I think that these helper scripts are NOT a good resource for beginners except if they want to learn shell scripting.
Basically they do lot of non-supported stuff (like running docker inside lxcs or putting openmediavault in lxcs: https://forum.openmediavault.org/in...ccess-additional-drives-via-proxmox-with-lxc/ ) and lure beginners in setting things up they don't understand and get bitten later ( https://forum.proxmox.com/threads/vm-shots-down-and-starts-on-its-own.143821/, https://forum.proxmox.com/threads/vm-stop-and-start-every-5-minutes.152586/ https://forum.proxmox.com/threads/vm-resetting-after-every-6-minutes.127110/ ) I'm not a fan of making shooting yourself in the foot easier. Instead people should use the right tool for the right job, ProxmoxVE isn't desktop virtualization and propably never will be.

If you want to play around with local models you don't need ProxmoxVE, you just needs a capable GPU and a way to setup the local models which can easily be done with docker. Putting ProxmoxVE on it just adds additional complexity (the joys of GPU passtrhrough) without any benefit.

I also don't see why limited resources and aging hardware are any argument in favour of such a setup, if your hardware resources are constrained it's even more a good idea just not to bother with ProxmoxVE but just use the Linux distribution of your preference together with docker and maybe virt-manager or Virtualbox for 1-2 playground VMs.




Why? It doesn't matter whether you use some docker-compose file or some helper script for setup, you won't learn anything in both cases.

Thanks for the advice and the lessons!

You’re right—I’m a newcomer to Proxmox and the intricacies of Linux, and I use tteck’s scripts in a rather amateur, superficial way. However, that approach gives beginners a chance to use and explore interesting, useful software without having to spend time becoming experts in installation and configuration right off the bat.

I should apologize for the brevity of my description regarding the context and motivation behind this article's use case. That brevity shifted the focus—and your comments—toward secondary factors.

Your observations and advice are entirely valid and interesting, especially for a standalone PC setup. When I referred to a "HomeLab," however, I was thinking in terms of an average or minimal hardware and system configuration.

In doing so, I essentially sidelined the core point of my article, moving it far away from the professional or production-grade use cases of the excellent PVE platform.

My own "HomeLab" actually started three years ago with a single old mini-PC where I tried out Home Assistant—which, at the time, most of the community recommended running as a VM or LXC container on PVE.

But times and trends have changed. Now, my setup consists of a stack of four mini-PCs and an older "Home Server" class PC (Socket 2011), all combined into a PVE cluster. With the ambitious goal of creating something akin to an "AI-Frankenstein" or perhaps even "JARVIS"... ))
The PC—the "hero" of this article—was a standalone machine at the time, serving as my home workstation. I hadn't yet found a concept I liked for utilizing a native desktop OS on a Proxmox (PVE) host without sacrificing functionality—both for the OS itself and for GPU-accelerated applications (a VM-based approach would have monopolized the entire graphics card).

And this was the very PC I took along on a trip to visit friends in another city...
If not for two "coincidences"—being forced to stay there for the entire summer and losing connection to my "HomeLab"—the project described in this article might never have come to be. )

 

[aureladmin]

If you want to play around with local models you don't need ProxmoxVE, you just needs a capable GPU and a way to setup the local models which can easily be done with docker. Putting ProxmoxVE on it just adds additional complexity (the joys of GPU passtrhrough) without any benefit.

I'll jump into the discussion even though I'm not the thread starter — there are some very fair points in your message (especially about the tteck scripts and the lack of real learning behind them).

I'd just like to nuance the point about "you don't need Proxmox to play with local models, it adds no benefit" — not to contradict you head-on, but because my own experience points somewhat the other way.

I have an ongoing project, HiveWaggle, which runs a full local AI stack (agents, GPU inference, multi-model jury) inside an LXC container under Proxmox, and it's been working very well in production on my end for a while now. So I'd say running AI through LXC isn't a mistake in itself — but it does require real work: fine-grained GPU management, network isolation, snapshots before updates, hot-adjusting resources, and so on. It's definitely not "zero-effort," I agree with you there, but the benefits are real in my case.

In a setup like mine — you already know a bit about it from HiveStation — it's actually especially useful: I work on a laptop with both an iGPU and a dGPU. Proxmox/LXC lets me split workloads between the two GPUs without monopolizing either one inside a fixed VM, which matters quite a bit on a laptop where you can't just bolt on more hardware.

It also lets me run continuous automated VM test benches (disposable VMs spun up/torn down automatically for testing) alongside everything else, without disrupting either the desktop or the AI services running in parallel on the same host. And Proxmox gives you a proper network architecture to cleanly segment all of this — dedicated bridges, traffic segmentation between desktop/AI/test workloads.

So yes, it clearly adds complexity compared to "just Docker on a bare distro" — but in my case, with multiple GPUs and multiple use cases that need to coexist, that complexity has a real payoff. That said, I fully understand it's not the right trade-off for everyone, especially for someone just starting out!

 

[Kingneutron]

Good on you for getting everything sorted and working, but this seems ridiculously complex compared to simply having a proxmox server plus a separate desktop.

Before the RAMpocalypse you could find used laptops around $100 that you could install MX-23 on and have everything Just Work over ethernet, without worrying about a whole house-of-cards configuration and cramming everything into a custom LXC.

 

[ivenae]

You can combine your home-server environment and your kodi video player in one device – and the kodi is always on, because the server always runs.
Perfect.

 

[Shintaro1969]

Yea, what a lot of work. Well done for working that out, though.
"Not my cup of tea" but I can understand why. I remember dual booting (yes, I know its not the same) Novell NetWare/OS2 WARP Server/ UnixWare even Slackware, so I could have a server and a client.
I think the biggest win for you is the knowledge you gained along the way. I am sure you will be very familiar with what "Doesn't work" and "What breaks".
Very interesting though using MX Linux by itself or as a LXC.
Best way to learn, "Break stuff" or push it to it's limits.