Lehekülje Proxmox VE 3.x lähteteksti vaatamine

{{Täienda}}

===Sissejuhatus===

Proxmox on firma mis arendab Debianil ja vabavaral baseeruvaid serverilahendusi. Proxmox VE on Debianile loodud KVM ja OpenVZ tehnikale baseeruvate virtuaalserverite haldusplatform ehk alusdistro. Proxmox kuulub GPL litsentsi alla.

Proxmox VEs sisalduvad võimalused:

* Virtuaalmasinate võrgu boodi tugi gPXE abil http://www.etherboot.org/wiki/pxechaining
* Lihtne kuid võimas veebiliides kus saab kõik põhilised seadistamised tehtud
* Klusterdamise tugi
* Virtuaalserverite mugav install ja kasutamine üle java konsooli

Võrreldes varasema 1.x versiooniga on kasutajaliides põhjalikult ümber kirjutatud-disainitud. Juurde on tulnud järgmised võimalused:

*Kõik clustri noded on VÕRDSED. Pole enam master-slave tüüpi clustrit.
*Backup-restore haldusliidesest lihtsam
*haila-vaila (HA), ehk kui üks masin jukerdab starditakse virtuaalmasinat automaatselt teisel.
*kasutajate haldus, võimalik luua erinevate ligipääsuõigustega kasutajaid
*rrdtooliga genereeritud koormusgraafikud iga virtuaalmasina kohta
*Proxmoxi API virtuaalmasinate/kasutajate loomiseks-haldamiseks eemalt

Veel on lisatud tulemüür mis võimaldab üle veebi hallata kirjeid ja teha seda kas üksikute masinate või gruppide kaupa. Väidetavalt sisaldab ta ka IDS/IPS lahendust Suricata, kuid selle uurimiseni pole me veel jõudnud. http://suricata-ids.org/features/ 

'''Makstud ja mittemakstud uuenduste erinevustest'''

Ametlik seisukoht on:
The pve-no-subscription repo can be used for testing and non-production
use. Its not recommended to run on production servers as these packages
are not always heavily tested and validated.
https://pve.proxmox.com/wiki/Package_repositories

See ei tähenda, et tegemist oleks mingite arendusjärgus asjadega

http://forum.proxmox.com/threads/15742-Details-about-the-new-pve-no-subscripton-repository

We move packages from pve-no-subscription to pve-enterprise after some
time if everything works as expected.
So basically the new pve-enterprise repository is expected to have less
bugs than the pve-no-subscription repository.

Seega tulevad pakid kõigepealt no-subscription reposse ja enterprise reposse jõuavad kunagi hiljem.

===Install===

Installimiseks on kaks võimalust. Esimene (ja soovituslik) on tõmmata ametlik ISO fail ning paigaldada Proxmox selleabil. Juhend ja ISO tõmbamise lingid asuvad aadressil http://pve.proxmox.com/wiki/Installation

Kui mingil põhjusel ametlikult plaadilt installimine ebaõnnestub. Näiteks ei tundnud minul seal leiduv Debian ära võrgukaarte ühe teatud kerneli bugi tõttu. Saab paigaldada käsitsi kõige uuema Debiani 64bitise versiooni, sest 32 bitil kahjuks rakendus ei tööta, ning sinna omakorda Proxmoxi paketi. Selleks esimese sammuna tuleks paigaldada tavaline Debian distro ja järgida edasi juhendit http://pve.proxmox.com/wiki/Installation

/etc/hosts failis tuleb defineerida masina väline IP-aadress.

Avame /etc/apt/sources.list ja lisame sinna rea

 # PVE packages provided by proxmox.com
 deb http://download.proxmox.com/debian wheezy pve

Lisame Proxmox VE repository key:

 # wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -

Uuendame süsteemi

 # aptitude update

Lisame hosts faili kirje serveri kohta. Lisaks tuleb eemaldada kirjed localhost'ile.

 192.168.0.1    masinanimi.domeen.ee    alias

Ja paigaldame proxmoxi

 # aptitude install pve-firmware proxmox-ve-2.6.32 ntp ssh lvm2

Mis installib nii kerneli kui vajalikud utiliidid.

Üleliigne kernel maha, et ei hakkaks segama.

 # apt-get remove linux-image-amd64 linux-image-3.2.0-4-amd64

Saadaolevaid versioone saab näha http://download.proxmox.com/debian/ saidilt.

Kui Proxmox teatab "KVM module not loaded. Maybe you need to enable Intel VT / AMD-V support in the BIOS." Siis on tõenäoliselt virtualiseerimise tugi BIOSist keelatud või üldse arvutist puuduv.

Lisainfot paigaldatud versioonide kohta saab käsuga:

 # pveversion 
 pve-manager/2.2/3089a616

Või veelgi täpsema versiooniinfo saamiseks

 # '''pveversion -v'''
 pve-manager: 2.2-32 (pve-manager/2.2/3089a616)
 running kernel: 2.6.32-17-pve
 proxmox-ve-2.6.32: 2.2-83
 pve-kernel-2.6.32-16-pve: 2.6.32-82
 pve-kernel-2.6.32-17-pve: 2.6.32-83
 lvm2: 2.02.95-1pve2
 clvm: 2.02.95-1pve2
 corosync-pve: 1.4.4-1
 openais-pve: 1.1.4-2
 libqb: 0.10.1-2
 redhat-cluster-pve: 3.1.93-2
 resource-agents-pve: 3.9.2-3
 fence-agents-pve: 3.1.9-1
 pve-cluster: 1.0-34
 qemu-server: 2.0-72
 pve-firmware: 1.0-21
 libpve-common-perl: 1.0-41
 libpve-access-control: 1.0-25
 libpve-storage-perl: 2.0-36
 vncterm: 1.0-3
 vzctl: 4.0-1pve2
 vzprocps: not correctly installed
 vzquota: 3.1-1
 pve-qemu-kvm: 1.3-10
 ksm-control-daemon: not correctly installed

Paigaldada võib veel:

 # aptitude install postfix ksm-control-daemon vzprocps

Vajadusel sertifikaadi paigaldamine
 cp server.key /etc/pve/pve-www.pem
 cp server.key /etc/pve/local/pve-ssl.key
 cp server.pem /etc/pve/local/pve-ssl.pem
 cp ca.crt     /etc/pve/pve-root-ca.pem

Paigaldatud kerneli versioon toetab lisaks ka KSM nimelist tehnoloogiat mälukasutuse vähendamiseks virtuaalmasinatel http://pve.proxmox.com/wiki/Dynamic_Memory_Management

Nimetatud funktsioonist leiab veel juttu kerneli uuenduste loetelu juures http://kernelnewbies.org/Linux_2_6_32#head-d3f32e41df508090810388a57efce73f52660ccb

Miks soovitatakse kasutada 32-bitiseid virtuaalmasinaid mitte 64 bitiseid ? 
64 bitine masin sobib vaid sellisel juhtudel kui vajad rohkem mälu kui 4GB.
Samas 32bitine virtuaalmasin kasutab teatud situatsioonides vähem mälu.
Näiteks standartselt paigaldatud apache2 kasutab 64 bitises opsüsteemis rohkem
mälu kui ta teeks seda 32bitises.

PS: Peale proxmoxi paigaldust võib testida enda süsteemi kiirust kaasapandud utiliidi abil pveperf

 # pveperf
 CPU BOGOMIPS:      127992.00
 REGEX/SECOND:      1026892
 HD SIZE:           9.17 GB (/dev/sda5)
 BUFFERED READS:    106.64 MB/sec
 AVERAGE SEEK TIME: 6.47 ms
 FSYNCS/SECOND:     2806.00
 DNS EXT:           64.95 ms
 DNS INT:           0.96 ms (eenet.ee)

NB! Süsteemi uuendamisel on soovitatav kasutada alati '''apt-get upgrade''' asemel käsku '''apt-get dist-upgrade''', sest muidu uuendatakse ainult paketid aga mitte nende sõltuvusi 
ja mõni teek (library) võib jääda vanema versiooni peale ning hakata tekitama hiljem probleeme.

Tundub, et hetkel on vaja proxmoxi uuendamiseks lisada sources faili järgnev allikas:

 deb http://download.proxmox.com/debian wheezy pve-no-subscription

Tähelepanekuid debiani uuendamisest: apt-get upgrade tundub, et ei taha väga julgelt pakette uuendada. Näiteks proxmox 3.0 pealt
selle käsu abil ei saa 3.1 versioonile minna. Vaja selleks sisestada käsud

 # aptitude update
 # aptitude full-upgrade

===Veebiliides===

Pöördudes http://192.168.0.1 aadressile peaks avanema veebiaken kus saab virtuaalseid masinaid luua ja hallata. Veebiliidese administraatori kasutajaks on "root" ja parooliks sama mis süsteemsel root kasutajal.

Kui virtuaalmasinas (KVM) kasutatav operatsioonisüsteem seda toetab siis tasub kasutada võimalikult palju virtio seamdmeid (võrk, ketas), nendepoolt tekitatud väiksema overheadi tõttu sest siis pole vaja virtuaalserveril emuleerida mingit konkreetset rauda.

===Guesti seadistusfaili kasutamine===

Seadistusfailid asuvad kaustas /etc/qemu-server/

Näiteks virtuaalmasina 101 konf asub failis /etc/qemu-server/101.conf ja näeb välja järgnev:

 name: testikas
 bootdisk: ide0
 vlan1: rtl8139=42:D5:BD:2C:EC:79
 ostype: other
 memory: 2024
 sockets: 1
 ide0: disk1:0.0.0.scsi-14945540000000000ebaf87d4e8aadc8f7c7cbd9b9b75a514

Vahel kui ei õnnestu virtuaalmasinat kustutada tuleb talt enne eemaldada
kettad. näiteks esineb see probleem iscsi külgehaagitud seadmetega.

===iSCSI kasutamine===

iSCSI kasutamiseks tuleb installida pakett open-iscsi

 # apt-get install open-iscsi

Ja seejärel tuleb mõned teenused käivitada-taaskäivitada

 # /etc/init.d/open-iscsi start
 # /etc/init.d/pvedaemon restart

Iscsi targeteid saab edaspidi külge haakida juba otse veebiliidesest.

Kui iSCSI server mingil põhjusel enam ei suhtle siis veebiliidese
kaudu iscsi kettaid lahti haakida pole võimalik. Sellisel juhul tuleb logida
käsureale ja kustutada need manuaalselt failist /etc/pve/storage.cfg

Masina initatori nime näeb failist /etc/iscsi/initiatorname.iscsi

'''NB! LVMi ja iSCSi puhul ei tööta PVE linked clone funktsionaalsus!'''

===Võrgu seadistus===

Probleem, meil on serveril üks võrgukaart ning tahame omistada
sellele avaliku IP aadressi (192.168.0.1), lisaks aga ka teha üle selle virtuaalsete serveriteni bridge (silla) millekaudu pääsevad võrku ka kõik serveris resideeruvad virtuaalmasinad.

Võrgu ehitust iseloomustab järgmine skeem

[[Pilt:Vmb.jpg]]

(pildil viga, peaks olema KVM)

Sellejaoks avame faili /etc/network/interfaces

 auto vmbr0
 iface vmbr0 inet static
         address  192.168.0.1
         netmask  255.255.255.0
         gateway  192.168.0.254
         bridge_ports eth0 
         bridge_stp off
         bridge_fd 0

Ja ongi valmis. Server on ligipääsetav ip aadressilt 192.168.0.1
ning KVM virtuaalmasinate network kaardid võib siduda vmbr0 sillaga. Virtuaalmasinate sees võib tekkinud võrguseadmele omistada koheselt sama võrgu ip aadresse või DHCP teenuse olemasolu korral küsida IP aadresse.

Soovides teha vmbr1 täiendavalt ilma igasuguse IP aadressita tuleb kirjutada see järgnevalt (kasutades võtit manual):

 auto vmbr1
 iface vmbr1 inet manual
         bridge_ports eth1
         bridge_stp off 
         bridge_fd 0

Käsureal näeb jaotust

 # brctl show
 bridge name	bridge id		STP enabled	interfaces
 vmbr0		8000.001b21da2b7c	no		eth0
 							tap118i0
 							tap121i0
 							tap126i0
 							tap146i0
 vmbr1		8000.001e679227c1	no		eth1
 							tap121i1
 							tap146i1
 							tap154i1
 							tap162i1
 

Tähele tasub panna, et vmbr0 tuleb külge linuxitele esimese võrguseadme, ehk eth0ina, vmbr1 järgnevalt eth1na jne..

Peale võrguseadistuse muutmist tuleb teha kas restart või käivitada käsk:

 /etc/init.d/network restart

Tulemüüri ehitamisel tuleb silmas pidada, et vaja on proxmoxi kasutamiseks hoida lahti järgnevad pordid.

#Veebiliidese kasutamiseks: 8006
#VNC veebikonsoolile: 5900-5999
#SSH ligipääsuks: 22

Uue bridge saab tekitada lennult käsuga:

 # brctl addbr vmbr300

Kui on vaja vmbr seamdeid ümber nimetada saab seda teha ka lennult, nt käsuga

 # ip link set vmbr0 down; ip link set dev vmbr0 name vmbr10;  ip link set vmbr10 up

Saab nimetada vmbr0 ümber vmbr10 nimeliseks.

Võimalik on lisaks jooksvalt lisada ja kustutada füüsilisi võrguseadmeid virtuaalsete sildade (bridge) peal. Näiteks
lisame vmbr10 bridgele uue vlan seadme (eth0.100) ja kustutame vana (eth0.1).

 # brctl addif vmbr10 eth0.100
 # brctl delif vmbr10 eth0.1

Kui jätta mõlemad vlanid korraga külge hakkab bridge nende vahelist liiklust vahendama - switchima, vahel on
see vlanide liigutamisel isegi vajalik. Siiski tuleks jälgida, et ühe võrgu piires poleks selliseid vlanide
vahelisi sildu mitu, sest nii võib tekitada virtuaalse ringi (loop), mis ajab füüsilised võrguseadmed hulluks.

====Vlanid ja storage ning erinevad pakettide MTU suurused====

Meil on proxmoxis üks võrgukaart eth1

Vaja oleks sinna seadistada 2 vlani. Ja veel selliselt, et üks oleks mtuga 1500 ja teine mtuga 9000 (et oleks ühenduv iSCSI storage külge). Vlanid on nimedega (id-dega) 1 ja 30. Debianis tuleb selleks avada /etc/network/interfaces ja kirjutada sinna

<source lang=bash>
auto eth1

iface eth1 inet manual
   up ip link set dev eth1 mtu 9000

auto eth1.1
iface eth1.1 inet manual
   up ip link set dev eth1.1 mtu 1500

auto eth1.30
iface eth1.30 inet manual

auto vmbr0
iface vmbr0 inet static
	address  192.168.1.20
	netmask  255.255.0.0
	bridge_ports eth1.1
	bridge_stp off
	bridge_fd 0

# storage 1
auto vmbr1
iface vmbr1 inet static
       address 192.168.2.20
       netmask 255.255.0.0
       bridge_ports eth1.30
       bridge_stp off
       bridge_fd 0
</source>

====OpenVSwitch sild tavalise linuxi brige asemel====

Kasutatav  3.2 versioonist alates.

Head omadused oleksid: pordi peegeldamine, võrkude ja VMide eraldamine, netflow eksportimine, tunnelid, QoS ja väidetavalt
ka tavalise linuxi bridgega võrreldes suurem jõudlus.

Openvswitchi pakett tuleb paigaldada käsitsi.

 apt-get install openvswitch-switch

Olemasolu saab kontrollida

 #  lsmod | grep openvswitch
 openvswitch            38226  0

Käsitsi vmbr0 nimelise silla loomiseks ja eth5 võrguseadmega sidumiseks

 ovs-vsctl add-br vmbr0
 ovs-vsctl add-port vmbr0 eth5

Konfi vaatamine:

 # ovs-vsctl show
 ae282fb2-6fe7-4084-ba79-8762d9f75047
     ovs_version: "2.0.90"

Konfinäide debianile (/etc/network/interfaces)

 allow-ovs vmbr0
   iface vmbr0 inet dhcp
       ovs_type OVSBridge
       ovs_ports eth0

* http://openvswitch.org/support/config-cookbooks/

===Cluster===

Meil on kaks masinat 10.40.0.6 ja 10.40.0.7 ning tahame nad panna koos tööle.
PS: Manual soovitab veidra käitumise vältimiseks kasutada vähemalt 3me nodet, kuid on võimalik panna tööle ka 2 masinat clustris. Lähemalt http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster

NB! Proxmox Ve 3.x kasutab clustrisiseseks komunikatsiooniks corosync cluster engine nimelist tarkvara
ja sqlite tarkvara andmebaasi pidamiseks. Nodede vahel jagatud failisüsteem ühendatakse üle fuse /etc/pve harusse.

Hosts fail oleks soovitatav ära defineerida /etc/hosts

 10.40.0.6  esimene.zoo.tartu.ee esimene pvelocalhost
 10.40.0.7 teine.zoo.tartu.ee teine

Logime üle SSH esimesse clustri nodesse (10.0.0.6) ja anname käsu

 # pvecm create YOUR-CLUSTER-NAME

To check the state of cluster:

 # pvecm status

Seejärel logime teise clustri nodesse (10.40.0.7) ja anname seal käsu

 # '''pvecm add 10.0.0.6'''
 copy corosync auth key
 stopping pve-cluster service
 Stopping pve cluster filesystem: pve-cluster.
 backup old database
 Starting pve cluster filesystem : pve-cluster.
 Starting cluster:
    Checking if cluster has been disabled at boot... [  OK  ]
    Checking Network Manager... [  OK  ]
    Global setup... [  OK  ]
    Loading kernel modules... [  OK  ]
    Mounting configfs... [  OK  ]
    Starting cman... [  OK  ]
    Waiting for quorum... [  OK  ]
    Starting fenced... [  OK  ]
    Starting dlm_controld... [  OK  ]
    Unfencing self... [  OK  ]
 waiting for quorum...OK
 generating node certificates
 merge known_hosts file
 restart services
 Restarting PVE Daemon: pvedaemon.
 Restarting web server: apache2 ... waiting .
 successfully added node 'jagaja' to cluster.

Konfiguratsioon /etc/pve/cluster.conf

 <?xml version="1.0"?>
 <cluster config_version="3" name="hailavaila">
   <cman keyfile="/var/lib/pve-cluster/corosync.authkey"/>
   <clusternodes>
     <clusternode name="koguja" nodeid="1" votes="1"/>
     <clusternode name="jagaja" nodeid="2" votes="1"/>
   </clusternodes>
 </cluster>

Järgnev rida on soovitatud ametliku dokumentatsiooni poolt, aga test on näidanud, et töötab edukalt kahe sõlmega ka ilma selle reata.

To be able to create and manage a two-node cluster, edit the cman configuration part to include this:

 <cman two_node="1" expected_votes="1"> </cman>

Virtuaalmasinate live migratsioon toimib vaikimisi üle SSH tunneli, juhul kui nodede taga on kasutusel turvaline võrk võib selle välja lülitada ning saada
seeläbi suurt kiirusevõitu. Muuta tuleks konfi /etc/pve/datacenter.cfg ja lisada

 migration_unsecure: true
 
Praegusel juhul nt võrdlesin kahte suvalist migratet enne ja pärast selle optioni määramist: ca 50MB/s ja 70MB/s versus 560MB/s ja 780 MB/s

====Fencing====

Fencing ehk automaatne migreerumine kui sõlmega midagi juhtub.

NB! Kui on teada, et soovite sõlme klastrist eemaldada mingite hooldustöödega seoses vms, siis on mõttekas kasutada ''live-migration'' funktsiooni, mida Proxmox VE pakub.

Fencing ei tööta "laivis", sellepärast et PVE eeldab, et masinaga on midagi juhtunud ja selle masina mälust (RAM) ei saada infot kätte. Kuna korralik klaster eeldab aga seda, et andmed on kuskil eraldi kettamassiivis, mida kõik klastri sõlmed kasutavad, siis saab sealt pealt masina uuesti käivitada.

Selleks, et konfigureerida klastrite vahel fencing, on vaja muuta kõigepealt käisitsi konfiguratsioonifaili. Hea praktika on konfiguratsioonifail kopeerida

 # cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new

ja seejärel asume muutma vastloodud faili

 # nano /etc/pve/cluster.conf.new

NB! agent="" on vaja määrata vastavalt IPMI kaardile. Tegemist küll redhat lehega, aga vaata linki: https://access.redhat.com/site/articles/28603 Tabelis on toodud väga paljud tootjad ja kaardid, mida on võimalik agent="" väärtuseks kirjutada. Kui juhtub, et informatsioon pole kättesaadav, proovi googeldada otsingufraasi "fencedevice agent".

Lisa järgnevad read faili. Asukoht pole väga oluline, peaasi, et lisad <cluster></cluster> tag'ide vahele. :)

 <fencedevices>
         <fencedevice agent="fence_impilan" hostname="nodeA.your.domain" lanplus="1" login="hpilologin" name="fenceNodeA" passwd="hpilopword" power_wait="5"/>
         <fencedevice agent="fence_ipmilan" hostname="nodeB.your.domain" lanplus="1" login="hpilologin" name="fenceNodeB" passwd="hpilologin" power_wait="5"/>
 </fencedevices>

Hostname on võimalik asendada IP aadressiga, siis tuleb hostname="" asemele kirjutada ipaddr=""

'''IP aadress (või hostname) peavad viitama IPMI kaardile, mitte füüsilisele masinale!'''

Seejärel on vaja iga <clusternode></clusternode> jaoks defineerida järgnevad parameetrid

    <clusternode name="test2" nodeid="2" votes="1">
      <fence>
        <method name="1">
          <device name="test2" port="3"/>
        </method>
      </fence>
    </clusternode>

Seletus:

- method name võite valida suvaliselt. Keerulisemates konfiguratsioonides on võimalik mitmeid meetodeid kirjeldada. Ehk siis võiks tuua analoogi - see on nagu if-lause. Kui esimene meetod ebaõnnestub, proovitakse teist, siis kolmandat jne.

- port parameeter hoiab seda sõlme ID väärtust, kuhu masinad migreeritakse. Migreeritakse vaid masinaid, mis on HA-s kirjeldatud! (loe altpoolt)

Lisaks suurenda kindlasti config_version numbrit (kui see on 1, pane 2, kui 10, siis 11 jne :)). See garanteerib selle, et konfiguratsioonifail paljundatakse teistesse sõlmedesse edasi. Kui see jääb muutmata, siis muudatusi ei paljundata.

Näiteks konfiguratsioonifail (kasutusel HP IPMI kaardid (Lights Out 100)).

 <?xml version="1.0"?>
 <cluster config_version="13" name="teetass">
  <cman keyfile="/var/lib/pve-cluster/corosync.authkey"/>
  <fencedevices>
    <fencedevice agent="fence_ipmilan" ipaddr="192.168.3.1" lanplus="1" login="admin" name="test1" passwd="k6vaparool" power_wait"=5"/>
    <fencedevice agent="fence_ipmilan" ipaddr="192.168.3.2" lanplus="1" login="admin" name="test2" passwd="k6vaparool" power_wait"=5"/>
    <fencedevice agent="fence_ipmilan" ipaddr="192.168.3.3" lanplus="1" login="admin" name="test3" passwd="k6vaparool" power_wait"=5"/>
  </fencedevices>
  <clusternodes>
    <clusternode name="test2" nodeid="2" votes="1">
      <fence>
        <method name="1">
          <device name="test2" port="3"/>
        </method>
      </fence>
    </clusternode>
    <clusternode name="test1" nodeid="1" votes="1">
      <fence>
        <method name="1">
          <device name="test1" port="2"/>
        </method>
      </fence>
    </clusternode>
    <clusternode name="test3" nodeid="3" votes="1">
      <fence>
        <method name="1">
          <device name="test3" port="1"/>
        </method>
      </fence>
    </clusternode>
  </clusternodes>
  <rm>
  </rm>
 </cluster>

Järgmiseks tuleb kõik sõlmed fencing'u domeeni liita. Selleks tuleb igas masinas muuta faili /etc/defauklt/redhat-cluster-pve ja sealt välja kommenteerida üks rida

Faili sisu: 

 # CLUSTERNAME=""
 # NODENAME=""
 # USE_CCS="yes"
 # CLUSTER_JOIN_TIMEOUT=300
 # CLUSTER_JOIN_OPTIONS=""
 # CLUSTER_SHUTDOWN_TIMEOUT=60
 # RGMGR_OPTIONS=""
 FENCE_JOIN="yes"

Kõikides sõlmedes tuleb käivitada administraatori õigustes käsk:

 # fence_tool join

Kui liidetud, siis võib kontrollida ka staatust

 # fence_tool ls
 fence domain
 member count  3
 victim count  0
 victim now    0
 master nodeid 2
 wait state    none
 members       1 2 3

Enne rakendamist oleks mõistlik kontrollida, kas uus konfiguratsioon on veatu. Seda saab teha kasutades käsku

 # ccs_config_validate -v -f /etc/pve/cluster.conf.new

Vastus võiks olla midagi taolist

 Config interface set to:
 Configuration stored in temporary file
 Updating relaxng schema
 Validating..
 Configuration validates
 Validation completed

Nüüd asendada konfiguratsioonifail

 mv /etc/pve/cluster.conf /etc/pve/cluster.conf.old

 mv /etc/pve/cluster.conf.new /etc/pve/cluster.conf

Ja mõne hetke pärast peaks olema konfiguratsioon ka paljundatud.

Järgnevalt on vaja kõikidel sõlmedel sisse lülitada üks teenus - "rgmanager". Seda saab teha kas käsurealt või valides graafilises liideses sõlme ja sealt "Services". Seejärel juba valida RGManager ja "start".

Nüüd on vaja adminstratsiooniliideses (https://192.168.1.1:8006 või mis iganes ta teil parasjagu on) valida vasakult menüüst Datacenter ja ülevalt HA. HA tähendab High Availability.

See peaks nüüd viisakamal kujul kuvama seaded, mis just XML koodis said kirjutatud.

Selleks, et masin käivitataks, kui sõlmega midagi juhtub on vaja seal lehel valida Add -> HA managed VM/CT. Avanenud kasti tuleb kirjutada virtuaalmasina (VM) või konteineri (CT) ID, mida soovitakse ümber tõsta ning "Autostart" ette teha linnuke. Kui nüüd peaks sõlmega midagi juhtuma, peaksid kõik HAs kirjeldatud virtuaalmasinad, mis asetsevad sellel sõlmel, ennast ümber kolima mõnele teisele.

See tähendab, et kui sõlmel on töötavaid masinaid, mis ei ole HAs kirjeldatud, siis need peatatakse. NB! Neid ei käivitata ka siis, kui sõlme normaalne töö on taastunud - sellisel juhul on vaja administraatori / kliendi sekkumine (oma masina käivitamiseks).

====Clustri node hooldus====

If you need to reboot a node, e.g. because of a kernel update you need to stop rgmanager. By doing this, all resources are stopped and moved to other nodes. All KVM guests will get a ACPI shutdown request (if this does not work due to VM internal setting just a 'stop').
You can stop the rgmanager service via GUI or just run:

 #/etc/init.d/rgmanager stop

Kui midagi läks ikkagi viltu siis saab kõigi nodede konfiguratsiooni nullida ära järgmiste käskudega

<source lang=bash>
#!/bin/bash

echo "######"
echo "See skript kustutab konkreetsest Proxmoxi nodest kogu konfiguratsiooni!!!!"
echo "Beware!"
echo "Ctrl+C panemiseks aega 10 sekundit!"

sleep 10

/etc/init.d/rgmanager stop

/etc/init.d/cman stop
killall -9 corosync cman dlm_controld fenced

/etc/init.d/pve-cluster stop
rm /etc/cluster/cluster.conf
rm -rf /var/lib/pve-cluster/* /var/lib/pve-cluster/.*
rm /var/lib/cluster/*

echo "tee nyyd reboot ja lisa node uuesti"
</source>

Ja seejärel on mõistlik teha reboot (vahel võivad mõned clustri teenused jääda rippuma)

*permission denied - invalid ticket (401)

 # pvecm updatecerts --force

Kontrolli üle ka kõigi node kellaajad! Need võivad olla sünkroonist väljas. Mõni millisekund antakse vast andeks.

Kui migreerimine annab veidraid veateateid ja logis teated:

 Feb  5 12:43:45 koguja corosync[3329]:   [TOTEM ] Received message has invalid digest... ignoring.
 Feb  5 12:43:45 koguja corosync[3329]:   [TOTEM ] Invalid packet data

Siis võib oletada, et võrgus on mingi clustri node, mis pole seotud clustriga kuid, mis saadab multicast aadressile "halbu signaale"
Peale node cman teenuse peatamist veidrad veateated kadusid.

'''Probleemid Proxmox 2.0-2.1 versioonil fence kasutamisega'''

Päris bugivaba see uus proxmox pole. HA optsiooni lisamisega läks miskipärast katki võimalus
migreerida omatahtmist mööda virtuaalmasinaid

 Executing HA migrate for VM 109 to node jagaja
 Trying to migrate pvevm:109 to jagaja...Target node dead / nonexistent
 TASK ERROR: command 'clusvcadm -M pvevm:109 -m jagaja' failed: exit code 244

Paistab teistelgi sarnaseid jamasid

*http://forum.proxmox.com/threads/9351-HA-errors-and-odd-behaviour-when-adding-servers-to-HA-Cluster

===Virtuaalmasinate taastamine ilma HA olemasoluta===

Kui clustris pole HA seadistatud ja üks clustri õlgadest peaks riknema siis kuidas startida töötavas masinas üles virtuaalmasinad, mis asusid katki läinud serveril?

'''/etc/pve/nodes''' kaust on sünkroniseeritud pmxcfs abil ning sisaldab igas clustri masinas kõigi nodede virtuaalide konfiguratsioone. Näiteks clustris, kus on kolm node ja kolm virtuaalserverid näeb selle kausta struktuur välja selline

 /etc/pve/nodes/node1/qemu-server
 100.conf
 /etc/pve/nodes/node2/qemu-server
 101.conf
 /etc/pve/nodes/node3/qemu-server
 102.conf

Kui node1 on seiskunud saab startida vm-100 virtuaalmasina suvalisel teisel srveri logides ühte allesjäänud õlga ja liigutades konfiguratsiooni töötava serveri kausta. Näiteks node2 peale

 # mv /etc/pve/nodes/node1/qemu-server/100.conf /etc/pve/nodes/node2/qemu-server/100.conf. 

Peale seda on võimalik startida vm-100 juba läbi veebiliidese. Või siis käsurealt

 # qm start 100

===Virtuaalmasinate migreerimine===

KVM kasutab virtuaalmasinate "elusaks migreerimiseks" ehk live-migrationiks pre-copy mehanismi. Täpsemalt
toimuvad pre-copy mehanismi rakendumisel järgmised etapid.

*1. Warm-up faas, proxmox üritab kopeerida kõik mälulehed (pages) algkohast-sihtkohta, ajal mil virtuaalmasin endiselt töötab.
*2. Kui algpunktis asuvas virtuaalmasina mälus toimub mingi muutus, märgitakse vastav mäluleht räpaseks ehk dirty. Kui esimene kopeerimine
on lõppenud, kopeeritakse kõik räpaseks märgitud lehed uuesti. Seda protsessi korratakse vajadusel kuni uuesti kopeeritud mälulehtede
kogus on suurem kui algvirtuaali jäänud räpaste mälulehtede oma, et olla kindel, et ainult väga ebaolulised muudatused on jäänud sünkroniseerimata.
*3. Kui räpaste lehtede kogus on väiksem kui uuesti kopeeritud lehtede oma lõpetatakse warm-up faaas ja algab stop-and-copy faas. Selle käigus
originaalne virtuaalmasin peatatakse ja allesjäänud räpased lehed kopeeritakse uude sihtpunkti. Virtuaalmasina maasolek võib sellekäigus
kestan millisekunditest kuni mõne sekundini.
*4. Kui kõik räpased mälulehed on kopeeritud jätkab kvm virtuaalmasina tööd.

===KSM (Kernel Samepage Merging) ja KVM===

KSM (Kernel SamePage Mergin) on hiljutine linux kerneli funktsioon, mis kombineerib
erinevate protsesside idetsed mälulehed (memory pages) üheks mälus asuvaks koopiaks.

Redhat väidab, et KSMi testides olid nad võimelised vedama 600 virtuaalmasinat 48 tuuma
ja 256GB mäluga.

[[Pilt:Ksm.png]]

Kerneli seadistus juhul kui tegemist enda loodud kernelgia:

 Processor type and features --->
     [*] Enable KSM for page merging

Kui eksisteerib kaust /sys/kernel/mm/ksm siis on KSM kerneli tugi olemas.

KSM käivitamiseks

 # echo 1 > /sys/kernel/mm/ksm/run

Lisaks võib tõsta mälu skaneerimise intervalli, et CPU poleks selle tööga liiga ülekoormatud.

 # echo 200 > /sys/kernel/mm/ksm/sleep_millisecs

KSM töötamise kontrollimiseks:

 # cat /sys/kernel/mm/ksm/pages_sharing
 169978

Kui väärtus on nullist suurem (nagu hetkel on) siis KSM toimib.

 #  for ii in /sys/kernel/mm/ksm/* ; do echo -n "$ii: " ; cat $ii ; done
 /sys/kernel/mm/ksm/full_scans: 0
 /sys/kernel/mm/ksm/pages_shared: 0
 /sys/kernel/mm/ksm/pages_sharing: 0
 /sys/kernel/mm/ksm/pages_to_scan: 100
 /sys/kernel/mm/ksm/pages_unshared: 0
 /sys/kernel/mm/ksm/pages_volatile: 130200
 /sys/kernel/mm/ksm/run: 0

Lisaks on olemas pakett Ksmtuned, mis tegeleb KSMi funktsioonis sisee-välja lülituse ja haldusega. Ksmtuned paketi jaoks vaja paigaldada:

 # apt-get install ksm-control-daemon

Ksmtuned deemoni saab käivitada:

 # /etc/init.d/ksmtuned startˇ

NB! Vaikimisi ei käivita ksmtuned enne KSMi kui mälukasutus pole üle 50% ja pisema mälukoormuse korral lülitab ta KSMi välja. Tarkvara seadistusfaili leiab /etc/ksmtuned.conf

 /sys/kernel/mm/ksm/sleep_millisecs: 300

http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm

http://pve.proxmox.com/wiki/KSM

http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/chap-KSM.html

===Jagatud storage===

Jagatud andmehoidla kasutamine kõigist masinatest on üldiselt kõige kergem ja jõudlusesõbralikum iSCSI/FC abil Näiteks teha nii, et FC/iSCSI storage on jagatud kõigile masinatele korraga. Nt on lõigatud storagest 20TB suurune tükk ja võetud külge kõigile kümnekonnale nodele. Sellele viilakale on tehtud omakorda LVM ja sellel LVMil on kokku nii umbes 200+ virtuaalmasinat.

Proxmox on ise üsna tark, et ta oskab lvmi viilaka kus virtuaalmasin on aktiveerida vaid õigel nodel kus masin parasjagu töötab ja kõigis teistes nodedes samal ajal deaktiveerida.
Kui teed virtuaalmasinale migreerimise ühelt nodelt teisele siis peale mäluseisu kopeerimist teeb proxmox lvm viilakale kus masin asub antud nodes deativate ja uues nodes kuhu migreeritakse activate. Nii saavad kõik noded sõbralikult üht sama välja jagatud ketast jagada ja migreeruda mööda clustrit.

[[Pilt:Screen-add-storage.png]]

'''LVM grupid''' - pve arendajate poolt soovituslik

Using LVM groups provides the best manageability. Logical volumes can easily be created/deleted/moved between physical storage devices. If the base storage for the LVM group is accessible on all Proxmox VE nodes (e.g. an iSCSI LUN) or replicated (with DRBD) then all nodes have access to VM images, and live-migration is possible. 

Esiteks paigutad kõigile kolmele masinale FC kaardid ja jagad neile ühe suure kettaviilaka välja, mis tuleb siis kõigile kolmele-viiele masinale külge kui  /dev/sdb

Teiseks tekitad ühes suvalises nodes pvecreate/vgcreate sellele /dev/sdb seadmele. Ühtlasi pead vaatama, et lvm2 utiliidid jms on kõigis nodedes olemas

Esimesena loome physical volume (pv):

 # pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created

teiseks loome volume group (vg)

 # vgcreate suurketas /dev/sdb1
  Volume group "usb-stick" successfully created

Ja kõige viimasena tuleb lisada LVM grupp webiliidese kaudu storage alamjaotisest proxmoxi masinale. Selleks tuleb logida enda proxmoxi clustrisse (masinad peavad olema klustriks liidetud), võtad storage menüüst, et lisa allikas, valid LVM ja lisad rippmenüüs oleva lvm allika. See tekib automaatselt seejärel kõigisse nodedesse.

NB! LVM ketast luues tasub märkida "Shared" linnuke, et oleks võimalik virtuaalmasinatele ''online migration''-it teha.

Ketastel ei pea olema sama nimi, proxmox leiab nad üles lvm nime järgi milleks nt "ketas" või "suurketas" või mida iganes, reaalselt võib nt olla nii, et /dev/sdb on ühes nodes füüsiline ketas ja lvm on reaalselt /dev/sdh, see ei muuda midagi.

Selleks, et LVMi peal mõnda tekitatud viilakat suurendada

 # lvextend -Ay -r -L +50G /dev/system/pve

Antud käsk lisab 50GB lisaruumi pve partitsioonile.
 
'''iSCSI LUNide otsekasutus'''

Ehk siis haakida iSCSI LUNid proxmoxi haldusest külge ja jagada otse virtuaalmasinatele edasi. Ka võimalik aga arendajate poolt mitte soovitatud.

Note: Currently iSCSI LUN´s are not protected from the Proxmox VE management tools. This means if you use a iSCSI LUN directly it still shows up as available and if you use the same LUN a second time you will loose all data on the LUN.

*http://pve.proxmox.com/wiki/Storage_Model

*Proxmox DRBD cluster

DRDB peamiseks miinuseks, et drdb clustrisse saab seadistada vaid kaks serverit mis toimivad mirrorina.

Soovitatav on, et kettal või partitsioonil, kus virtuaalmasinad resideeruvad oleks eelnevalt seadistatud LVM

*http://pve.proxmox.com/wiki/DRBD Ametlik seadistusjuhend
*http://www.drbd.org/ DRBD ametlik kodulehekülg
*http://kuutorvaja.eenet.ee/wiki/DRBD_kasutamine_Debianiga DRBD kasutamine Debianiga

===VMile USB andmine===

Olgu kohe alguses öeldud, et VM-ile USB andmine kaotab igasuguse võimaluse VMi migreerida. Ka stopped olekus. Lisaks ei ole GUI kaudu võimalik näha, kas VMi küljes on mõni USB seade või mitte. Seda näeb vaid konfi kaudu käsurealt.

Suska füüsiline USB sisse ja anna nodes käsk lsusb -t. Vastus võiks olla midagi sellist:

 $ lsusb -t
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M
     |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
         |__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/3p, 480M
 *            |__ Port 2: Dev 4, If 0, Class=stor., Driver=usb-storage, 480M*
             |__ Port 3: Dev 5, If 0, Class=HID, Driver=usbhid, 1.5M
             |__ Port 3: Dev 5, If 1, Class=HID, Driver=usbhid, 1.5M
 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M
     |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

Siit tuleb nüüd taga ajada õige seade: '''Bus 02:Port1:Port 5:Port2'''

Konfi võiks kirjutada midagi sellist

 usb0: host=2-1.5.2

Masinale stop/start ja küljes see peakski olema.

====Töötavale VMile====

Kui soov juba töötavale VMile külge anda USB, siis tuleks logida sisse sinna hosti, kus see VM on (ja USB ka). Seejärel kirjuta: 

 qm monitor VMID 

ja käsk on ikka ülemise näite jaoks 

 device_add usb-host,id=malupulk,hostbus=2,hostport=1.5.2

See peaks külge andma töötavale VMile USBi. Linuxiga proovisin, töötab. Küll aga muudatus ei säili pärast rebooti. Seega - soe soovitus on panna konfi ja teha masinale stop/start - siis on kindel, et vastav seade alati küljes on.

Nimi on vajalik selleks, et seda pärast küljest ära võtta. Ilma nimeta mina muud varianti ei leidnud kui reboot.

Ära võtmiseks:

 qm monitor 254 ja siis device_del malupulk

====Migreermine kohalike USB seadmetega====

 qm migrate vmid target [OPTIONS]

Tuleb anda masinas, kus konkreetne VM on. Näiteks midagi sellist:

 qm migrate 254 node5 -force -online

===Ketta suurendamine===

Kui ketast vaja suurendada, siis kõigepealt võta GUI kaudu: '''Hardware -> HDD ja ülevalt menüüst resize'''. Increment küsib GB suurust, kui mitu suurendatakse (mitte lõppsuurust)!
Suurendad ära, siis kustuta fdiskiga olemasolev partisioon, loo uus täisulatuses ning kirjuta muudatused kettale.

Leidsin ka ühe lohutuse: >
 > I know 'delete the partition' sounds scary, but it doesn't change the data at all. It just changes the thing that references the container. As long as you DON'T mkfs.ext4 you should be fine.

Seejärel tee: 

 e2fsck -f /dev/vda1
ja siis: 
 resize2fs /dev/vda1

Ja tulemuseks on suurenenud partitsioon ja failisüsteem.

===KVM masinate varundus ja taastamine===

Esiteks pakub proxmox üsnagi põhjaliku varunduse veebiliidese

[[Pilt:Screen-Scheduled-Backup.png]]

Pildil näha võimalused backupide automaatse tegemise seadistamiseks.

[[Pilt:Varu2.png]]

Max_backup tähendab, et varundada saab 1 backupi iga VMi kohta. Kui kasutada ülalnähtavat backup-schedulet sis
eemaldatakse vanad backupid iga käivitamise järel. Üldiselt peaks veebiliidese kasutamine olema piisavalt intuitiivne, et selle lahtiseletamisele ilmselt palju aega kulutama ei pea. Selleasemel keskenduks utiliitidele, milledega saab masinaid varundada ja taastada käsurealt.

Oletame, et meil on virtuaalmasin ID'ga 250, selle andmed asuvad LVMi peal ning ketta suur on 15G ja soovime
teha full bacupi kogu masinast.

Varundamiseks

 # vzdump --compress lzo 250

Mille järel tekib meile 6G suurune kompressitud varukoopia. Võti --snapshot paneb utiliidi kasutama LVM2 snapshotte.

Taastamiseks. Kui virtuaalmasinat enam ei eksisteeri siis ta tekitatakse.

 # '''qmrestore /var/lib/vz/dump/vzdump-qemu-250.vma 250'''
 restore vma archive: lzop -d -c /var/lib/vz/dump/vzdump-qemu-250-2014_06_11-15_54_19.vma.lzo|vma extract -v -r  /var/tmp/vzdumptmp816614.fifo - /var/tmp/vzdumptmp816614
 CFG: size: 212 name: qemu-server.conf
 DEV: dev_id=1 size: 16106127360 devname: drive-ide0
 CTIME: Wed Jun 11 15:54:21 2014
   Logical volume "vm-156-disk-1" created
 new volume ID is 'voluum1:vm-156-disk-1'
 map 'drive-ide0' to '/dev/virtuaalid/vm-156-disk-1' (write zeros = 1)
 progress 1% (read 161087488 bytes, duration 1 sec)
 progress 2% (read 322174976 bytes, duration 1 sec)
 ...
 progress 99% (read 15945105408 bytes, duration 104 sec)
 progress 100% (read 16106127360 bytes, duration 105 sec)
 total bytes read 16106127360, sparse bytes 647921664 (4.02%)
 space reduction due to 4K zero bocks 1.08%

Kõikide virtuaalmasinate backupimiseks ja administraatorile sellekohase mailisaamiseks

 # vzdump --all --mode suspend --mailto root --mailto admin

VMA faili sisse saab ka vajadusel piiluda

 # lzop -d vzdump-qemu-156-2014_06_12-13_08_29.vma.lzo 
 # vma  list vzdump-qemu-156-2014_06_12-13_08_29.vma
 CFG: size: 212 name: qemu-server.conf
 DEV: dev_id=1 size: 16106127360 devname: drive-ide0
 CTIME: Thu Jun 12 13:08:30 2014

Kõigi nodes toimuvate varundustööde peatamiseks

 # vzdump --stop

Kui süsteem teatab: '''VM is locked (backup) (500)''' aitab lahtilukustamine

 # qm unlock vm_id

Varundus teemalised lingid

http://www.yakakliker.org/Cat%C3%A9gorie_%3A_Virtualisation/Proxmox/Sauvegardes_Proxmox

VMA formaadist ja selle saamisest

https://git.proxmox.com/?p=pve-qemu-kvm.git;a=blob;f=backup.txt

https://git.proxmox.com/?p=pve-qemu-kvm.git;a=blob;f=vma_spec.txt

===Logi===

Proxmoxi veebiliidesest näidatav logi on üldiselt kättesaadav ka nodedest aga kahjuks vägagi raskesti loetav (eriti näiteks kuupäevade osas)

Selline käsurida paneb proxmoxi logi indeksile kuupäevad ette:

 while read line; do d=$(echo $line | cut -d : -f 5); d=$((0x$d)); d=$(date '+%Y-%m-%d %H:%M:%S' -d @$d); echo "$d $line"; done < /var/log/pve/tasks/index

Konkreetse logirea sisu näeb /var/log/pve/tasks/ alamkataloogidest. Näiteks selle logirea

 UPID:koonerdaja:0008FBCC:02139D39:550E9E75:qmstart:239:root@pam: 550E9E78 OK

detaile peaks otsima alamkataloogist "5" (viimane märk stringis 550E9E75)

===Clustri arhidektuur===

Proxmoxi cluster koosneb peaasjalikult kolmest suurest komponendist nagu Corosync, cman ja pmxcfs.

Corosync on framweork mis mõeldud clustri kommuninatsiooni jaoks. Esimene ja madalam pool HA clustri tarkvarast. Teine nö "kõrgem" pool on clustri resursihaldur, milleks proxmoxi puhul on CMAN.
Corosync üritab garanteerida seda, et kõik clustri "õlad" ehk noded suudaksid saata ja vastuvõtta teateid üle erinevate komunikatsioni radade ("rings"). Corosync toetab erinevaid
transpordiviisie näiteks UDP, unicast UDP ja InfiniBand. Vaikimisi kasutab proxmoxi corosync multicasti. Corosync koosneb lisaks mitmetest teenustest

*cpg - Closed Process Group
*sam - Simple Availability Manager
*confdb - Configuration and Statistics database
*quorum - Provides notifications of gain or loss of quorum

CMAN hoiab järge clustri õlgade kohta monitoorides kõigi nodede teateid. Näiteks kui clustrisse tekib uus node siis cman  teavitab kõiki selle komponente. Kui node ei suuda teatud aja jooksul anda vastust, siis
cman eemaldab node enda nimekirjast ja teatab sellest kõiki ülejäänud nodesid. Oluline mõiste on veel quorum, viimane on terviklik kui üle poolte nodede on aktiivselt elus. Kui mitte siis quorum puudub. Quorum
on mõeldud split-brain olukordade lahendamiseks. CMAN koosneb kahest suuremast tükist. Connection manager (cnxman) mis tegeleb eventide, quorumi,notifikatsioonide jms, ja Service manager (sm) mis haldab teenuseid, mis vajavad clustri tuge.

Proxmox Cluster file system (pmxcfs) on andmebaasi (sqlite) põhine failisüsteem, mis mõeldud virtuaalmasinate konfiguratsioonifailide salvestamiseks
ja replikeerimiseks masinate vahel üle Corosynci. Maksimumsuuruseks andmetel mida saab seal hoida on 30MB (see tuleb asjaolust, et kõike infot hoitakse ka nodede ramis).
Täpseamalt on kasutuses  Corosync Cluster Engine ja sqlite ning fuse, mille abil mounditakse konfid /etc/pve alla. Pmxcfs andmebaasifail asub nodedes /var/lib/pve-cluster/config.db

Cman on peamine kubjas, mis stardib corosync deemoni. Cluster.conf fail laetakse corosynci andmebaasi ja see leiab kasutust corosynci, mani ja teiste clustriga seotud deemonite poolt.

Abiks võib olla pmxcfs nimeline utiliit. corosync-quorumtool -l näitab kõiki nodesid.

 # '''ccs_tool lsnode'''
 
 Cluster name: hailavaila1, config_version: 3
 
 Nodename                        Votes Nodeid Fencetype
 koguja                             1    1    
 jagaja                             1    2    
 rabaja                             1    3    

Kui corosync on kasutatud cmani keskkonnas siis corosync.conf faili ei kasutata.

http://linux.die.net/man/5/cluster.conf

http://linux.die.net/man/5/cman

http://linux-ha.org/wiki/Cluster_Concepts

===LDAP autentimine===

Proxmox ei toeta by-default non-anonymous bindi. Selleks on vaja paar muudatust teha:

Muuda faili: '''/usr/share/perl5/PVE/Auth/LDAP.pm'''

Kirjuta sinna lisaks sub properties{} sisse:

    bind_dn => {
        description => "LDAP bind DN",
        type => 'string',
        pattern => '\w+=[^,]+(,\s*\w+=[^,]+)*',
        optional => 1,
        maxLength => 256,
    },
    bind_pw => {
        description => "LDAP bind password",
        type => 'string',
        optional => 1,
        maxLength => 256,
    },

Siis vaata, et /etc/pve/cluster.conf failis oleksid sellised read LDAPi autentimise juures:

    bind_dn CN=Proxmox asutus,CN=Users,DC=tartu,DC=zoo,DC=ee
    bind_pw parool

Ja ära enam veebi kaudu cluster.confi muuda, muidu lähevad need read kaduma.

===Uue clustri tekitamine või poolitamine===

Klastri uuesti loomisel VMide tööd ei häirita (kvm protsessid jäävad käima). Küll aga kaovad KÕIK konfifailid. Seega, vajalik on /etc/pve/ kaustast backup

 # tar -czf /root/pve.tar.gz /etc/pve

* Veendu, et uus võrk töötaks (sh mutlicast).
* Veendu, et /etc/hosts failis on uued aadressid kirjas (ja vanad eemaldatud) 

Seejärel tekita eemalda vanad noded olemasolevast klastrist: '''pvecm delnode nodenimi'''

Tekita uues masinas uus klastri konf:

 /etc/init.d/rgmanager stop
  
 /etc/init.d/cman stop
 killall -9 corosync cman dlm_controld fenced 
 
 /etc/init.d/pve-cluster stop
 rm /etc/cluster/cluster.conf
 rm -rf /var/lib/pve-cluster/* /var/lib/pve-cluster/.*
 rm /var/lib/cluster/*
 /etc/init.d/pve-cluster start
 
 pvecm create <cluster_name>

Kui klaster ühega loodud, siis mine teise "uude" nodesse ja tee seal:

 /etc/init.d/rgmanager stop
  
 /etc/init.d/cman stop
 killall -9 corosync cman dlm_controld fenced
 /etc/init.d/pve-cluster stop
 rm /etc/cluster/cluster.conf
 rm -rf /var/lib/pve-cluster/* /var/lib/pve-cluster/.*
 rm /var/lib/cluster/*
 /etc/init.d/pve-cluster start

Kui cmani juures configfs stoppima jääb, siis katkesta ära, jäta see välja, killall lahendab ära, loodetavasti.

Seejärel lisa ta klastrisse käsuga pvecm add olemasoleva_node_aadress

Tõenäoliselt tahad taastada (aga vaata enne failid üle). Kõik failid suhtelised /etc/pve/ kausta suhtes

* user.cfg (andmed kasutajate, poolide ja gruppide kohta)
* priv/shadow.cfg (pve kasutajate parooliräsid)
* vzdump.cron (backup cron)
* domains.cfg (sisselogimisrealmide kohta info)
* storage.cfg (ketaste jm salvestusseadmete info)
* nodes// (VMide conf failid)
* datacenter.cfg (datacenter seaded, nt migration_unsecure: true seda ei saa GUI kaudu seadistada) 

PS: Clustrist kustutatud node ei kao enne proxmoxi serverite menüüst kuni pole kustutatud /etc/pve/nodes alt serverinimelist kausta 

====Pveproxy====

Tegemist on deemoniga, mis tegeleb proxmoxi veebiliidese näitamisega. Selle käivitab
init skript /etc/init.d/pveproxy mis tegelikult stardib tööle perlis kirjutatud skripti /usr/bin/pveproxy

Sama perli skripti seest saab vajadusel vaadata ka mõningate failide radu või neid muuta. Näiteks sertifikaatide
kohta on seal sees read

        ssl => {
            cipher_list => $proxyconf->{CIPHERS} || 'HIGH:MEDIUM:!aNULL:!MD5',
            key_file => '/etc/pve/local/pve-ssl.key',
            cert_file => '/etc/pve/local/pve-ssl.pem',
        },

Pveproxy kuula 8006 pordil. Selleks, et süsteem oleks ligipääsetav standartsetelt portidelt võib ehitada
clustrile ette näiteks haproxy.

[[Pilt:Haproxyprok.png]]
<source lang=apache>
global
    maxconn 4096
    pidfile /var/run/haproxy.pid
    daemon

defaults
    mode tcp
    balance source
    retries 3
    maxconn 20480

    timeout client 500s
    timeout connect 500s
    timeout server 240s

listen http-in :80
    mode http
    redirect location https://proxmox.edu.ee

#server syntaks: server serveri_nimi_ilmub_statistikas ip_aadress:port lisaparameetrid
listen https-in :443
    mode tcp
    balance source
    server node1 192.168.1.5:8006 check
    server node2 192.168.1.6:8006 check
    server node3 192.168.1.7:8006 check

listen konsool_5900 :5900
    mode tcp
    balance source
    server node1 192.168.1.5:5900
    server node2 192.168.1.6:5900
    server node3 192.168.1.7:5900

listen konsool_5901 :5901
    server node1 192.168.1.5:5901
    server node2 192.168.1.6:5901
    server node3 192.168.1.7:5901

listen konsool_5092 :5902
    server node1 192.168.15.15:5902
    server node2 192.168.15.16:5902
    server node3 192.168.15.17:5902

listen stats 192.168.1.4:1936
    mode http
    stats enable
    stats realm Haproxy\ Statistics\ admin:admin
    stats refresh 15s
    stats uri /
    stats auth admin:admin
</source>

===Probleemid===

Probleemide korral kontrollida kas /etc/hosts failis on mõlemas masinas info korrektne, on
proxmoxi versioon identne ning kellaajad süngis.

Kui masin ei taha endiselt clustrisse minna ja tundub olevat quorumi ootamise taga tasub uurida kas multicast töötab

http://kuutorvaja.eenet.ee/wiki/V%C3%B5rgudiagnostika#Ssmpingiga_multicasti_toimimise_testimine

====Krüpto ja šifrid====

/etc/default/pveproxy failis on kirjas nimekiri (kõikides nodedes) mis annab pveproxyle ette lubatud šifrite loetelu.
  
 CIPHERS="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-...CBC3-SHA"

/usr/bin/pveproxy failis saab turvakaalutlustel teha järgneva muudatuse, et keelatud oleks SSLv3 ja lubatud TLSv1.2 ja TLSv1.1:

 # Method rida välja kommenteeritud, lisatud "sslv3 => 0,"
 #           method => "tlsv1",
             sslv3 => 0,

LISA: Proxmoxi arendajad kirjutasid koodi sisse sslv2 ja sslv3 disablemise pärast listis küsimist ja lahenduse pakkumist sertifikaatide teemal.

https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=f6bc4a73d0f252bbae1d5a769068351ed1cc33a1

====Rippuma jäänud tööd====

Vahel võib juhtuda, et mõni task menüüribal olev element jääb lõputult kerima ega suuda enda tegevust lõpetada, selle eemaldamiseks aitavad järgnevad käsud

 cd /var/log/pve/tasks
 rm -f active index */UPID*
 /etc/init.d/pve-cluster restart

====Clustri maksimaalne suurus====

Tundub, et hetkel on proxmoxi muude komponentide poolest võimalik ehitada suuri clustreid, ainult corosync pidurdab kuna tal on hardcoded limiidiks 64 node.

 Corosync "entering GATHER state from 11" when the cluster nodes > 64

https://bugzilla.redhat.com/show_bug.cgi?id=905296#c5

====Proxmoxi konsoolipilt videoks====

Mul on pidevalt see häda, et Proxmoxi buutimise veateated kaovad ekraani serva taha ära ja kerida ei lase, et neid lugeda.
Nüüd avastasin, et Proxmoxi kasutatav TightVNC lubab (kui Java lubab) ekraanistriimi salvestada faili RFB formaadis ja on proge nimega RFBProxy, mis suudab seda lugeda.

Ekraanipildi salvestamiseks tuleb Proxmoxi konsooliaknas vajutada nuppu "Record", määrata failinimi, kuhu salvestada ja siis jälle "Record".

Edasi sikutada programm RFBProxy: http://sourceforge.net/projects/rfbproxy
Kompileerida ja siis lasta järgmine käsk käima

 $ rfbproxy -x vncsession.fbs.001| ffmpeg -r 60 -f image2pipe -vcodec ppm \
 -i - -vcodec libx264 -vpre ultrafast -crf 20 -threads 0 -bf 0 -y vncsession.mp4

*-x võtmega sülitab rfbproxy sessiooni PPM formaadis stdouti ja ffmpegiga saab selle kenasti MP4 videoks keerata.

Oma veateate sain igatahes ära lugeda.

PS. Kui faili suurus on oluline, siis selle -crf võtme väärtust võib suurendada. Kuni 35 tundus veel tekst loetav olevat.

====Kui switch ei toeta multicasti====

Selline olukord poleks sugugi ebatavaline, mida siis teha? tuleb lülitada cluster ümber unicastile. Selleks on vaja clustri konfis teha muudatus real

 <cman keyfile="/var/lib/pve-cluster/corosync.authkey">

Muutes selle järgnevaks

 <Cman keyfile = "/var/lib/pve-cluster/corosync.authkey" transport="udpu">

Ja unustada ei tohiks ka muuta real:

 <cluster name="clustername" config_version="2">

config_version parameetrit.

http://pve.proxmox.com/wiki/Multicast_notes

====NO QUORUM====

Kui midagi läks valesti, nt teatatakse veateade "NO QUORUM" ja oleks vaja node read-onlyst kirjutatavaks teha (st
tahame teha muudatusi /etc/pve/cluster.conf failis)

 # pvecm e 1

(The read-only gets turned on in an orphaned cluster node for safety.)

====Ubuntus java paikaseadmine====

Java on vajalik selleks, et näha üle browseri virtuaalmasina konsoolipilti.

Juhul kui konsoolipilt ei taha ilmuda või hangub on võimalik, et kasutusel on vale java versioon.

How to switch Firefox Java plugin to Sun Java on Ubuntu Linux

Open Synaptic and go to Settings -> Repositories -> Other Software and activate the Canonical partner repo. Now close Synaptic, fire up a terminal and run the following commands in order, selecting Sun Java (java-6-sun) where appropriate:

 # sudo apt-get update
 # sudo apt-get install sun-java6-bin sun-java6-fonts sun-java6-jdk sun-java6-plugin
 # sudo update-alternatives --config java

The tricky part is: even when you have Sun's Java runtime installed, Firefox will still default to the open source IcedTea plugin, unless you tell it not to. Run the following command and select Sun's Java web browser plugin:

 # sudo update-alternatives --config mozilla-javaplugin.so

====Enterprise repositooriumi eemaldamine (veateade 401)====
Proxmox annab veateadet 401 - Not Authorized, kui pärast vaikeinstalli minna menüüsse ja valida "updates". Kuna Proxmox'ile on võimalik ka raha maksta, et saada ametliku tugiteenust (support), siis on see repositoorium jäetud konfiguratsiooni sisse.

Selleks, et seda veateadet ei kuvataks, võib selle repositooriumi välja kommenteerida - seniks, kuni otsustate, kas raha maksta, või siis seniks, kuni kasutate tasuta versiooni.

Selleks on vaja avada fail

 # nano /etc/apt/sources.list.d/pve-enterprise.list

Ja sealt välja kommenteerida järgnev rida

 # # deb https://enterprise.proxmox.com/debian wheezy pve-enterprise

====FreeBSD ja Ivy bridge probleem (2013. veebruar algus)====

Nii naljakas kui see esmapilgul ka ei tundu - Ivy bridge protsessoriga serverid ei suuda 64 bitist FreeBSDd bootida ning jääb kohe peale kerneli laadimist "rippuma". Teiste CPUdega ei paista seda probleemi olevat.
Googeldades tekkis mulje (sama viga oli ka paljudel teistel), et probleemiks on konkreetne raud+kvm bugid. Mainiti mingit koleda nimega värki nagu "ivy bridge".

2013 aprilli tekst ühest foorumist: " Seems that Ivy bridge processor + proxmox/KVM + FreeBSD is a recipy for problems. Hope it will be resolved. Tried different bios.bin files from seabios but that didn't help either. Somewhere read something about disabling USB in perl file. Didn't help either."

http://forum.proxmox.com/threads/11843-Proxmox-2-2-Freebsd-8-3-AMD64-freezes-can-not-start-installation Link asjale siin.

====VMide suures koguses ümbernimetamine====

Probleem: Vaja on kokku ühendada kaks clustrit aga seal olevat virtuaalmasinad omavad samu ID numbreid. Käsitsi
nimetamine on üsnagi tülikas sest VMi ID järgi on genereeritud ka LVMi viilaka nimi. Appi tuleb skript: vmrenumber.sh 

NB! KVM masinad mida liigutatakse tuleb eelnevalt peatada, muidu tekib kõrvale uus uue IDga KVMi protsess ja failisüsteem võib saada kahjustatud.

<source lang=bash>
#!/bin/bash

if [ ! -e /tmp/renumber ]; then
  echo "no renumbering file"
  exit 1
fi

for i in `cat /tmp/renumber`; do
  old=$i
  new=$(($i+15))
  if [ -e /etc/pve/qemu-server/${new}.conf ]; then
    echo "${new}.conf exists, exiting"
    exit 1
  fi
  if lvs --noheadings -o vg_name,lv_name | grep -q "vm-${new}-disk"; then
    echo "vm-${new}-disk exists, exiting"
    exit 1
  fi
</source>

Skript loeb numbrid failist /tmp/renumber ja paneb igaühele uueks numbriks +15 (vt. rida 10),mille peab siis kohendama vastavalt
kohandama endale. Skript peaks olema piisavalt turvaline selles suhtes, et midagi jäädavalt katki ei keera, vana vm-i konfifail jääb ka alles. Ainuke häda, mis esines oli lvrenamega, mis osadel juhtudel jättis vana symlingi ripakile vms.

Kui seda skripti panna tööle, siis peaksid olema kõik masinad ühe node peal, sest et muidu ei kuvata seal teistes nodedes olevaid ID-sid.

 # '''sh vmrenumber.sh'''
 sed: preserving permissions for `/etc/pve/qemu-server/sed5XL0va': Function not implemented
   Logical volume "vm-100-disk-1" changed
   Logical volume "vm-100-disk-1" changed
   Renamed "vm-100-disk-1" to "vm-145-disk-1" in volume group "virtuaalid"
   Logical volume "vm-100-disk-2" changed
   Logical volume "vm-100-disk-2" changed
   Renamed "vm-100-disk-2" to "vm-145-disk-2" in volume group "virtuaalid"

====Kõigis nodedes sama käsu käivitamine====

Nodesid on sageli palju ja vaja neis mingeid rutiinseid töid teha, nt kõigile teatud pakett paigutada, kuidas teha? lihtne

 for masin in `cat nodes.txt`; do echo -n "$masin: " && ssh root@$masin "uname -r"; done

Ülalolev käsk võtab nodes.txt failis ip aadressid ja käivitab neis kõigis käsu uname -r selleks, et saada nimekiri
kasutuses olevatest kernelitest.

====Unable to open port 60000-60010====
Tuntud ka: live migration ei tööta, offline töötab *VÕI* Java konsool ei avane (authentication failed)

Probleemiks on tõenäoliselt samasugused SSH võtmed. Proxmoxi klaster on küll omavahel sõber, aga kõikide masinate root kasutajatel peab olema OMA SSH võti.

   cat /root/.ssh/id_rsa

Tuleks võrrelda masinate vahel. Kui on sama, siis kõige lihtsam/turvalisem lahendus on masinad sealt pealt ära võtta, node välja võtta klastrist, tühjaks teha, taaskäivitada ja siis uuesti liita.

/etc/hosts fail võib samuti olla vea põhjuseks (127.0.0.1 localhost pluss kõikide teiste nodede aadressid peavad olema olemas)

====authentication failed====

Kui node teatab nt java konsoolis "authentication failed" võib viga olla nodede erinevates kellaaegades. Tasub kontrollida ntpd seadeid.

====Infoleke LVMilt====

Proxmox ei kustuta virtuaalmasinat eemaldades LVMilt infot ja nii võib uut virtuaali tekitades muutuda
ühe kasutaja info teisele loetavaks.

Probleemi ka pve-listis sama märgatud

http://pve.proxmox.com/pipermail/pve-user/2015-July/008940.html

Neil imelik arhiveerimise süsteem, aga followup'e peaks ka paar tükki olema

http://pve.proxmox.com/pipermail/pve-user/2015-July/thread.html#8940