Tag: proxmox

NMI watchdog bug soft lockup – CPU#1 stuck for 23s!

eine meiner auf kvm basierten virtuellen maschinen auf basis ubuntu (16.04) mit virtio netzwerkkarte und openvpn hat unter belastung immer wieder diese meldungen geschmissen:

mit dem ergebnis, dass die cpu last ganz oben hing und die vm nicht mehr nutzbar war. ursache war der virtio treiber fuer die netzwerkkarte. (oder eher die kombination kernel und virtio nic.) nachdem ich das in proxmox auf eine e1000 umgestellt habe, flutscht das nur noch so. die cpu last ist zwar geringfuegig mehr, aber dafuer schmiert die kiste nicht mehr ab.

proxmox minimal firewall

wenn mann einen oder mehrere proxmox server installiert, lauschen standardmaessig ein paar dienste auf diversen ports. darunter auch der portmapper/rpcbind auf port 111. den will man nicht im internet am lauschen haben.

oft kann man das ding z.b. mit einem freundlichen “apt-get remove rpcbind” deinstallieren. aber proxmox scheints wohl zu benoetigen 😉

proxmox beinhaltet eine iptables basierte firewall, welche standardmaessig deaktiviert ist. damit man sich nicht gleich aussperrt, sollte man als erstes regeln fuer port 22 und 8006 anlegen. (“Destination” ist die (ggf. oeffentliche) ipadresse des servers). dazu habe ich azf “Datacenter” ebene unter “firewall” diese regeln definiert:

in meinem fall ist noch icmp erlaubt und kommunikation meines nagios servers zu proxmox auf port 5666. danach kann man in den options die input policy auf DROP setzen und die firewall aktivieren.

proxmox: mit firewall ausgesperrt

wenn man die firewall funktionalitaeten bei proxmox nutzt, hat man sich auch mal schnell selbst ausgesperrt, wenn bei der konfiguration z.b. eine gewisse reihenfolge nicht einhaelt 😉

wenn man das bei einem rootserver macht, auf den man keinen physikalischen zugriff hat, wirds bloed. die meisten hoster bieten aber ein rettungssystem an, in das man booten kann. wenn geschehen, muss man sich im rettungssystem seine festplatte mounten – z.b. nach /mnt – und die proxmox firewall ausschalten, so dass sie nach dem booten inaktiv ist.

dazu schreibt man einfach in die datei /mnt/etc/rc.local (sofern die platte nach /mnt gemountet ist)

pve-firewall stop

und nach dem naechste, normalen reboot wird die firewall gestoppt. nicht vergessen, den eintrag wieder raus zu nehmen, wenn alles wieder passt.

proxmox cluster “waiting for quorum…”

nach einem freundlichen “pvecm add ip.add.re.ss” um einen weiteren node zu einem proxmox cluster hinzuzufuegen, bleibt der output da stehen:

~# pvecm add ip.add.re.ss
The authenticity of host 'ip.add.re.ss2 (ip.add.re.ss2)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
root@ip.add.re.ss2's password: 
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...

da musste ich in dem unglaublich guenstigen, managbaren switch von netgear das IGMP snooping abschalten, welches standardmaessig aktiviert ist.

20161205_igmpsnooping

…und schon gings weiter

ova in proxmox nutzen

proxmox hat keine native unterstuetzung fuer ova templates. eigentlich verwunderlich, da es sich bei ova ja schliesslich um ein “offenes” format handelt. damit das trotzdem funktioniert, muss ein wenig hand angelegt werden.

das zu verwendende ova file ist erstmal auf den proxmox server kopieren. eine ova datei ist eigentlich nur ein tar archiv mit einer image datei (vmdk) der festplatte und einer config datei im ovf format. hier am beispiel einer ova datei von OpenVAS

reinschauen kann man mal mit

tar -tf OpenVAS-8-DEMO-1.0.ova

als ausgabe kommt dann sowas:

OpenVAS-8-DEMO-VM-1.0.ovf
OpenVAS-8-DEMO-VM-1.0-disk1.vmdk

und dann entpacken geht mit

tar -xvf OpenVAS-8-DEMO-1.0.ova

erst dachte ich, dass man einfach die vmdk in proxmox als platte einbinden kann… aber dann kam nach einem versuch zu booten nur kauderwelsch auf dem bildschirm raus… also doch die vmdk nach qcow2 konvertieren:

qemu-img convert -O qcow2 OpenVAS-8-DEMO-VM-1.0-disk1.vmdk output.qcow2

die virtuelle maschine muss man dann in proxmox anlegen (ein blick in die ovf datei kann auch nicht schaden. stichworte E1000, IDE usw) und dann die zuvor erzeugte datei “output.qcow2” einfach ueber die von proxmox erstellte datei (mit dem entsprechenden namen) drueber kopieren…. und schon bootet die maschinerie. 🙂

die neue computerspielwiese

als it onkel muss man ja auch viel rumprobieren. dank virtualisierung ist das heutzutage einfacher als frueher. schnell hat man sich mal ein testsystem zurecht gemacht und nachher auch wieder entsorgt. ich habe mir dafuer eine neue spielwiese zugelegt. klein sollte sie sein…. und das ist gelungen 😉

20161119_spielwiese

– intel NUC6i3SYK mit 32GB ram und 256GB ssd
– synology NAS ds416slim mit 2x2TB
– netgear managbarerer gigabit switch GS108E-300PES

darauf dann ein proxmox installiert, das nas per nfs als storage angebunden und fleissig vm’s installiert…

20161119_spielwiese2

ok, die performance ist jetzt nicht der hammer, aber zum rumspielen tuts das dicke. vielleicht bekommt das nas irgendwann auch nochmal zwei ssd’s fuer die virtual hdd files spendiert. dafuer ists klein und braucht nicht wirklich viel strom.