How ASNetworking Installs Proxmox: ECC, ZFS & Network Pinning

Thank you to ASNetworking for making this detailed Spanish-language Proxmox installation lesson. In chapter three of the creator’s course, the discussion moves from hardware requirements and BIOS settings to the installer, storage formats, and network interface pinning. The original 31-minute video is the source for the sequence below.

Watch before reading: This episode suits a home lab builder who wants to understand the decisions made before creating the first VM. It covers the Proxmox VE ISO, CPU virtualization features, practical memory planning, BIOS/UEFI, installation media, Ext4/XFS/Btrfs/ZFS choices, management networking, and interface pinning. The creator uses more than one type of lab hardware; the screenshots of a 32GB RAM example and a larger PC are not specifications for ZimaBoard 2.

The useful lesson is that a successful installer screen is only one part of a sound virtualization host. CPU features, guest memory, boot storage, filesystem behavior, and stable management networking all shape what the node can do later. ASNetworking shows the installation path and the resulting Proxmox interface; this episode does not benchmark VM performance or prove that every storage layout suits every machine.

Start with a verified ISO and a realistic hardware plan

The creator begins with the Proxmox VE download and verification steps before reviewing minimum and recommended requirements. Obtain the installer from the official Proxmox downloads and check the published checksum before writing installation media. This reduces the chance of troubleshooting a damaged or incorrect image as though it were a hardware problem.

A minimal 64-bit host, memory, one installation disk, and a network interface can get an installer running. That baseline says little about useful guest capacity. Budget memory for the host, every VM or container, and any storage features you choose. The 32GB graphic in the video illustrates an allocation example, with 2GB reserved for the host and 30GB assigned across guests; it does not describe either ZimaBoard 2 model. ECC memory is a desirable reliability feature on supported hardware, but it is not a universal prerequisite to install Proxmox VE. Compare your actual configuration with the current Proxmox hardware requirements.

Check virtualization features before installing

The episode explains CPU virtualization extensions and introduces IOMMU and SR-IOV. Hardware virtualization matters for running KVM virtual machines. IOMMU becomes relevant when planning device passthrough; SR-IOV is a more specialized capability that also depends on the device, firmware, and driver. These features should be checked against the planned workload, rather than treated as a checklist that every basic host must fully support.

Later, ASNetworking opens the machine’s BIOS/UEFI settings and shows Intel VT-d enabled. Firmware menus vary by manufacturer, so use the screenshot as an example of where to look, then confirm the settings and capabilities of your own system. If a passthrough project is the goal, make that decision before you build the VM around a device you cannot assign.

Choose the target disk and filesystem deliberately

After creating installation media, the creator starts the Proxmox installer. Before accepting a disk choice, identify the target drive and understand that installing an operating system can erase its existing data. This matters especially if you are repurposing a home server that already has files or an operating system on it. Preserve anything you need before changing the boot device.

The filesystem section compares conventional choices such as Ext4 and XFS with copy-on-write options such as Btrfs and ZFS. A straightforward single-disk lab and a redundant storage design do not have the same requirements. ZFS offers checksums, snapshots, and pool features, but also needs a suitable disk layout and memory budget. Snapshots help with specific recovery tasks; they are not a substitute for independent backups. The Proxmox ZFS guidance is useful before selecting it for a small host.

The ZimaBoard 2 mini home server appears again during this storage discussion with an attached drive and expansion hardware. Its compact form makes it a useful subject for a home lab, but a viewer should choose the filesystem and guest count based on the exact board model, attached drives, and available memory. The video’s other lab machines should not be used to infer ZimaBoard 2 capacity.

Keep the management network identifiable

At the network stage, identify the physical port that will carry management traffic, then check the address, gateway, DNS, and hostname before finishing setup. On a host with multiple NICs or added network cards, mixing up port names can make the web interface appear unreachable even though installation has succeeded.

“Interface pinning” in this episode refers to assigning persistent names to network interfaces. It does not mean pinning a VM to CPU cores. Proxmox provides a network interface pinning tool for this purpose; changes to the mapping require care and a reboot to take effect. The Proxmox network configuration reference explains the tool and its limitations. Keep local access available while changing management networking so a mistaken mapping does not strand the host.

Verify the host after the first boot

The closing screen shows the Proxmox VE web interface with two nodes named zima1 and zima2. Seeing the nodes in the management view confirms that the interface is accessible in this lab; it does not, by itself, establish shared storage, failover, or a production-ready cluster. For your own installation, first verify that the intended host, disks, and network interfaces appear correctly. Then create a small test VM, restart the host, and confirm that management access and storage return as expected.

ASNetworking’s full Proxmox chapter is worth watching for the on-screen sequence and the creator’s explanations in Spanish. If you are following along on ZimaBoard 2, keep the first deployment small and make the disk, memory, and network decisions explicit before adding more virtual machines.