KVM- und XEN-VMs untereinander erreichbar

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.

nagvis kvm xen

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.

Xen

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.

Laconica und XEN

Problem war:

Vorlon hat sich einen Account bei identica.ca angelegt und folgt mir darueber auf mexdc.exdc. Nun wollte ich ihm natuerlich auch folgen, was aber auf teufelkommraus nicht funktionieren wollte. Im Laconica Log hatte ich nur:

2009-06-10 14:15:34 LOG_DEBUG: action.php – Server error ‚500‘ on ‚requesttoken‘: Expired timestamp, yours 1244643029, ours 1244643334

Und ich suche (und suche und suche) den Fehler dabei war es natuerlich nur die falsche Serverzeit. Exdc laeuft als XEN VM und hatte eine Abweichung von -5 Minuten. Mit date oder ntpdate war es auch nicht moeglich eine andere Zeit zu setzen. Man muss naemlich erst

echo 1 > /proc/sys/xen/independent_wallclock

tun, bevor man das kann. Zukuenftig sollte ein

extra = ‚independent_wallclock=1‘

in der /etc/xen/exdc.cfg reichen.

scponly mit chroot

Ich richte zur Zeit eine kleine Serverumgebung ein. Wer seinen usern nicht 100% traut sollte sich mal scponly mit chroot anschauen.

wichtig ist:

ln -s /lib/ld-linux-x86-64.so.2 /lib/ld.so
cd /home/scponly
cp -p /lib/libncurses.so.5 lib/
cp -p /lib/libdl.so.2 lib/
cp -p /lib/libc.so.6 lib/
mkdir lib64
cp -p /lib64/ld-linux-x86-64.so.2 lib64/

lib64 fuer 64bit Systeme. Den Rest findet man hier.