Frequently Asked Questions ========================== ifndef::manvolnum[] :pve-toplevel: endif::manvolnum[] ifdef::wiki[] :title: FAQ endif::wiki[] NOTE: New FAQs are appended to the bottom of this section. ///////////////////////////////////////////////////////////////// ADD NEW FAQS TO THE BOTTOM OF THIS SECTION TO MAINTAIN NUMBERING ///////////////////////////////////////////////////////////////// [qanda] What distribution is {pve} based on?:: {pve} is based on http://www.debian.org[Debian GNU/Linux] What license does the {pve} project use?:: {pve} code is licensed under the GNU Affero General Public License, version 3. Will {pve} run on a 32bit processor?:: {pve} works only on 64-bit CPUs (AMD or Intel). There is no plan for 32-bit for the platform. + NOTE: VMs and Containers can be both 32-bit and/or 64-bit. Does my CPU support virtualization?:: To check if your CPU is virtualization compatible, check for the `vmx` or `svm` tag in this command output: + ---- egrep '(vmx|svm)' /proc/cpuinfo ---- Supported Intel CPUs:: 64-bit processors with http://en.wikipedia.org/wiki/Virtualization_Technology#Intel_virtualization_.28VT-x.29[Intel Virtualization Technology (Intel VT-x)] support. (http://ark.intel.com/search/advanced/?s=t&VTX=true&InstructionSet=64-bit[List of processors with Intel VT and 64-bit]) Supported AMD CPUs:: 64-bit processors with http://en.wikipedia.org/wiki/Virtualization_Technology#AMD_virtualization_.28AMD-V.29[AMD Virtualization Technology (AMD-V)] support. What is a container, CT, VE, Virtual Private Server, VPS?:: Operating-system-level virtualization is a server-virtualization method where the kernel of an operating system allows for multiple isolated user-space instances, instead of just one. We call such instances containers. As containers use the host's kernel they are limited to Linux guests. What is a QEMU/KVM guest (or VM)?:: A QEMU/KVM guest (or VM) is a guest system running virtualized under {pve} using QEMU and the Linux KVM kernel module. What is QEMU?:: QEMU is a generic and open source machine emulator and virtualizer. QEMU uses the Linux KVM kernel module to achieve near native performance by executing the guest code directly on the host CPU. It is not limited to Linux guests but allows arbitrary operating systems to run. [[faq-support-table]] How long will my {pve} version be supported?:: {pve} versions are supported at least as long as the corresponding Debian Version is https://wiki.debian.org/DebianOldStable[oldstable]. {pve} uses a rolling release model and using the latest stable version is always recommended. + [width="100%",cols="5*d",options="header"] |=========================================================== | {pve} Version | Debian Version | First Release | Debian EOL | Proxmox EOL | {pve} 6.x | Debian 10 (Buster)| 2019-07 | tba | tba | {pve} 5.x | Debian 9 (Stretch)| 2017-07 | 2020-07 | 2020-07 | {pve} 4.x | Debian 8 (Jessie) | 2015-10 | 2018-06 | 2018-06 | {pve} 3.x | Debian 7 (Wheezy) | 2013-05 | 2016-04 | 2017-02 | {pve} 2.x | Debian 6 (Squeeze)| 2012-04 | 2014-05 | 2014-05 | {pve} 1.x | Debian 5 (Lenny) | 2008-10 | 2012-03 | 2013-01 |=========================================================== [[faq-upgrade]] How can I upgrade {pve} to the next release?:: Minor version upgrades, for example upgrading from {pve} in version 5.1 to 5.2, can be done just like any normal update, either through the Web GUI __Node -> Updates__ panel or through the CLI with: + ---- apt update apt full-upgrade ---- + NOTE: Always ensure you correctly setup the xref:sysadmin_package_repositories[package repositories] and only continue with the actual upgrade if `apt update` did not hit any error. + Major version upgrades, for example going from {pve} 4.4 to 5.0, are also supported. They must be carefully planned and tested and should *never* be started without having a current backup ready. Although the specific upgrade steps depend on your respective setup, we provide general instructions and advice of how a upgrade should be performed: + * https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0[Upgrade from {pve} 5.x to 6.0] * https://pve.proxmox.com/wiki/Upgrade_from_4.x_to_5.0[Upgrade from {pve} 4.x to 5.0] * https://pve.proxmox.com/wiki/Upgrade_from_3.x_to_4.0[Upgrade from {pve} 3.x to 4.0] LXC vs LXD vs Proxmox Containers vs Docker:: LXC is a userspace interface for the Linux kernel containment features. Through a powerful API and simple tools, it lets Linux users easily create and manage system containers. LXC, as well as the former OpenVZ, aims at *system virtualization*, i.e. allows you to run a complete OS inside a container, where you log in as ssh, add users, run apache, etc... + LXD is building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through `liblxc` and its Go binding to create and manage the containers. It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network. + Proxmox Containers also aims at *system virtualization*, and thus uses LXC as the basis of its own container offer. The Proxmox Container Toolkit is called `pct`, and is tightly coupled with {pve}. That means that it is aware of the cluster setup, and it can use the same network and storage resources as fully virtualized VMs. You can even use the {pve} firewall, create and restore backups, or manage containers using the HA framework. Everything can be controlled over the network using the {pve} API. + Docker aims at running a *single* application running in a contained environment. Hence you're managing a docker instance from the host with the docker toolkit. It is not recommended to run docker directly on your {pve} host. + NOTE: You can however perfectly install and use docker inside a Proxmox Qemu VM, and thus getting the benefit of software containerization with the very strong isolation that VMs provide.