Często podłączenie GNS3 do sieci fizycznej z użyciem komponentu Cloud może sprawić duże problemy.

Jeżeli w naszym przypadku występuje problem, możemy dodać do GNS3 VM dodatkową kartę sieciową ustawioną w trybie Bridged.

Teraz przy wstawianiu komponentu Cloud do projektu wybieramy jako serwer maszynę GNS3 VM

Podłączając komponent wirtualnym kablem, wybieramy dodaną kartę sieciową, która pracuje w trybie Bridged na GNS3 VM.

W konsoli Proxmoxa musimy zidentyfikować dysk który chcemy dołączyć w trybie Passthrough do VM.

$ find /dev/disk/by-id/ -type l|xargs -I{} ls -l {}|grep -v -E '[0-9]$' |sort -k11|cut -d' ' -f9,10,11,12

/dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_21060M809484 -> ../../sda
/dev/disk/by-id/wwn-0x5001b448be044ab2 -> ../../sda
/dev/disk/by-id/ata-WDC_WD5000AZRX-00A8LB0_WD-WMC1U6335427 -> ../../sdb
/dev/disk/by-id/wwn-0x50014ee602c28429 -> ../../sdb
/dev/disk/by-id/ata-WDC_WD5000AUDX-73H9TY0_WD-WCC4J0287754 -> ../../sdc
/dev/disk/by-id/wwn-0x50014ee25e260065 -> ../../sdc
/dev/disk/by-id/ata-WDC_WD5000AAKX-001CA0_WD-WCAYU9578736 -> ../../sdd
/dev/disk/by-id/wwn-0x50014ee10389e0a4 -> ../../sdd

Teraz wybieramy dyski z listy aby je dodać do konfiguracji naszej maszyny vm, wskazując id maszyny, kontroler oraz id dysku. Dla każdego dysku wybieramy nowy kontroler, który w tej vm nie używamy np: scsi2, scsi3 …..

$ qm set  111  -scsi2 /dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_21060M809484
update VM 592: -scsi2 /dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_21060M809484

$ qm set  111  -scsi3 /dev/disk/by-id/ata-WDC_WD5000AZRX-00A8LB0_WD-WMC1U6335427
update VM 592: -scsi3 /dev/disk/by-id/ata-WDC_WD5000AZRX-00A8LB0_WD-WMC1U6335427

$ qm set  111  -scsi4 /dev/disk/by-id/ata-WDC_WD5000AUDX-73H9TY0_WD-WCC4J0287754
update VM 592: -scsi4 /dev/disk/by-id/ata-WDC_WD5000AUDX-73H9TY0_WD-WCC4J0287754

Na podstawie: https://pve.proxmox.com/wiki/Passthrough_Physical_Disk_to_Virtual_Machine_(VM)

Aby przenieś VM na inny serwer Proxmox musimy zrobić kopie VM.

1. W panelu zarządzania wskazujemy maszynę do przeniesienia i wybieramy Backup, następnie przycisk Backup now. Domyślnie backup wykona się na zasobie dyskowym local.
2. Za pomocą scp lub ftp przenosimy backup z katalogu /var/lib/vz/dump serwera źródłowego na docelowy.
3. Na serwerze docelowym wskazujemy Backup który powinien być na zasobie dyskowym local
4. Wybieramy plik kopi zapasowej który tam przegraliśmy, następnie przycisk Restore.

Aby uruchomić wysokodostępny klaster na Proxmox potrzebujemy przynamniej trzech węzłów (trzech głosów) w klastrze aby można było osiągnąć kworum. Zawsze optymalna jest nieparzysta ilość węzłów w klastrze. Aby to osiągnąć posiadając tylko dwa węzły (nody) zainstalujemy na jakimś innym urządzeniu w sieci np. Raspberry Pi z Linuxem „corosync-qdevice”, który będzie miał trzeci głos w kworum.

Na obydwu nodach instalujemy qdevice

$ apt install corosync-qdevice

Na naszym fejkowym nodzie:

$ apt install corosync-qnetd
$ apt install corosync-qdevice

Teraz jeszcze dodamy to urządzenie jako trzecie do kworum. Idziemy do naszego autentycznego węzła i uruchamiamy polecenie:

$ pvecm qdevice setup x.x.x.x -f 

x.x.x.x to adres ip naszego fejkowego noda. System poprosi nas o akceptację certyfikatu i hasło root do tego urządzenia.

Teraz gdy uruchomimy:

$ pvecm status

zobaczymy 3 głosy (Total votes) i 3 węzły w klastrze.

---

Gdy będziemy chcieli dołączyć następny prawdziwy węzeł do klastra, urządzenie Qdevice będzie nam już nie potrzebne i możemy je szybko usunąć.

$ pvecm qdevice remove