This guide walks you through the entire process of installing an ISO image on your VPS. We\u2019ll use the Arch Linux<\/a> ISO image as an example, but you can install any other image of your choice.<\/p>\n You'll first verify that your VPS supports nested virtualization, install the required packages, create virtual disks, then boot Arch Linux, and finally manage your VMs through the command line.<\/p>\n By the end, you'll have mastered how to run fully functional virtual machines inside your VPS.<\/p>\n To follow this tutorial, you\u2019ll need:<\/p>\n You might be asking: Why go through the trouble of setting up nested virtualization?<\/p>\n It's actually a game-changer for your VPS<\/a>!<\/p>\n You'll enjoy incredible flexibility to run multiple operating systems at once, build perfectly isolated development environments, and test specialized software without compatibility headaches, among many other use cases<\/a>.<\/p>\n Let's first check if your VPS supports nested virtualization by running these commands.<\/p>\n In the above command, any number above 0 means it's supported.<\/p>\n This second command checks if the I once spent hours debugging a VM setup before realizing nested virtualization wasn't enabled on my VPS, so always check this first! Some VPS providers disable this feature by default.<\/p>\n Without nested virtualization, your VMs will either fail to start or run extremely slowly as they'll be using software emulation instead of hardware acceleration.<\/p>\n At SSD Nodes, we offer nested virtualization as an add-on on our Performance VPS<\/a> servers.<\/p>\n Now we'll install all the packages<\/a> needed to run virtual machines:<\/p>\n This installs all the virtualization tools we need. These packages work together to create the complete virtualization stack.<\/p>\n QEMU provides the emulation, KVM is the kernel module that allows direct access to CPU virtualization features, and libvirt gives us a consistent API to manage everything.<\/p>\n To start the virtualization process, we need to first enable and start the libvirt service to manage our VMs.<\/p>\n Check the status:<\/p>\n Output:<\/p>\n From the output, we can see libvirtd is running properly. The service handles all VM operations and needs to be running before we can create or manage any VMs.<\/p>\n First, check if the default virtual network is active:<\/p>\n Output:<\/p>\n This command lists all defined virtual networks. The This default network provides NAT (Network Address Translation) for your VMs, allowing them to access the internet through your VPS without needing their own public IPs.<\/p>\n This creates a virtual bridge named Let's create a directory for boot images and download the latest Arch Linux ISO.<\/p>\n First, we make a directory to store our ISO files:<\/p>\n The Download the Arch Linux installer ISO from one of the available mirrors<\/a>:<\/p>\n This could take a few minutes depending on your VPS's download speed. The ISO contains everything needed to boot and install Arch Linux. I prefer keeping ISOs in this standardized location so I can easily find them later when setting up new VMs.<\/p>\n You could technically store them anywhere, but sticking to the Now we'll create a virtual disk for our VM to install on:<\/p>\n These commands first create the standard directory for VM disk images, then create a 40GB virtual disk in The The This means better disk space usage on your VPS. I've created many of these images, and qcow2 has been more reliable than raw format in my experience, especially when you need to take snapshots later.<\/p>\n Start the VM installation process with This command creates and boots a new VM. Let's break down the parameters:<\/p>\n When I run this on my own servers, I usually tweak the RAM based on what else is running - 4GB is plenty for a basic Arch install though.<\/p>\n The VM will boot, and you'll see the Arch Linux boot menu:<\/p>\n When this boot menu appears, press Tab<\/strong> to edit the kernel parameters, hit SPACE<\/strong>, and add Warning<\/strong><\/p>\n This parameter is crucial<\/em>. Without it, you won't see any output once the kernel boots. The You'll then see the boot process:<\/p>\n And finally the login prompt:<\/p>\n Login with username With this, you are now inside the Arch Linux virtual machine inside<\/em> your VPS!<\/p>\n Let's check if the internet is working using The output should show successful ping:<\/p>\n This shows our VM has internet access through the NAT network we verified earlier. This connectivity is essential for installing packages during Arch setup. The low ping times (around 2ms) in SSD Nodes nested virtualization VPS<\/a> show the virtualization overhead is minimal.<\/p>\n I always test connectivity right away. There is nothing worse than getting halfway through an install before discovering network issues!<\/p>\n Now let's check what disks are available:<\/p>\n Output:<\/p>\n This command lists all disk devices in the VM. We can see our 40GB virtual disk as Let's verify our CPU configuration:<\/p>\n Output:<\/p>\n This confirms our VM has exactly 2 vCPUs as we configured with the The VM sees these as regular CPUs, but they're actually virtual cores allocated from your VPS's physical resources.<\/p>\n If your VM workload needs more processing power, you can always shut down and reconfigure with more vCPUs.<\/p>\n I typically match the number of vCPUs to what the workload needs. More isn't always better since excess vCPUs can cause scheduling overhead.<\/p>\n When running With the VM running, you can now continue with your Arch Linux installation<\/a> process as usual.<\/p>\n After you install your ISO image, you can detach from the VM console without shutting down the VM by pressing You'll then see this message:<\/p>\n This message confirms the VM is still running in the background, and you've just disconnected from its console.<\/p>\n This is super useful when you need to check something on your VPS or if your SSH connection is unstable.<\/p>\n To reconnect to the VM console, use the followin:<\/p>\n Wait briefly then press ENTER<\/strong>. This reconnects you to the VM's console so you can continue the installation.<\/p>\n The VM has been running the whole time, you're just reattaching your terminal to it. Think of it like plugging a monitor back into a running computer.<\/p>\n If you get this error:<\/p>\n It means your previous console session wasn't properly closed. This usually happens if your SSH connection dropped abnormally. To force a connection:<\/p>\n Wait briefly then press\u00a0ENTER<\/strong>.<\/p>\n If that doesn't work, you can restart the libvirt daemon:<\/p>\n Or reset just your VM:<\/p>\n This set of commands forces a proper reset of your VM and its console connection. The Be careful though, as it's like pulling the plug on a physical computer.<\/p>\n I've had to use this approach a few times when my internet connection dropped during a long installation. It's a lifesaver, but you might lose unsaved work in the VM.<\/p>\n You have several options for managing your VM from the VPS.<\/p>\n To shut down the VM from inside:<\/p>\n This properly shuts down the VM from inside the guest OS. It's like pressing the power button and selecting shutdown. All services stop cleanly. This is the preferred method as it gives the guest operating system a chance to save data and shut down services properly.<\/p>\n To list all the currently running virtual machines:<\/p>\n This command shows all running VMs managed by libvirt. you can use this to check if your VM is still running. It's a quick way to get a status report of all active VMs on your system. You can add the To gracefully shut down a VM:<\/p>\n This sends a signal to the VM's operating system to shut down properly. It's polite and prevents data loss. This is equivalent to pressing the power button on a physical machine that's configured to trigger a clean shutdown.<\/p>\n To force power off a VM:<\/p>\n This immediately cuts power to the VM - like unplugging a physical computer. Use this only when the VM is frozen or won't respond to a normal shutdown. Again, while the name To start a VM:<\/p>\n This powers on a stopped VM. If the VM was shut down previously, it will boot normally. It's the equivalent of pressing the power button on a physical machine that's turned off.<\/p>\n To connect to the VM's console:<\/p>\n This connects you to the VM's serial console, giving you a terminal interface to the VM. It's essential for headless setups without graphics. Remember to use These commands give you complete control over your VM's lifecycle. I recommend using shutdown commands whenever possible rather than destroy, as sudden power loss can sometimes corrupt filesystems.<\/p>\n You've now successfully set up nested virtualization on your VPS and installed Arch Linux in a VM! This powerful setup opens up a world of possibilities - from creating isolated development environments to testing deployments across different OS configurations without needing multiple physical servers.<\/p>\n The skills you've learned here apply to virtually any Linux distribution, not just Arch. You can use the same techniques to run Ubuntu, Debian, CentOS, or even Windows VMs inside your VPS.<\/p>\nPrerequisites<\/h2>\n
\n
Benefits of Installing Your Own ISO Image on a VPS<\/h2>\n
![\"Installing](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2025\/05\/Install-Your-Own-ISO-Image-on-a-VPS-Article-.jpg\")
<\/p>\nStep 1: Check if Nested Virtualization is Enabled<\/h2>\n
$ grep -cw vmx \/proc\/cpuinfo<\/code><\/pre>\n$ cat \/sys\/module\/kvm_intel\/parameters\/nested<\/code><\/pre>\nnested<\/code> parameter is enabled in the KVM module. An output of Y<\/code>\u00a0 or 1<\/code> confirms that it's on.<\/p>\nStep 2: Install the Required Packages<\/h2>\n
sudo apt update\r\nsudo apt install -y \\\r\n qemu-kvm \\\r\n libvirt-daemon-system \\\r\n libvirt-clients \\\r\n bridge-utils \\\r\n virtinst \\\r\n virt-manager<\/code><\/pre>\n![\"install](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2025\/05\/install-nested-virtualization-requirements.webp\")
<\/p>\nqemu-kvm<\/code> is the hypervisor itself, libvirt<\/code> provides the API and daemon to manage VMs, bridge-utils<\/code> helps with networking, virtinst<\/code> gives us command-line tools like virt-install<\/code>, and virt-manager<\/code> is a GUI tool (though we won't need it for our console-based setup).<\/p>\nStep 3: Start the Virtualization Service<\/h2>\n
sudo systemctl enable --now libvirtd<\/code><\/pre>\nsudo systemctl status libvirtd<\/code><\/pre>\n\u25cf libvirtd.service - libvirt legacy monolithic daemon\r\n **Loaded: loaded** (\/usr\/lib\/systemd\/syst\r\nem\/libvirtd.service; enabled; preset: enabled)\r\n **Active: active (running)** since Wed 2025-05-14 12:09:45 UTC; 20s ago\r\nTriggeredBy: \u25cf libvirtd-ro.socket\r\n \u25cf libvirtd-admin.socket\r\n \u25cf libvirtd.socket\r\n Docs: man:libvirtd(8)\r\n https:\/\/libvirt.org\/\r\n Main PID: 9397 (libvirtd)\r\n Tasks: 22 (limit: 32768)\r\n Memory: 11.2M (peak: 12.6M)\r\n CPU: 788ms<\/code><\/pre>\nStep 4: Verify the Default Network<\/h2>\n
sudo virsh net-list --all<\/code><\/pre>\n Name State Autostart Persistent\r\n--------------------------------------------\r\n default active yes yes\r\n<\/code><\/pre>\nvirsh<\/code> command is your main interface to libvirt from the command line. You'll use it for most VM management tasks. The output shows the \"default\" network is active<\/code>, set to start automatically, and is persistent (saved between reboots).<\/p>\nvirbr0<\/code> that your VMs will connect to. Without this network, your VMs would be isolated. Every time I set up a new server, I check this because it saves a ton of networking headaches later.<\/p>\nStep 5: Download the Arch Linux ISO<\/h2>\n
sudo mkdir -p \/var\/lib\/libvirt\/boot<\/code><\/pre>\nmkdir -p<\/code> command creates all necessary parent directories and doesn't error if the directory already exists. The libvirt convention is to use \/var\/lib\/libvirt\/boot<\/code> for this. Move to this directory:<\/p>\ncd \/var\/lib\/libvirt\/boot<\/code><\/pre>\nsudo wget https:\/\/mirror.rackspace.com\/archlinux\/iso\/2025.05.01\/archlinux-2025.05.01-x86_64.iso<\/code><\/pre>\n\/var\/lib\/libvirt<\/code> hierarchy makes everything more organized.<\/p>\nStep 6: Create a Virtual Disk<\/h2>\n
sudo mkdir -p \/var\/lib\/libvirt\/images\r\nsudo qemu-img create -f qcow2 \/var\/lib\/libvirt\/images\/arch-vm.qcow2 40G<\/code><\/pre>\nqcow2<\/code> format. The qemu-img<\/code> tool is specifically designed for creating and managing disk images for QEMU\/KVM VMs.<\/p>\n-f qcow2<\/code> specifies the format.<\/p>\nqcow2<\/code> format is great because it uses thin provisioning. The file only grows as you use space in the VM, not immediately to 40GB.<\/p>\nStep 7: Launch the Arch Linux Installer<\/h2>\n
virt-install<\/code>:<\/p>\nsudo virt-install \\\r\n --name arch-vm \\\r\n --ram 4096 \\\r\n --vcpus 2 \\\r\n --os-variant archlinux \\\r\n --disk path=\/var\/lib\/libvirt\/images\/arch-vm.qcow2,size=40 \\\r\n --network network=default \\\r\n --graphics none \\\r\n --console pty,target_type=serial \\\r\n --cdrom \/var\/lib\/libvirt\/boot\/archlinux-2025.05.01-x86_64.iso\r\n<\/code><\/pre>\n\n
-name arch-vm<\/code> gives our VM a name we can reference later<\/li>\n-ram 4096<\/code> allocates 4GB of memory<\/li>\n-vcpus 2<\/code> assigns 2 virtual CPUs<\/li>\n-os-variant archlinux<\/code> helps libvirt optimize for Arch Linux<\/li>\n-disk path=...<\/code> connects our virtual disk<\/li>\n-network network=default<\/code> attaches to the default NAT network<\/li>\n-graphics none<\/code> disables graphical console<\/li>\n-console pty,target_type=serial<\/code> enables text-based console<\/li>\n-cdrom<\/code> mounts our ISO file so we can boot from it<\/li>\n<\/ul>\n![\"\"](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2025\/05\/Booting-an-ISO-in-a-VPS-with-Nested-Virtualization.webp\")
<\/p>\nconsole=ttyS0<\/code>, then press ENTER<\/strong>. This redirects the console output to the serial port so we can see it in our terminal.<\/p>\n![\"Nested](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2025\/05\/Nested-Virtualization-Console.webp\")
<\/p>\nconsole=ttyS0<\/code> tells Linux to send console output to the first serial port, which is mapped to your terminal session by KVM.<\/p><\/blockquote>\nLoading \/arch\/boot\/x86_64\/vmlinuz-linux... ok\r\nLoading \/arch\/boot\/x86_64\/initramfs-linux.img...ok<\/code><\/pre>\nArch Linux 6.14.4-arch1-2 (ttyS0)\r\n\r\narchiso login:\r\n<\/code><\/pre>\nroot<\/code> (no password needed).<\/p>\n![\"Arch](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2025\/05\/arch-on-a-vps.webp\")
<\/p>\nping<\/code>:<\/p>\nroot@archiso ~ # ping ssdnodes.com<\/code><\/pre>\nPING ssdnodes.com (172.66.43.60) 56(84) bytes of data.\r\n64 bytes from 172.66.43.60: icmp_seq=1 ttl=57 time=1.79 ms\r\n64 bytes from 172.66.43.60: icmp_seq=2 ttl=57 time=1.82 ms\r\n64 bytes from 172.66.43.60: icmp_seq=3 ttl=57 time=1.80 ms\r\n64 bytes from 172.66.43.60: icmp_seq=4 ttl=57 time=2.20 ms\r\n64 bytes from 172.66.43.60: icmp_seq=5 ttl=57 time=2.03 ms\r\n64 bytes from 172.66.43.60: icmp_seq=6 ttl=57 time=2.14 ms\r\n\r\n--- ssdnodes.com ping statistics ---\r\n6 packets transmitted, 6 received, 0% packet loss, time 5009ms\r\n<\/code><\/pre>\nroot@archiso ~ # fdisk -l<\/code><\/pre>\nDisk \/dev\/vda: 40 GiB, 42949672960 bytes, 83886080 sectors\r\nUnits: sectors of 1 * 512 = 512 bytes\r\nSector size (logical\/physical): 512 bytes \/ 512 bytes\r\nI\/O size (minimum\/optimal): 512 bytes \/ 512 bytes\r\n\r\nDisk \/dev\/loop0: 846.72 MiB, 887848960 bytes, 1734080 sectors\r\nUnits: sectors of 1 * 512 = 512 bytes\r\nSector size (logical\/physical): 512 bytes \/ 512 bytes\r\nI\/O size (minimum\/optimal): 512 bytes \/ 512 bytes\r\n<\/code><\/pre>\n\/dev\/vda<\/code> - this is where we'll install Arch. The loop0<\/code> device is part of the live ISO environment. Notice how the virtual disk appears just like a regular disk would. That's the beauty of virtualization.<\/p>\nlscpu | grep -E '^CPU\\(s\\)'\r\n<\/code><\/pre>\nCPU(s): 2<\/code><\/pre>\n--vcpus 2<\/code> parameter.<\/p>\n![\"Nested](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2025\/05\/Nested-Arch-Linux-VM-on-a-VPS-.webp\")
<\/p>\nWarning<\/h3>\n
virt-install<\/code>, do not detach from the console or close the terminal until the installation is complete. Detaching before completing could leave you with an unbootable disk image.<\/p><\/blockquote>\nStep 8: Disconnecting and Connecting to the VM Console<\/h2>\n
Ctrl+]<\/code>.<\/p>\nDomain is still running. Installation may be in progress.\r\nYou can reconnect to the console to complete the installation process.<\/code><\/pre>\nsudo virsh console arch-vm<\/code><\/pre>\nerror: operation failed: Active console session exists for this domain<\/code><\/pre>\nsudo virsh console --force arch-vm<\/code><\/pre>\nsudo systemctl restart libvirtd\r\nsudo virsh console arch-vm<\/code><\/pre>\nsudo virsh destroy arch-vm\r\nsudo virsh start arch-vm\r\nsudo virsh console arch-vm<\/code><\/pre>\ndestroy<\/code> command is misleadingly named - it just forces a power off, not an actual deletion.<\/p>\nStep 9: Managing Your VM<\/h2>\n
shutdown -h now<\/code><\/pre>\nsudo virsh list<\/code><\/pre>\n--all<\/code> flag to see inactive VMs too.<\/p>\nsudo virsh shutdown arch-vm<\/code><\/pre>\nsudo virsh destroy arch-vm<\/code><\/pre>\ndestroy<\/code> sounds scary, it only destroys the running instance, not the VM definition or storage.<\/p>\nsudo virsh start arch-vm<\/code><\/pre>\nsudo virsh console arch-vm<\/code><\/pre>\nCtrl+]<\/code> to disconnect when you're done.<\/p>\nImportant Tips for VM Management<\/h2>\n
\n
Ctrl+]<\/code> first to detach.<\/li>\nCtrl+]<\/code> to detach. The VM installation will continue running in the background.<\/li>\nsudo virsh console --force arch-vm<\/code> to reattach.<\/li>\nvirsh snapshot-create-as<\/code> to create a point-in-time backup you can roll back to.<\/li>\nvirt-top<\/code> (you may need to install it separately with apt install virt-top<\/code>).<\/li>\nvirsh autostart arch-vm<\/code>.<\/li>\n<\/ol>\nConclusion<\/h2>\n