Proxmox Install and Configure
This content pack manages deployment of Proxmox hyperviso nodes and configuration of the installed Proxmox hypervisor.
This content pack utilizes the Debian bootenv as a baseline for the Proxmox installation. The Proxmox released "appliance ISO" is not network installable by default, and requires a fair amount of work to rip apart the ISO and rebuild it to make it network installable.
The version of Proxmox that is installed is dependent on the base Debian version you install. Examples of the Proxmox versions you will get based on the Debian base version:
- Debian 10 = Proxmox 6.x
- Debian 11 = Proxmox 7.x
Upgrading Proxmox Content Pack¶
To upgrade from the proxmox v4.9.0 and older versions, please perform the following prepatory tasks:
- Convert any existing profiles in configuration data content packs that use
Params with the name
busterin them; replace
- Remove any Workflows or Stages on any Machines that contain the
- Upgrade the content pack as per normal operations (eg
drpcli catalog item install proxmox --version=v4.11.0, or via the Catalog menu item in the Web UX Portal)
The named Params and Stages that contained "buster" have been moved to more generic name construct of "debian" to support the install of the content on newer versions of Debian distros.
Installation Preparation Information¶
Proxmox installation has been moved to use the Universal Pipelines and workflow chaining process. This significantly simplifies the installation path, along with providing all of the enhanced customizability of the Universal workflows.
The basic customization and configuration methods for Proxmox have not changed from previous implementation.
RackN does NOT suggest using the standalone (non-universal) Proxmox workflows. They are maintained in this content pack for backwards compatibility, and will be DEPRECATED and removed from future versions.
The Proxmox content bundle relies on
drp-community-content to install the
base Debian version on the target systems.
Debian package prerequisites require human input to the packaging system. To automate
this, we utilize the
debconf-set-selections mechanism to preseed the answers to
those packages (eg Samba and Postfix). The preseed debconf selections template
is defined by the
proxmox/debconf-selections-template Param. By default it
defines the template as
proxmox-debconf-selections-template.tmpl. To specify
customizations for the selections, set the Param to point to your own custom
template with appropriate customization selections.
The debconf selections by default answer values for Postfix and Samba. If the Proxmox host needs these set to interact with external infrastructure (Eg send outbound mail), you must adjust these appropriately.
Debian OS Network Configuration¶
Currently, the RackN
netwrangler Network Configuration tooling does not support
network configuration for Debian / Proxmox systems. As a consequence, Tasks and
tooling have been written to support building up the Base OS network configuration
to support the topology requirements for given virtualized use cases.
The primary concern is to integrate the hypervisors network configuration and IP addressing needs with the virtualized network topology and IP addressing requirements for the virtualized infrastructure built on top of Proxmox.
To address that, the Proxmox workflows support custom network topology configuration
of the base hypervisor OS (Debian) with the use of the Flexiflow system to inject tasks
to handle network reconfiguration. This is handled by setting an array of tasks
proxmox/flexiflow-debian-install Param, which drives the
flexiflow-debian-install Stage to inject tasks.
Several prebuilt network topology Tasks exist that may meet the operator needs. These are as follows:
More than one network reconfiguration task can be specified in the array to combine multiple tasks to generate the final desired configuration. Please review each Task to understand what is being changed to support network topology use cases.
Due to how network reconfigurations occur in Debian, it is possible that some tasks may require forcing a reboot, or detailed understanding on how to tear down existing configurations to reach a desired topology. For example, if the base OS is using Bonded interfaces that need to be broken and reconfigured, this requires a lot of work to correctly tear down the bonds and build things back up again, it is safeer/cleaner to reboot the system in some cases.
Custom templates can be written to effect specific network topology changes as required, if the provided tasks/templates are not sufficient for your use case. Please review the Task and associated above named Templates to understand how to customize via the Flexiflow task injection.
Installation via Universal Pipelines¶
The following information outlines installation of Proxmox 7 via the Debian base repositories. Future versions may need to adjust this example (eg "Debian 12" deploys "Proxmox 8").
The process should be fairly straight forward. YOU MUST build the appropriate network topology and configuration necessary for your virtualized environment use case. This should be provided in a Profile attached to your target machine PRIOR TO INSTALLING Proxmox. See the above documentation information for details.
Debian 11 can ONLY be installed with Internet access. Go thank the Debian maintainers for that. Subsequently though, you will not need to install the Debian 11 bootenv ISO.
- Install the BootEnv ISO for the Base OS, if required (see above note)
- Add your Proxmox configuration Profile to the target bare metal Machine
- Set the Pipeline on the Machine to
- Set the Workflow on the Machine to
- Hit the
Virtual Machine IP Address Assignments¶
Ultimately, how the Virtual Machines on the Proxmox system obtain their IP addressing determines the required previous OS Network Configuration steps. Some examples are:
- Completely private IP addressing, isolated from external networks - requires hypervisor/OS SSH tunneling, VPNs, or custom NAT translations to make the VMs reachable from the outside
- Virtual Machine Layer 3 IP networks, routed by external network devices, to the external IP of the Hypervisor
- DHCP or Static IP assignments from the Hypervisors Layer 2 / Layer 3 network, bridging the hypervisor interface directly to the VMs networks
In some cases, the NAT translation network configuration tasks in these workflows can help with the first case (private networks).
If the VMs are addressable on the external network of the Hypervisor, then an external DRP Endpoint can provision the addressable VMs via standard PXE/TFTP boot and installation workflows.
If the VMs are not addressable directly on the external networks, a DRP endpoint may be installed on the Hypervisor OS alongside the Proxmox components to provision the VMs.
For more complete details of these differences, see the following DRP Deployment section.
DRP Deployment of Virtual Machines¶
Digital Rebar Platform (DRP) v4.11 and newer now supports virtual
machine infrastructure management via the
cloud-wrappers content on
top of Proxmox hypervisors.
The process essentialy entails creating a
Resource Broker which
provides the connection and API calls to a given individual Hypervisor
or cluster of Proxmox hypervisors.
Cluster object is then used to manage the request to add or
remove Virtual Machines, via a specific
Please review the Cloud Wrappers documentation for more details on how to achieve this.
The primary installation workflow is provided in the
catalog content bundle. It is called
should not be directly used. See the Installation via Universal Pipelines
instructions above for usage.
Here is a brief summary of the now DEPRECATED workflows provided in the Proxmox content pack.
DEPRECATED - please do not use these workflows. See the Installation via Universal Pipelines section above for correct installation method.
proxmox-debian-install: Install Debian 10 (Buster) linux, install Proxmox, setup admin account, create storage configs, enable KVM nested mode, configure base hypervisor network
proxmox-only-install: no Debian install, only Proxmox install and configure
These workflows have been removed from the Proxmox content as of v4.11.
Profiles with Example Usage¶
Review the Profile provided in the Proxmox content pack for example usage
scenarios. Example profile(s) will start with the prefix
Future To Do Items¶
This is a list of future enhancements that are planned for the Proxmox content.
Current ToDo list:
- [completed in v4.11] separate Proxmox and RackN Lab components in to separate content packs
[deprecated in v4.11] restructure the workflows as individual non-overlapping workflows as follows:
[completed] base OS install and customization (or move debconf selection handline to community content)
- [completed] base OS network topology reconfiguration (preferably netwrangler should support this instead)
- [completed] proxmox package installation
- [completed] proxmox configuration and setup
- [completed] generic VM create capability (this may move to new WorkOrders system)
- [completed] generic VM destroy capability (this may move to new WorkOrders system)
[partially completed in v4.11] RackN usage scenarios
- lab create
- lab destroy
[completed in v4.11] move the newly resturcutred workflows to Universal wrapped workflows
- [completed in v4.11] possibly integrate
cloud-wrappersto drive VM management on top of Proxmox hosts or clusters
- implement Proxmox Cluster management between multiple hypervisors
- enable more Storage configuration capabilities (e.g. shared Ceph storage, zfs, nfs)
- move to Netwrangler network topology management for Hypervisor network config
netwranglersupporting Debian base network configuration methodology)