Een VM heeft 3 componenten:
rbd
(rados block device).kvm-data
ceph pool./mnt/xmlStorage/vm-xml
op elke KVM node.example.xml
die men kan kopieren om nieuwe VM’s te maken.virsh
shell op een KVM node waar de VM op dat moment runt.pcs
.Disclaimer: subject to change
Alles is verbonden met het intern netwerk (192.168.0.0/24
) via een switch. De admin interfaces van de kvm nodes zijn verbonden via dezelfde NIC als de verbinding van de server zelf. De kvm en ceph nodes zijn daarbij ook nog met elkaar verbonden via een ‘backend’ netwerk (192.168.10.0/24
) via een aparte switch. De ceph nodes zijn met dit netwerk verbonden met 2 NICs die geteamed zijn. De kvm nodes hebben externe IP adressen die toegankelijk zijn vanaf de buitenwereld, die gebeurt via VLAN’s (193..
adressen).
Algemene status van de cluster kun je op elke kvm node zien je met
By default staat de cluster uit en moet die aangezet worden. De volledige cluster starten en stoppen kan op eender welke kvm node:
Een specifieke node uit de cluster halen voor bv. hardware maintanance:
pcs cluster stop <node> # <node> weglaten = huidige node
# en starten (kan ook op eender welke node)
pcs cluster start <node>
cluster stop
operaties kunnen even duren omdat VM’s eerst moeten worden gemigreerd of uitgezet.(dit gebeurt automatisch)
Een node in standby zetten, d.i. een node die deel van de cluster is maar geen resources mag hosten:
Bij het migreren moet men er wel van bewust zijn dat Pacemaker ook andere VM’s gaat verplaatsen om zo een optimale “spreiding” te behouden.
Een processor kan veel sneller geheugen aanpassen dan dat die zijn geheugen over het netwerk kan verstuurd worden. Een VM migreren met heel zware load kan hierdoor falen.
TODO resource-stickiness TODO ordering is blijkbaar speciaal
De VM moet eerst uit staan.
Men kan die disk image dan terug ‘restoren’ naar die snapshot met:
Deze rollback kan wel even duren.
Om disks te clonen moet je eerst een snapshot hebben en die read-only is. Read-only maken gaat zo:
Dan pas kun je de snapshot clonen.
Clonen gaat instant omdat dit COW clonen zijn. Dit is dus ook veel sneller dan rollbacks. Men kan een volledige kopie maken van deze COW clone met:
Als een nieuwe VM een clone is van een base image kan het zijn dat die image vrij klein is.
Dit maakt de enkel de disk groter. De partities van de VM zelf zullen binnen de VM groter gemaakt moeten worden. Een partitie vergroten kan met:
Een ext4 filesysteem kan dan vergroot worden met resize2fs /dev/<partitie>
zonder meer. Die zoekt zelf de maximale grote uit. Partities/filesystems resizen kan allemaal terwijl de VM runt.
Zie het Clones hoofdstuk voor een bestaande image te kopieren. Als men toch zelf een wilt maken kan dit zo op een ceph node:
Log dan in op een kvm node en kopieer example.xml
in /mnt/xmlStorage/vm-xml
naar /mnt/xmlStorage/vm-xml/<vm-naam>.xml
en pas de waardes tussen de curly brackets aan ({{ variable }}
). Een uuid kan je genereren met uuidgen
. Er zijn ook 3 netwerk interfaces gedefineerd (<interface type='network'>
blokken). Meestal heb je daar maar 1 van nodig en mag je de rest verwijderen. extern
verweist naar de externe VLAN, intern
naar 192.168.0.0/24
interne ulyssis netwerk en ceph
naar het 192.168.10.0/24
backend netwerk.
Het volgende veel te lange commando zal dan de nieuwe VM in de cluster aanmaken en starten.
Run pcs status
om te kijken om welke kvm node de VM draait en log dan daar op in. Als men een bestaande image heeft gekopieerd kan men inloggen op een VM ookal heeft die nog geen netwerk met: