Tag: virtualisierung

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 😉

– 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…

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.

nach dem update auf osx 10.7.4 habe ich beim starten einer virtuellen maschine mit vmware (3.1.1) folgende fehlermeldungen bekommen:

Kernelzonengröße können nicht abgerufen werden.

Initialisierung des Monitorgeräts fehlgeschlagen.

Kein gültiger Peer-Prozess zum Herstllen der Verbindung gefunden.

ein update von vmware fusion auf die version 3.1.4 brachte die erhoffte loesung des problems…

dem /dev/null blog geklaut… aber ich wollts hier auch nochmal geschrieben haben:

Um die XEN Console unter Mac OS X bzw dessen Terminal zu verlassen CTRL+ALT+6 !

xm console bleibt haengen

nach einem quasi p2v eines alten debian etch auf eine xen domU hat das mit dem “xm console ” zwar noch die konsole des gastes angezeigt, aber an einem gewissen punkt ist diese anzeige einfach stehen geblieben und reagierte nicht mehr auf tastatureingaben. problem ist, dass durch das “p2v” die /etc/inittab und /etc/securetty des alten systems mit ueberspielt wurden und deswegen die passenden eintraege fehlten. das erste console device heisst in der domU nicht tty1, sondern hvc0.

damit die xen console wieder funktioniert, ist folgendes zu in der domU zu tun:

echo hvc0 >> /etc/securetty

und in der datei /etc/inittab muss man diese zeile:

1:2345:respawn:/sbin/getty 38400 tty1

abaendern in diese:

1:2345:respawn:/sbin/getty 38400 hvc0

zwei nics – auch in der domU

meine dom0 hat zwei netzwerkkarten und ein paar der darauf laufen domUs sollen auch darueber kommunizieren. und wie? erstmal braucht man in der dom0 zwei bridges dazu hab ich erstmal diese datei angelegt:

vi /etc/xen/scripts/network-bridge-wrapper

und mit diesem inhalt gefuellt:

#!/bin/bash
/etc/xen/scripts/network-bridge $@ netdev=eth0
/etc/xen/scripts/network-bridge $@ netdev=eth1
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -A FORWARD -m physdev --physdev-in peth0 -j ACCEPT
iptables -A FORWARD -m physdev --physdev-in peth1 -j ACCEPT

zur erklaerung: dieser wrapper ruft nur das default xen script fuer die bridges zweimal auf, damits halt zwei bridges werden. die iptables regeln (fuer die option “antispoof=yes”) sind aus dem originalen script “network-bridge” ausgelagert, da aufgrund des “DROP” sonst nur die zuletzt angelegte bridge funktioniert.

die datei muss noch ausfuehrbar gemacht werden:

chmod a+x /etc/xen/scripts/network-bridge-wrapper

..und natuerlich muss man sie auch in der xend config einbinden, damits funktioniert:

vi /etc/xen/xend-config.sxp

die zeile suchen:

(network-script 'network-bridge antispoof=yes')

und ersetzen mit:

(network-script network-bridge-wrapper)

so.. genug fuer heute 😉

basierend auf dem testserverchen (debian lenny 64bit) hier ein echt kurzes xen (4.0.1) howto. und los gehts…

die benoetigten pakete installieren:

apt-get install xen-hypervisor xen-linux-system xen-utils xenstore-utils xenwatch xen-tools

die config datei fuer die xentools bearbeiten. (theoretisch kann man den kram auch alles auf der commandline mitgeben)

vi /etc/xen-tools/xen-tools.conf

…das eintragen:

lvm = vg0
dist   = `xt-guess-suite-and-mirror --suite`
gateway    = 192.168.0.1
netmask    = 255.255.255.0
broadcast  = 192.168.0.255
passwd = 1
kernel = /boot/vmlinuz-`uname -r`
initrd = /boot/initrd.img-`uname -r`
mirror = `xt-guess-suite-and-mirror --mirror`
serial_device = hvc0
disk_device = xvda

die xen(d) config anpassen:

vi /etc/xen/xend-config.sxp

und diese werte setzen bzw. aendern:

[...]
(network-script 'network-bridge antispoof=yes')
[...]
(vif-script vif-bridge)
[...]

und nach einem abschliessenden reboot kann der erste virtuelle server installiert werden:

xen-create-image --hostname=vs.sd.vc --size=150Gb --swap=4Gb --ip=192.168.0.100 --memory=1Gb --arch=amd64 --role=udev

dank der xen-tools config wird ein debian lenny installiert. andere kann man z.b. mit dem parameter “–dist=etch” instalieren.

die virtuelle kiste noch “anschalten” und gut is:

xm create /etc/xen/vs.sd.vc.cfg

have fun!

so… nachdem ich jahrelang mit dem vmware server gearbeitet habe, mache ich mich nun mal an xen.
fuer die ersten gehversuche hab ich mir bei manitu einen rootserver gemietet. die entscheidung fiel auf manitu, da es dort (im gegensatz zu z.b. hetzner) standardmaessig vier ipadressen zu einem server gibt. da es ja nur zum “probieren” ist, reicht mir der rootserver M mit einem amd dualcore und 4gb ram vollkommen aus. zudem gibts keine mindestvertragslaufzeit bzw. ist monatlich kuendbar.

der server, der mir zugewiesen wurde, hatte prompt ein problem mit der hardware. von den zwei physikalischen festplatten wurde meistens nur eine erkannt. manchmal auch beide… und das mal so und mal so. der support hat mir kurzerhand einfach einen neuen server gegeben. mal schauen, wie es nun klappt.

um die kiste nach meinen vorstellungen zu partitionieren, hab ich ihn erstmal neu installiert. 4gb swap und 100gb fuer die root partition und beides als raid1. der rest wird ein lvm fuer die xen maschinchen. mit cfdisk auf beiden platten einfach den freien platz als eine partition des typs FD eingerichtet. das sieht dann so aus:

~# fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         523     4200966   fd  Linux raid autodetect
/dev/sda2             524       13578   104864287+  fd  Linux raid autodetect
/dev/sda3           13579      121601   867694747+   5  Extended
/dev/sda5           13579      121601   867694716   fd  Linux raid autodetect

manchmal ist ein boot an dieser stelle notwendig. danach kann das raid device eingerichtet werden:

mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda5 /dev/sdb5

da kommt auch gleich wieder eine fehlermeldung:

mdadm: excess host name on HOMEHOST line:  - ignored
mdadm: excess address on MAIL line: root - ignored

die man mit einem freundlichen

vi /etc/mdadm/mdadm.conf

..und aendern der entprechenden werte los werden kann.

und damit die raid devices auch in der mdadm.conf stehen, muss man diesen befehl ausfuehren:

mdadm --detail --scan >> mdadm.conf

nun noch ein paar sachen drauf, die man sowieso immer braucht:

apt-get install ntp ntpdate rsync mc postfix lvm2 dmsetup reiserfsprogs xfsprogs

und die passende zeitzone einstellen:

dpkg-reconfigure tzdata

danach noch das physical volume und die volume group anlegen:

pvcreate /dev/md2
vgcreate vg0 /dev/md2

das reicht erstmal als vorbereitung fuer den xen server. das zeugs mit dem lvm wird gemacht, weil:
“Virtual machines that use disk images are very slow and heavy on disk IO”. normalerweise muesste man naemlich noch die standardeinstellung fuer die maximalen loopback devices in der datei “/etc/modules” erhoehen, damit man die ganzen disk images mounten kann.

morgen gehts weiter mit der installation der virtuellen maschinen. dann mal schauen, wie ich am einfachsten “alte” physikalische maschinen virtualisiere…