Schlagwort: kvm

Probleme nach libvirt Update

kero Schreib einen Kommentar

Sollte man bei KVM  mit Portweiterleitung für VMs (z.B.  iptables -t nat -A PREROUTING -p tcp -d 123.123.123.123 –dport 1234 -j DNAT –to-destination 192.168.99.99:22) arbeiten und folgende Debian Updates eingespielt haben:

[UPGRADE] libvirt-bin 0.8.3-5+squeeze2 -> 0.8.3-5+squeeze5
[UPGRADE] libvirt0 0.8.3-5+squeeze2 -> 0.8.3-5+squeeze5
[UPGRADE] python-libvirt 0.8.3-5+squeeze2 -> 0.8.3-5+squeeze5

Nach dem Einspielen aber bemerkt haben man , dass die Portweiterleitung nicht mehr funktioniert und man auch durch erneutes Eintragen der iptables/routing oder was auch immer für Regeln keinen Erfolgt erzielt, dann könnte tatsächlich ein Reboot des Hosts helfen.

clone your kvm vm

kero Schreib einen Kommentar

Wirtssystem:

lvcreate -L40G -n web2 WEB-VG
virt-clone --original web1 --name web2 -f /dev/WEB-VG/web2 --prompt

Danach auf der web2 VM:
/etc/hostname
/etc/mailname
/etc/network/interfaces
eventuell auch
/etc/hosts
editieren. Falls vorhanden, auch die TSM Konfiguration anpassen.
Geht natuerlich auch ueber z.B. virt-manager. Web1 muss waehrend des Klonens ausgeschaltet sein.

KVM- und XEN-VMs untereinander erreichbar

kero Schreib einen Kommentar

Ich wechsle zur Zeit von XEN zu KVM. Das ganze System verteilt sich ueber 4 Rechner. 3xKVM und 1xXEN. Jeder Host beherbergt 3-4 virtuelle Maschinen. Die VMs nutzen alle NAT im 192.168er Netz. Nun war es bei XEN kein Problem, dass sich die VMs ueber die Hostgrenzen hinweg erreichen konnten. XEN1-VM1 konnte also ohne Umwege  auf XEN2-VM1 zugreifen. Das vereinfacht natuerlich sehr viele Dinge (Mysql Replikation, failover und und und). Noetig war quasi nur ein

ip route add XEN2-VM1 via XEN2 dev eth0?

auf XEN1, damit von den XEN1-VMs auf die XEN2-VM1 zugegriffen werden konnte.  Entweder fuer jede VM einzeln oder fuer das ganze Netz eintragen, falls moeglich.

Nun kam KVM ins Spiel. Bei KVM konnte ich problemlos noch von XEN1-VM1 auf KVM-VM1 zugreifen. Umgekehrt, also von KVM-VM1 auf XEN1-VM1 funktionierte nicht. Abhilfe schaffte

?for i in /proc/sys/net/ipv4/conf/*/proxy_arp
do
echo 1 >>$i
done

Kann man natuerlich  auf die noetigen Interface begrenzen. Bei XEN war proxy_arp bereits aktiviert, daher gab es dort keine Probleme.

KVM image file vergroessern

kero Schreib einen Kommentar

1.?

cd /meine/images/
???truncate --size=+10G mein.img
virsh pool-refresh poolname

2. Dort http://gparted.sourceforge.net/download.php runterladen
3. Via virt-manager (oder Konsole) die VM von der CD starten
4. Mit gparted solange rumfrickeln bis man zufrieden ist (und ja Partitionen zu verschieben, die durch andere Partionen begrenzt sind bzw. durch Anfags- und Endsektor , ist nicht moeglich)
5. Das gparted iso wieder auswerfen und die VM von HD booten lassen
6. fertig

Das ist bei XEN ein bisschen schicker, aber darueber habe ich  irgendwann schon mal was geschrieben. Nutzt man LVM sieht das natuerlich alles anders aus. Auf jeden Fall sollte man vorher die Maschine zur Sicherheit klonen.

Als naechstes bauen wir uns einen KVM Cluster.

nagvis kvm xen

kero Schreib einen Kommentar

Bei Nagvis und dem ndo Backend:

dbinstancename nagvis not valid
da hat bei mir
dbinstancename=“Central“
geholfen.

XEN und KVM:

Damit die XEN VMs die KVM VMs erreichen:
XEN1 (192.168.1.1 usw.), XEN2(192.168.1.11 usw.), ( KVMs (192.168.1.51 usw) . Unter XEN hosts reicht ein 

ip route add IP_XEN_VM_AUF_XEN2 via IP_XEN2 dev INTERFACE_XEN1

Um die KVM VMS von den XEN VMs zu erreichen benoetigt man nicht nur

ACCEPT     all  —  0.0.0.0/0            192.168.1.0/24      state RELATED,ESTABLISHED
sondern
ACCEPT     all  —  0.0.0.0/0            192.168.1.0/24

Alles unter Debian Lenny ohne Gefrickel.
Das ist alles etwas aelter aber das mit XEN <-> KVM habe ich erst seit ich das von prego ausprobiert habe. Ich dachte state RELATED,ESTABLISHED wuerde ausreichen.

Qnap TS-219 nfs und kvm

kero Schreib einen Kommentar

Ich kann das Problem nicht 100%ig erklaeren. Anscheinend tauchte es nach einem Update der Qnap Firmware (Current firmware version: 3.3.6 Build 1109T) auf. Ich mounte ein NFS share vom Qnap TS-219 in eine KVM VM ein. Bisher gab es nie Probleme, heute kam dann jedoch

failed, reason given by server: Permission denied

Das NFS share wird nicht automatisch gemountet, daher ist mir das Problem auch erst heute aufgefallen. Auf dem Qnap liegen Backupdaten, auf die ich heute zugreifen wollte. Diverse andere XEN VMs nutzen diesen QNAP in gleicherweise. Diese haben jedoch keine Probleme die shares einzumounten.  Egal welche Einstellungen probiert wurden, die KVM VMs konnten die shares nicht einbinden. Herr E. aus G. gab mir den Tip als export Option beim Qnap „insecure“ einzufuegen. Tatsaechlich funktionierte danach der mount wieder. Unklar ist mir jedoch warum es nur bei den KVM VMs Probleme gab, sowohl der KVM Host als auch die XEN VMs hatten keine Probleme mit NFS.

Da bei jedem reboot, bzw. neu start des NFS Dienstes, die Eintraege in /etc/exports ueberschrieben werden, sollte man in

/mnt/HDA_ROOT/.config/nfssetting

insecure direkt eintragen

[Access]
/share/MD0_DATA/deinefreigabe = rw,insecure

http://forum.qnapclub.de/viewtopic.php?f=49&t=275

Xen

kero 4 Kommentare

Seit 1 Jahr betreibe ich nun zwei Xen Server produktiv. Auf beiden laufen jeweils 4 VMs. Ich muss sagen ich bin sehr zufrieden. Bisher gab es keine Probleme mit Xen. Ich reiche ein SAN Device an eine VM durch, was ohne Probleme funktioniert. Performance ist auch super und aehh… ja ist hoffentlich klar was ich damit sagen will ;-). Auf einer neueren Maschine setze ich nun aber doch KVM ein…da sind wir mal gespannt. Als Hardware bei den  Xens kommen 2x PE 1950er mit 8 Cores und 16 GB RAM zum Einsatz, beim neuen KVM 1xPE 2950 8 Cores 16 GB.