These are the steps I used to install Home Assistant on Proxmox. I chose to install the full Home Assistant Operating System (HAOS) rather than running Home Assistant in a regular Linux VM or LXC container.

Home Assistant provides an official KVM/Proxmox .qcow2 disk image specifically for this type of installation. The process is slightly different from installing a normal operating system from an ISO because we import this prebuilt disk image into Proxmox instead.

I based part of my process on this community guide rather than using one of the automated helper scripts.

Before Installing Home Assistant on Proxmox

For my Home Assistant VM, I used:

• 2 CPU cores
• 4096 MB (4 GB) RAM
• q35 machine type
• OVMF (UEFI) BIOS
• Home Assistant’s KVM/Proxmox QCOW2 image
• The default Proxmox network interface

Home Assistant’s official documentation currently lists a minimum of 2 vCPUs and 2 GB of RAM for a virtual machine. I decided to give mine 4 GB of RAM instead. You can always increase the resources later if necessary.

You will also need access to the Proxmox web interface and shell (either via web or SSH) for the Proxmox node where you want Home Assistant to run.

Steps to Install Home Assistant on Proxmox

1. Get the Home Assistant KVM/Proxmox Image

First, go to the Home Assistant alternative installation page and find the download for KVM/Proxmox.

Home Assistant provides this image in QCOW2 format, which is exactly what we need for Proxmox.

Instead of downloading the image to my computer and uploading it again to Proxmox, I downloaded it directly from the Proxmox shell.

Right-click the KVM/Proxmox download link on the Home Assistant website and copy the link address.

Then, open the Proxmox web interface, select your Proxmox node and open Shell.

Download the file using wget:

wget <HOME-ASSISTANT-QCOW2-UL>

For example, your command will look similar to:

wget https://github.com/home-assistant/operating-system/releases/download/<version>/haos_ova-<version>.qcow2.xz

Press Enter after typing the command.

Alternatively, you can SSH into the Proxmox node to run these commands.

I recommend copying the current URL directly from Home Assistant instead of copying an old version number from another guide. That way, you will download the current Home Assistant OS image.

2. Decompress the Home Assistant QCOW2 Image

The downloaded QCOW2 image is compressed using XZ, so we need to decompress it before importing it into Proxmox.

Run:

unxz haos_ova-<version>.qcow2.xz

Replace the filename with the actual filename you downloaded.

For example:

unxz haos_ova-18.2.qcow2.xz

The version above is only an example. Use the filename you actually downloaded.

After extraction, you should have a file ending in:

.qcow2

If you aren’t sure which directory you downloaded the file into, run:

pwd

You can also list the files in the current directory with:

ls

If you opened the shell through the Proxmox web interface, you will commonly be working from /root.

The Proxmox forum guide uses the same wget and unxz process to obtain and extract the Home Assistant image.

3. Create a New Home Assistant VM in Proxmox

Next, go back to the Proxmox web interface and click Create VM.

We are going to create the VM without an installation ISO because the Home Assistant QCOW2 file will become the VM’s boot disk.

General

Give the VM a name such as:

HomeAssistant

Take note of the VM ID. We will need this number when importing the Home Assistant disk later. In my case, this was 103.

In Advanced settings I also enabled:

Start at boot

This way, Home Assistant will automatically start when my Proxmox server starts.

OS

Under the OS tab, select:

Do not use any media

We don’t need an ISO because Home Assistant is already installed inside the QCOW2 image.

System

This part is important.

For Machine, select:

q35

For BIOS, select:

OVMF (UEFI)

Select a storage location for the EFI disk. In many installations this will be:

local-lvm

In my case it was actually a storage location called VMs.

I also unchecked:

Pre-Enroll keys

Home Assistant requires UEFI when running as a virtual machine, and the referenced Proxmox configuration uses q35 with OVMF and Secure Boot keys disabled.

Disks

Proxmox normally creates an empty disk when you create a VM.

We don’t need it.

Delete the automatically created SCSI disk from the VM configuration. The Home Assistant QCOW2 image that we downloaded earlier will become our disk instead.

CPU

I assigned:

2 cores

You can give Home Assistant more CPU resources later if your installation grows.

Memory

I assigned:

4096 MB

That gives the VM 4 GB of RAM.

Although Home Assistant currently specifies 2 GB as the minimum for a VM, I preferred giving it 4 GB from the beginning.

Network

I left the network configuration at the Proxmox defaults.

For a typical installation, the VM should be connected to your normal Proxmox bridge so Home Assistant appears as another device on your LAN.

If you’re using VLANs or a more complicated network configuration, adjust this accordingly.

Finish creating the VM.

Do not start it yet.

4. Import the Home Assistant QCOW2 Disk into Proxmox

Now we need to import the Home Assistant disk into the VM we just created.

Go back to the Proxmox node’s Shell.

The general syntax for importing a QCOW2 image is:

qm importdisk <VM-ID> <QCOW2-FILE> <STORAGE>

For example, if:

• Your Home Assistant VM ID is 103
• Your Home Assistant QCOW2 file is in /root
• Your VM storage is local-lvm

You would run something similar to:

qm importdisk 103 /root/haos_ova-<version>.qcow2 local-lvm

Make sure you replace the VM ID, filename and storage with the values from your own Proxmox installation.

Let the import finish before continuing.

5. Attach the Imported Home Assistant Disk

Once the import completes, return to the Proxmox web interface.

Select your Home Assistant VM and open:

Hardware

You should now see something similar to:

Unused Disk 0

This is the Home Assistant disk we just imported.

Select the unused disk and click Edit.

If your Proxmox storage backing this VM is on an SSD, you should enable Discard.

Then, click Add.

The disk should now be attached to the Home Assistant VM, commonly as something similar to:

scsi0

6. Set the Home Assistant Disk as the Boot Disk

Before starting the VM, we need to make sure Proxmox actually boots from the imported Home Assistant disk.

Select the VM and go to:

Options > Boot Order

Click Edit.

Enable the imported Home Assistant disk. In my case, this was the scsi0 disk.

Disable any unnecessary boot devices so the Home Assistant disk is the VM’s primary boot device.

7. Start the Home Assistant VM

We can finally start Home Assistant.

Click Start.

Then, open the VM’s Console.

Home Assistant OS should begin booting!

If everything is configured correctly, Home Assistant will eventually display network information in the console, including the address you can use to access the web interface.

8. Open the Home Assistant Web Interface

Once Home Assistant has booted, open a web browser from another computer on your network.

Home Assistant may be available at:

http://homeassistant.local:8123

Alternatively, you can use the IP address shown in the Home Assistant console:

http://<HOME-ASSISTANT-IP>:8123

For example:

http://192.168.1.100:8123

Home Assistant’s documentation recommends using the IP address directly if hostname discovery doesn’t work on your network.

You should now see the Home Assistant onboarding page.

From here, you can create your Home Assistant account and continue with the normal initial setup.

That’s it! Home Assistant OS is now running as a virtual machine in Proxmox.

Troubleshooting Home Assistant on Proxmox

Home Assistant VM Says There Is No Bootable Disk

First, go to:

VM > Options > Boot Order

Make sure the imported Home Assistant disk is enabled.

It will commonly appear as something such as:

scsi0

The imported QCOW2 disk needs to be selected as a bootable device.

Also confirm that you actually attached the Unused Disk after running qm importdisk.

VM Fails to Boot or Shows a UEFI/Secure Boot Error

Check the VM’s system configuration.

I used:

• Machine: q35
• BIOS: OVMF (UEFI)
• Pre-Enroll Keys: Disabled

Home Assistant requires UEFI for the virtual machine, while the Proxmox forum procedure specifically disables the pre-enrolled Secure Boot keys.

There are also reports in the referenced forum thread of Secure Boot preventing the Home Assistant image from booting until it was disabled.

qm importdisk Says the QCOW2 File Does Not Exist

Check your current directory:

pwd

Then list your files:

ls

You can also specify the complete path to the file:

qm importdisk 103 /root/haos_ova-<version>.qcow2 local-lvm

Also double-check the filename. The extension should be:

.qcow2

Make sure you have already decompressed the .qcow2.xz file with unxz.

homeassistant.local:8123 Does Not Work

Try accessing Home Assistant by IP address instead:

http://<HOME-ASSISTANT-IP>:8123

The Home Assistant documentation specifically recommends using the VM’s IP address when local hostname resolution does not work.

You can find the assigned address from the Home Assistant VM console or from your router/DHCP server.

What About Zigbee, Z-Wave and Other USB Devices?

If you use Home Assistant with a Zigbee, Z-Wave or other USB adapter, the physical USB device will need to be made available to the Home Assistant VM.

Home Assistant’s virtualization documentation specifically accounts for passing USB hardware such as Zigbee and Z-Wave controllers through to a VM.

I would get the basic Home Assistant VM installed and working first before configuring any USB passthrough. This makes it much easier to troubleshoot because you know the base Home Assistant installation is working before adding additional hardware.

If you’re planning to use a Zigbee coordinator with Home Assistant, you’ll also need to decide whether to use ZHA or Zigbee2MQTT. I’ve compared both options separately, along with the best Zigbee channels for Home Assistant if you’re trying to avoid Wi-Fi interference.

Why I Installed Home Assistant Manually

There are community scripts available that can automate much of the process of installing Home Assistant on Proxmox.

However, I wanted to install it manually.

Doing it this way makes the VM configuration much more obvious. You know exactly which machine type, BIOS, CPU, memory, storage and boot disk the Home Assistant VM is using.

It also makes troubleshooting easier later because the installation isn’t hidden behind a script.

The process really isn’t complicated once you understand that the Home Assistant download is a preinstalled QCOW2 disk rather than a conventional installation ISO.

The basic process is simply:

1. Download the Home Assistant QCOW2 image.
2. Decompress it.
3. Create an empty Proxmox VM.
4. Import the QCOW2 image using qm importdisk.
5. Attach the imported disk.
6. Make it bootable.
7. Start the VM.
8. Open Home Assistant on port 8123 at http://homeassistant.local:8123.

Conclusion

Installing Home Assistant on Proxmox is a little different from creating a typical Linux VM because there isn’t an installer ISO involved. Instead, Home Assistant provides a ready-to-use QCOW2 image that we import directly into the virtual machine.

These are the steps I used to install Home Assistant on Proxmox, and once the VM configuration and disk import were complete, Home Assistant OS booted like any other virtual machine.

For my setup, 2 CPU cores, 4 GB of RAM, q35 and OVMF worked well as a straightforward starting configuration.

Running Home Assistant this way also keeps it nicely contained in its own VM while letting Proxmox handle the underlying virtual hardware and startup of the system.

Remarks

• Home Assistant provides an official KVM/Proxmox QCOW2 image, so make sure you download that image to install Home Assistant on Proxmox rather than one intended for VirtualBox or VMware.
• I used 2 CPU cores and 4 GB of RAM. Home Assistant currently lists 2 vCPUs and 2 GB of RAM as the minimum VM requirements.
• Make sure the VM uses OVMF/UEFI. Home Assistant requires UEFI to boot as a virtual machine.
• If the VM refuses to boot, double-check that Pre-Enroll Keys/Secure Boot is disabled and that the imported Home Assistant disk is selected in the boot order.
• If homeassistant.local doesn’t resolve on your network, access Home Assistant directly using its IP address and port 8123, such as http://192.168.1.100:8123.

The post How to Install Home Assistant on Proxmox Step by Step appeared first on TechOpt.

In this guide, I’ll walk you through enabling GPU passthrough in Proxmox (or Jellyfin) LXC step by step.

Step 1: Enabling PCI(e) Passthrough in Proxmox

The first step is enabling PCI passthrough at the Proxmox host level. I mostly followed the official documentation here: Proxmox PCI Passthrough Wiki.

I’ll summarize what should be done below.

Enable IOMMU in BIOS

Before you continue, enable IOMMU (Intel VT-d / AMD-Vi) in your system’s BIOS. This setting lets GPUs pass directly through to containers or VMs.

Each BIOS Is different, so if you’re not sure you should check your motherboard’s instruction manual.

Enable IOMMU Passthrough Mode

Not all hardware supports IOMMU passthrough, but if yours does you’ll see a big performance boost. Even if your system doesn’t, enabling it won’t cause problems, so it’s worth turning on.

Edit the GRUB configuration with:

nano /etc/default/grub

Locate the GRUB_CMDLINE_LINUX_DEFAULT line and add:

iommu=pt

Intel vs AMD Notes

• On Intel CPUs with Proxmox older than v9 (kernel <6.8), also add: intel_iommu=on
• On AMD CPUs, IOMMU is enabled by default.
• On Intel CPUs with kernel 6.8 or newer (Proxmox 8 updated or Proxmox 9+), you don’t need the intel_iommu=on parameter.

With an AMD CPU on Proxmox 9, my file looked like this in the end:

Save the file by typing CTRL+X, typing Y to confirm and then Enter to save.

Then update grub by running:

update-grub

Load VFIO Kernel Modules

Next, we need to load the VFIO modules so the GPU can be bound for passthrough. Edit the modules file with:

nano /etc/modules

Add the following lines:

vfio
vfio_iommu_type1
vfio_pci

My file looked like this in the end:

Save and exit, then update initramfs:

update-initramfs -u -k all

Reboot and Verify

Reboot your Proxmox host and verify the modules are loaded:

lsmod | grep vfio

You should see the vfio modules listed. This is what my output looks like:

If you don’t get any output, the kernel modules have not loaded correctly and you probably forgot to run the update-initramfs command above.

To double-check IOMMU is active, run:

dmesg | grep -e DMAR -e IOMMU -e AMD-Vi

Depending on your hardware, you should see confirmation that IOMMU or Directed I/O is enabled:

Step 2: Finding the GPU Renderer Device Path

Now that PCI passthrough support is enabled, the next step is to figure out the device path of the renderer for the GPU you want to pass through.

Run the following on your Proxmox host:

ls /dev/dri

This will print all the detected GPUs. For example, my output looked like this:

by-path  card0  card1  renderD128  renderD129

If you only have a single GPU, you can usually assume it will be something like renderD128. But if you have multiple GPUs (as I did), you’ll need to identify which renderer belongs to your Intel Arc card.

First, run:

lspci

This will list all PCI devices. From there, I found my Intel Arc GPU at 0b:00.0:

Next, run:

ls -l /dev/dri/by-path/

My output looked like this:

lrwxrwxrwx 1 root root  8 Aug 24 11:54 pci-0000:04:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Aug 24 11:54 pci-0000:04:00.0-render -> ../renderD129
lrwxrwxrwx 1 root root  8 Aug 24 11:54 pci-0000:0b:00.0-card -> ../card1
lrwxrwxrwx 1 root root 13 Aug 24 11:54 pci-0000:0b:00.0-render -> ../renderD128

From this, I confirmed that my Intel Arc GPU was associated with renderD128. That means the full device path I need to pass to my LXC container is:

/dev/dri/renderD128

Step 3: Passthrough GPU Device to the Plex LXC Container

Now that we know the correct device path, we can pass it through to the LXC container.

1. Stop the container you want to pass the GPU into.
2. In the Proxmox web UI, select your Plex LXC container.
3. Go to Resources.
4. At the top, click Add → Device Passthrough.
   
5. In the popup, set Device Path to the GPU renderer path you identified in Step 2 (in my case, /dev/dri/renderD128).
6. In the Access mode in CT field, type:0666
   
7. Click Add.
8. Once added, you can start the container again.

A Note About Permissions

Normally, you would configure a proper UID or GID in CT for the render group inside the container so only that group has access. However, in my testing I wasn’t able to get the GPU working correctly with that method.

Using 0666 permissions allows read/write access for everyone. Since this is a GPU device node and not a directory containing files, I’m not too concerned, but it’s worth noting for anyone who takes their Linux permissions very seriously.

Step 4: Installing GPU Drivers Inside the LXC Container

With the GPU device passed through, the container now needs the proper drivers installed. This step varies depending on the Linux distribution you’re running inside the container.

Some distros may already include GPU drivers by default. But if you reach Step 5 and don’t see your GPU as an option in Plex (or Jellyfin), chances are you’re missing the driver inside your container.

In my case, I’m using a Debian container, which does not include Intel Arc drivers by default. Here’s what I did:

1. Edit your apt sources to enable the non-free repo: nano /etc/apt/sources.list
2. Add non-free to the end of each Debian repository line:
   
3. Refresh apt sources: apt update
4. Install the Intel Arc driver package: apt install intel-media-va-driver-non-free
5. Restart the container.

For Debian, I followed the official documentation here: Debian Hardware Video Acceleration Wiki.

Note: These steps will vary depending on your GPU make, model and container distribution. Make sure to check the official documentation for your hardware and distro.

Step 5: Enabling Hardware Rendering in Plex

Now that your GPU and drivers are ready, the final step is to enable hardware transcoding inside Plex.

1. Open the Plex Web UI.
2. Go to Settings (top-right corner).
3. In the left sidebar, scroll down and click Transcoder under Settings.
4. Make sure the following options are checked:
   • Use hardware acceleration when available
   • Use hardware-accelerated video encoding
5. Under Hardware transcoding device, you should now see your GPU. If not, double-check Step 4. In my case, it showed up as Intel DG2 [Arc A380]
6. Select your GPU and click Save Changes.

Testing Hardware Transcoding

To verify that hardware transcoding is working:

1. Play back any movie or TV show.
2. In the playback settings, change the quality to a lower resolution that forces Plex to transcode:
   
3. While it’s playing, go to Settings → Dashboard.
4. If the GPU is handling transcoding, you’ll see (hw) beside the stream being transcoded:
   

That’s it! You’ve successfully set up GPU passthrough in Proxmox LXC for Plex. These same steps should also work for Jellyfin with minor adjustments for the Jellyfin UI.

The post GPU Passthrough to Proxmox LXC Container for Plex (or Jellyfin) appeared first on TechOpt.

When setting up a new environment, you might wonder whether you should deploy your workload inside an LXC container or a full VM. The choice depends on what you are trying to achieve.

LXC Containers: Lightweight and Efficient

LXC (Linux Containers) provides an efficient way to run isolated environments on a Proxmox system. Unlike traditional VMs, containers share the host system’s kernel while maintaining their own isolated user space. This means they use fewer resources, start up quickly, and offer near-native performance.

When to Use LXC Containers:

• Single Applications – If you need to run a single application in an isolated environment, an LXC container is an excellent choice.
• Docker Workloads – If an application is only available as a Docker image, you can run Docker inside an LXC container, avoiding the overhead of a full VM.
• Resource Efficiency – LXC containers consume fewer resources, making them ideal for lightweight applications that don’t require their own kernel.
• Speed – Since LXC containers don’t require full emulation, they start almost instantly compared to VMs.

Considerations for LXC Containers:

• Less Isolation – Since they share the host kernel, they are not as isolated as a full VM, which can pose security risks if an attacker exploits vulnerabilities in the kernel or improperly configured permissions.
• Compatibility Issues – Some applications that expect a full OS environment may not work well inside an LXC container.
• Limited System Control – You don’t have complete control over kernel settings like you would in a VM.

Virtual Machines: Full System Isolation

Virtual machines in Proxmox use KVM (Kernel-based Virtual Machine) technology to provide a fully virtualized system. Each VM runs its own operating system with its own kernel, making it functionally identical to a physical machine.

When to Use Virtual Machines:

• Multiple Applications Working Together – If you need to run a system with multiple interacting services, a VM provides a fully isolated environment.
• Custom Kernel or OS Requirements – If your application requires a specific kernel version or a non-Linux operating system (e.g., Windows or BSD), a VM is the way to go.
• Strict Security Requirements – Since VMs have strong isolation from the host system, they provide better security for untrusted workloads.
• Compatibility – Any software that runs on a physical machine will run in a VM without modification.

Considerations for Virtual Machines:

• Higher Resource Usage – VMs require more CPU, RAM, and disk space compared to containers.
• Slower Start Times – Because they emulate an entire system, VMs take longer to boot up.
• More Maintenance – You’ll need to manage full OS installations, updates, and security patches for each VM separately.

Final Thoughts: When to Choose LXC Containers vs. Virtual Machines in Proxmox

In general, if you need to run a single application in isolation, or if your application is only available as a Docker image, an LXC container is the better choice. Containers are lightweight, fast, and efficient. However, if you’re running a more complex system with multiple interacting applications, need complete OS independence, or require strong isolation, a VM is the better solution.

Proxmox makes it easy to work with both LXC and VMs, so understanding your workload’s needs will help you choose the right tool for the job. By leveraging the strengths of each, you can optimize performance, security, and resource usage in your environment.

The post LXC Containers (CTs) vs. Virtual Machines (VMs) in Proxmox appeared first on TechOpt.

Working with QCOW2 in Proxmox setups involves a few terminal commands and some configuration in the Proxmox web interface, but it’s straightforward once you’ve done it once.

Steps to Import a QCOW2 Image in Proxmox

1. Access Your Proxmox Terminal

Log in to the terminal of your Proxmox host. This can be done directly or via SSH. The terminal is essential for transferring and managing files during the setup process.

2. Prepare the QCOW2 Storage Directory

Store QCOW2 images in a dedicated directory for better organization. Proxmox doesn’t create this directory by default, so you may need to set it up. A good place to store QCOW2 images is in /var/lib/vz/template/qcow.

• Check if the directory exists:
  
  ls /var/lib/vz/template/qcow
  
  
• If it doesn’t exist, create it:
  
  mkdir -p /var/lib/vz/template/qcow

3. Upload the QCOW2 Image Using SFTP

Uploading the QCOW2 image requires an SFTP connection. Here’s how to do it using the command line:

1. Open a terminal on your local machine.
2. Use the sftp command to connect to your Proxmox host. Replace user with your Proxmox username and host with the IP address of your Proxmox server:
   
   sftp user@host
   
   
3. Navigate to the directory where you want to upload the image:
   
   cd /var/lib/vz/template/qcow
   
   
4. Upload the QCOW2 file from your local system:
   
   put /path/to/your_image.qcow2
   
   Replace /path/to/your_image.qcow2 with the actual path to the QCOW2 file on your local machine.
   
5. Exit the SFTP session with bye.

4. Create a New Virtual Machine

Now, create a VM in Proxmox using the web interface:

1. Log in to the Proxmox web interface.
2. Select Create VM and configure the basic settings, such as the name and operating system. Make sure to select Do not use any media on the OS tab.
3. On the Disks tab, leave all settings at their default values:
   • The default settings work because QCOW2 images already define their initial drive size. If needed, you can expand the drive size later.
   • Select any bus type for now, as you will replace this with the QCOW2 disk.

5. Import the QCOW2 Image

After creating the VM, use the qm importdisk command to import the QCOW2 image to the VM.

1. Identify the VM’s ID from the Proxmox web interface (e.g., 120).
2. Run the following command in the Proxmox terminal:
   
   qm importdisk 120 /var/lib/vz/template/qcow/your_image.qcow2 local

This imports the QCOW2 image as an unused disk linked to the VM.

Make sure to replace the VM ID, image location and storage name with the values for your system.

Here is a sample output from the command:

importing disk '/var/lib/vz/template/qcow/haos_ova-14.1.qcow2' to VM 120 ...
transferred 0.0 B of 32.0 GiB (0.00%)
transferred 396.5 MiB of 32.0 GiB (1.21%)
transferred 737.3 MiB of 32.0 GiB (2.25%)
transferred 1.1 GiB of 32.0 GiB (3.36%)
transferred 1.4 GiB of 32.0 GiB (4.47%)
transferred 1.8 GiB of 32.0 GiB (5.59%)
transferred 2.1 GiB of 32.0 GiB (6.70%)
transferred 2.5 GiB of 32.0 GiB (7.81%)
transferred 2.9 GiB of 32.0 GiB (8.92%)
...
transferred 20.9 GiB of 32.0 GiB (65.44%)
transferred 21.3 GiB of 32.0 GiB (66.56%)
transferred 21.7 GiB of 32.0 GiB (67.67%)
transferred 22.0 GiB of 32.0 GiB (68.78%)
transferred 22.4 GiB of 32.0 GiB (69.89%)
transferred 22.7 GiB of 32.0 GiB (71.01%)
transferred 32.0 GiB of 32.0 GiB (100.00%)
unused0: successfully imported disk 'VMs:vm-120-disk-3'

In this case, this created a new 32.0 GiB drive specified by our image that we can attach to our VM.

6. Attach the Disk to the VM

Once imported, attach the QCOW2 image to the VM:

1. In the Proxmox web interface, go to the VM and select Hardware.
2. Find the unused disk and attach it as a VirtIO Block Device or a SATA device (if your guest OS doesn’t support QEMU agent and VirtIO drivers).
3. Optionally, remove or detach the original disk created during VM setup if it’s no longer needed.

7. Update the Boot Order

Ensure the VM boots from the newly attached QCOW2 image:

1. Go to the Options tab in the VM’s settings.
2. Set the newly attached VirtIO disk as the primary boot device.

8. Start the VM

Boot up the VM. If everything is set up correctly, the system should load from the QCOW2 image!

Remarks

• When creating the VM, default disk settings are sufficient since the QCOW2 image specifies its own initial drive size. You can expand the size later if needed.
• The sftp command is a straightforward way to upload the QCOW2 file. If you prefer a graphical interface, tools like FileZilla can achieve the same result.
• Use the /var/lib/vz/template/qcow directory to keep QCOW2 images organized and accessible for future use. You can use any directory, but this is an easy place to remember since it’s with other templates.
• You can also use any other method to upload your QCOW2 images to this directory, or even download them to this directory directly with a tool such as wget.

The post Importing a QCOW2 Image in Proxmox appeared first on TechOpt.