Установка и настройка proxmox ve

Сетевой Bridge для kvm

Настройка сети для виртуальных машин kvm может быть настроена различными способами. Я как минимум 3 наиболее популярных знаю:

1. Виртуальные машины выходят во внешний мир через сам хост kvm, на котором настроен NAT. Этот вариант вам будет доступен сразу после установки kvm. Ничего дополнительно настраивать не надо, так как сетевой бридж для этого virbr0 уже будет добавлен в систему. А в правилах iptables будет добавлен MASQUERADE для NAT.
2. Одна из виртуальных машин превращается в шлюз и через нее осуществляется доступ во внешний мир для всех виртуальных машин. Наиболее гибкий способ управления сетью для vm, но в то же время требует больше времени на настройку и набор знаний по работе с сетями.
3. Для виртуальных машин kvm создается отдельный сетевой бридж во внешнюю сеть. Они напрямую получают в нее сетевой доступ.

Последний вариант наиболее простой и удобный, поэтому настроим сеть для виртуальных машин таким образом. Для этого нам нужно установить дополнительный пакет на host.

sudo apt install bridge-utils

Теперь на хосте приводим сетевые настройки в /etc/netplan к следующему виду.

network:
  ethernets:
    ens18:
      dhcp4: false
      dhcp6: false
  version: 2

  bridges:
    br0:
      macaddress: 16:76:1a:3b:be:03
      interfaces:
        - ens18
      dhcp4: true
      dhcp6: false
      parameters:
        stp: true
        forward-delay: 4

Здесь будьте очень внимательны. Не выполняйте изменения сетевых настроек, не имея прямого доступа к консоли сервера. Очень высок шанс того, что что-то пойдет не так и вы потеряете удаленный доступ к серверу.

В предложенном наборе правил netplan у меня один сетевой интерфейс на хосте гипервизора — ens18. Он изначально получал настройки по dhcp. Мы добавили новый сетевой бридж br0, в него добавили интерфейс ens18. Так же мы указали, что br0 будет получать сетевые настройки по dhcp. Я указал mac адрес для того, чтобы он не менялся после перезагрузки. Такое может происходить. Адрес можно указать любой, не принципиально. Я сделал похожий на адрес физического сетевого интерфейса.

Теперь надо применить новые настройки.

sudo netplan apply

Сразу после этого вы потеряете доступ к серверу по старому адресу. Интерфейс ens18 перейдет в состав bridge br0 и потеряет свои настройки. А в это время бридж br0 получит новые сетевые настройки по dhcp. IP адрес будет отличаться от того, что был перед этим на интерфейсе ens18. Чтобы снова подключиться удаленно к гипервизору kvm, вам надо будет пойти на dhcp сервер и посмотреть, какой новый ip адрес ему назначен.

Если у вас нет dhcp сервера или вы просто желаете вручную указать сетевые настройки, то сделать это можно следующим образом.

network:
  ethernets:
    ens18:
      dhcp4: false
      dhcp6: false
  version: 2

  bridges:
    br0:
      macaddress: 16:76:1a:3b:be:03
      interfaces:
        - ens18
      addresses:
        - 192.168.25.2/24
      gateway4: 192.168.25.1
      nameservers:
        addresses:
          - 192.168.25.1
          - 77.88.8.1
      dhcp4: false
      dhcp6: false
      parameters:
        stp: true
        forward-delay: 4

В этом случае после применения новых настроек, гипервизор kvm будет доступен по адресу 192.168.25.2.

Обращайте внимание на все отступы в конфигурационном файле netplan. Они важны

В случае ошибок, настройки сети применены не будут. Иногда эта тема очень напрягает, так как не получается сразу понять, где именно в отступах ошибка. В этом плане yaml файл для настроек сети гипервизора как-то не очень удобен.

Далее еще один важный момент. Чтобы наш kvm хост мог осуществлять транзит пакетов через себя, надо это явно разрешить в sysctl. Добавляем в /etc/sysctl.d/99-sysctl.conf новый параметр. Он там уже есть, надо только снять пометку комментария.

net.ipv4.ip_forward=1

Применяем новую настройку ядра.

sudo sysctl -p /etc/sysctl.d/99-sysctl.conf
net.ipv4.ip_forward = 1

С настройкой сети гипервизора мы закончили. На данном этапе я рекомендую перезагрузить сервер и убедиться, что все настройки корректно восстанавливаются после перезагрузки.

Enable Nested Hardware-assisted Virtualization

Note: VMs with nesting active (vmx/svm flag) cannot be live-migrated!

To be done on the physical PVE host (or any other hypervisor).

To have nested hardware-assisted virtualization, you have to:

• use AMD cpu or very recent Intel one
• use kernel >= 3.10 (is always the case after Proxmox VE 4.x)
• enable nested support

to check if is enabled do («kvm_intel» for intel cpu, «kvm_amd» for AMD)

 root@proxmox:~# cat /sys/module/kvm_intel/parameters/nested   
N

N means it’s not enabled, to activate it («kvm-intel» for intel):

 # echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf

(or «kvm-amd» for AMD, note the 1 instead of Y):

 # echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.conf

and reboot or reload the kernel module

modprobe -r kvm_intel
modprobe kvm_intel

check again

 root@proxmox:~# cat /sys/module/kvm_intel/parameters/nested                    
 Y

(pay attention where the dash «-» is used, and where it’s underscore «_» instead)

Then create a guest where you install e.g. Proxmox as nested Virtualization Environment.
Set the CPU type to «host»

 root@guest1# qm set <vmid> --cpu host

Once installed the guest OS, if GNU/Linux you can enter and verify that the hardware virtualization support is enabled by doing

 root@guest1# egrep '(vmx|svm)' --color=always /proc/cpuinfo

VMware Converter

Physical (running) Windows server to Proxmox VE (KVM) using VMware vCenter Converter Standalone Client (V5)

Tested on an HP ProLiant ML350 G5 and G6

Prepare Windows

VMware vCenter Converter Standalone Client

Download here(version 5.x is Free Software and also free of charge but you need to create an account and login before download)

Mergeide.reg

Execute mergeide.reg (File:Mergeide.zip)

VMware vCenter Settings

Launch VMware vCenter and use the following settings:

• Source type: Powered-on machine
• Specify the powered-on machine: This local machine
• Select destination type: VMware Workstation or other VMware virtual machine
• Select VMware Product: VMware Workstation 8.0.x
• Name: Enter the desired name for the image
• Select a location for the virtual machine: Browse to the USB or Network drive where the image will be saved.

The next screen shows the settings for the virtual machine.

Click on Advanced options, select the Post-conversion tab and make sure ‘Install VMware Tools on the destination virtual machine’ is NOT check. We do not want to install VMware tools.

Click next and Finish.

It will now convert your physical machine to a .vmdk file.

NOTE: Depending on your hardware, you may need to boot the .vmdk file using VMware Workstation or Player before moving the file to the Proxmox VE server. This allows windows to install additional drivers for the disk controller. If promoted to convert the disk to Workstation 9.x compatibility, say Yes. You won’t know if you need this step until starting the Windows VM in the final step. If you get a blue screen during boot, you should try this step.

Prepare the VM on Proxmox VE

Create a new KVM virtual machine. You’ll want to use similar CPU and memory as the physical system. In the Hard Disk menu, leave everything as default. We won’t be using the disk created by Proxmox VE. Finish creating the VM. Make note of the VMID. For this guide, we’ll be using 100 as an example.

Once the VMware converter has completed, disable all of the networks adapters on the physical server and shut down. Disabling the network adapters will avoid potential IP conflicts if you will start the physical server back into Windows after you have your new virtual server running.

Move the image to the Proxmox VE Server

Plug a USB Hard Drive into the server

From the Proxmox VE command line:

mkdir /mnt/usb

mount /dev/sdc1 /mnt/usb/

ls /mnt/usb

You should see the contents of the USB drive. In my case, the vmdk file was located in /mnt/usb/windows-server/

Converting to qcow2

We want to convert the .vmdk image file to qcow2. To do this, use the following command:

qemu-img convert -f vmdk /mnt/usb/windows-server/windows-server.vmdk -O qcow2 /var/lib/vz/images/100/windows-server.qcow2

This can take a while depending on the size of file and speed of your system.

Final Steps

Once the conversion is complete, we need to edit the configuration file for the VM.

nano /etc/pve/local/qemu-server/100.conf

In the line with ide0: we want to change vm-100-disk-1.raw,size=32G to windows-server.qcow2

You may delete the empty disk created by Proxmox VE when you created the VM.

rm /var/lib/vz/images/100/vm-100-disk-1.raw

Start the VM and open the console. Windows should boot up normally. It’ll take a few minutes to detect the hardware changes. If the Windows system had a static IP address, you’ll have to reconfigure the settings.

Alternative Methods

OpenVZ Template Creators to create non Debian (we have DAB for it) templates.

Follow these steps to do a V2V migration and move a virtual machine from another hypervisor to a Proxmox VE virtual machine that uses Qemu and KVM.

Example: PVE hosts a PVE guest hypervisor

Set a cluster of self-nested PVE

In the physical host Proxmox you create 2 VM, and in each one install a new instance of PVE, so you can experiment with cluster concepts without the need of having multiple physical servers.

log into (web gui) your host pve (running on real hardware)

 => PVE

create two or more vm guests (kvm) in your host PVE, each with enough ram/disk and install PVE from iso on the each guest vm (same network)

 => PVE => VMPVE1 (guest PVE)
 => PVE => VMPVE2 (guest PVE)
 ...

log into (ssh/console) the first guest vm & create cluster CLUSTERNAME

 => PVE => VMPVE1 (guest PVE) => #pvecm create CLUSTERNAME

log into each other guest vm & join cluster

 => PVE => VMPVE2 (guest PVE) => #pvecm add <IP address of VM1>

log into (web gui) any guest vm (guest pve) and manage the new (guest) cluster

 => PVE => VMPVE1/2 (guest PVE) => #pvecm n

• create vm or ct inside the guest pve (nodes of CLUSTERNAME)
  • if you did’t enable hardware-assisted nested virtualization, you have to turn off KVM hardware virtualization (see VM options)
  • install only CLI based, small ct or vm for those guest (do not try anything with a GUI, don’t even think of running Windows…)

 => PVE => VMPVE1/2 (guest PVE) => VM/CT

install something on a VM (for example a basic ubuntu server) from ISO

 => PVE => VMPVE2 (guest PVE) => VM (basic ubuntu server)

VM/CT performance without hardware-assisted virtualization extensions

if you can’t setup hardware-assisted virtualization extensions for the guest, performance is far from optimal! Use only to practice or test!

• CT (LXC) will be faster, of course, quite usable
• VM (KVM) will be really slow, nearly unusable (you can expect 10x slower or more), since (as said above) they’re running without KVM hardware virtualization

but at least you can try or test «guest pve» features or setups:

Requirements

In nested virtualization, also the guest hypervisor should have access to hardware-assisted virtualization extensions, and that implies that the host hypervisor should expose those extension to its virtual machines. In principle it works without those extensions too but with poor performance and it is not an option for productive environment (but maybe sufficient for some test cases). Exposing those extensions requires in case of intel CPUs kernel 3 or higher, i.e. it is available in Proxmox VE > 4.x, but not as default in older versions.

You will need to allocate plenty of CPU, RAM and disk space for those guest hypervisors.

Изменения в Proxmox 6.0

Подробно об изменениях в Proxmox ve 6.0 можно посмотреть в официальном . На opennet сделан перевод основных нововведений. Я внимательно все прочитал, но особо не заметил кардинальных изменений, которые обычно ждешь от новой ветки. Из основных изменений там вот что:

1. Перешли на кодовую базу Debian 10 Buster.
2. Все компоненты (QEMU, LXC, ZFS, Ceph и т.д.) обновили до более свежих версий.
3. Небольшие изменения в gui и некоторого функционала.

Тем не менее, я решил обновить proxmox, чтобы сильно не отставать по версиям. Обычно, если отстаешь по обновлениям, потом все труднее и ленивее наверстывать. Больше шанс, что будут проблемы, если прыгаешь в обновлениях с большей разницей в версиях. Лучше все делать своевременно.