Netzwerkblog

Archiv für die Kategorie „XenServer“

Im XenCenter ist die Exportfunktion die einfachste (und vor allem ohne Zusatzkosten) Möglichkeit eine Sicherung einer Virtuelle Maschine zu erstellen. Einfach einen rechtsklick auf den Eintrag im linken Baum auf die VM, Export und angeben wohin damit. Das Ergbnis ist eine einzige Datei die auf jedem beliebigen XenServer wieder importiert werden kann. Die VM muss dabei heruntergefahren oder suspended sein.

Effizient bedeutet hier, die exportierte Datei so klein wie möglich zu erhalten. Diese läßt sich dann meist nochmal via RAR oder ZIP halbieren.

Je länger man eine VM betreibt und darin Dateien erstellt und wieder löscht desto größer wird der Export einer virtuellen Festplatte. Wenn man erstmal 5 Gigabyte Logdateien gelöscht hat, wundert sich vielleicht auch, warum der Export immernoch so groß ist. Das liegt daran, dass gelöschte Dateien nicht wirklich gelöscht werden, sondern einfach nur aus der Allokationstabelle entfernt werden und der Bereich zum überschreiben freigegeben wird. Die Exportfunktion des XenCenter, kann dies leider nicht unterscheiden und der Export wird so groß als wären die Dateien noch vorhanden.

Abhilfe schafft ein Tool von Microsoft, “SDelete” von Sysinternals. Eigentlich ein Sicherheitswerkzeug um gelöschte Dateien auch wirklich zu löschen, überschreibt es die freigegeben Festplattenbereiche mit Nullen (“0000 0000″). Aber vorsicht, danach sind versehentlich gelöschte Dateien auch mit “undelete”-Werkzeugen nicht mehr wiederherstellbar.
Anwendung: In der Kommandozeile “sdelete -c” und abwarten.

Dannach sollte die exportierte Datei entsprechend der gelöschten Dateien kleiner sein.

Eine Komprimierung mit RAR tut den Rest.

Wie man das unter Linux macht, werde ich noch beschreiben.

Es kursieren eine Menge Texte und Lösungsvorsachläge zu diesem Problem im Internet.
Alle Tricks die im Internet zu finden sind, haben leider nicht funktioniert … irgendwann beim überprüfen der Netzwerkkarteneinstellungen habe ich eine Lösung gefunden, die funktioniert hat. Wahrscheinlich löst sie ähnliches aus, wie dieser “DisableTaskOffload” RegestryKey Hack auslösen sollte …

Folgende Umgebung:
XenServer 5.6 mit einer Windows Server 2003 SP2 VM und installierten XenTools.

Problem:
Extrem schlechte Netzwerkperformance der 2003er VM, vor allem bei einem http-Zugriff auf den IIS.

Weiterlesen, testen und bitte kommentieren …

Diesen Beitrag weiterlesen »

neue Platte(n) ist/sind bereits eingebaut und angeschlossen …

‘fdisk -l’ ergibt folgende Ausgabe:

[root@xen03 ~]# fdisk -l

Disk /dev/sda: 999.9 GB, 999989182464 bytes
255 heads, 63 sectors/track, 121575 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         523     4194304   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2             523        1045     4194304   83  Linux
/dev/sda3            1045      121575   968162548   8e  Linux LVM
Disk /dev/sdb: 999.9 GB, 999989182464 bytes
255 heads, 63 sectors/track, 121575 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdb doesn't contain a valid partition table
Disk /dev/sdc: 499.9 GB, 499989348352 bytes
255 heads, 63 sectors/track, 60786 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdc doesn't contain a valid partition table

Wir sehen: sdb und sdc sind unberührt.

pvcreate /dev/sdb

Physical volume "/dev/sdb" successfully created

[root@xen03 ~]# ll /dev/disk/by-id

total 0
lrwxrwxrwx 1 root root  9 Sep  6 20:29 scsi-3600050e083404f00c3bd0000c9210000 -> ../../sda
lrwxrwxrwx 1 root root 10 Sep  6 20:29 scsi-3600050e083404f00c3bd0000c9210000-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Sep  6 20:29 scsi-3600050e083404f00c3bd0000c9210000-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep  6 20:29 scsi-3600050e083404f00c3bd0000c9210000-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Sep  6 20:29 scsi-3600050e08354a80095f1000078390000 -> ../../sdb
lrwxrwxrwx 1 root root  9 Sep  6 20:29 scsi-3600050e08354c600441b0000c9210000 -> ../../sdc

Dann für jedes neue Laufwerk:

[root@xen03 ~]# xe sr-create type=lvm content-type=user device-config:device=/dev/disk/by-id/scsi-3600050e08354a80095f1000078390000 name-label="Local storage 2"
[root@xen03 ~]# xe sr-create type=lvm content-type=user device-config:device=/dev/disk/by-id/scsi-3600050e08354c600441b0000c9210000  name-label="Backup"

Die Laufwerksnamen und GUIDs müssen natürlich angepasst werden.

Nach der Installation einer CentOS VM mit GUI ist im XenCenter kein Umschalten auf den “Graphical Desktop” möglich. Dazu muss noch VNC auf der VM eingerichtet werden.

Zuerst in der XenCenter Console zur entsprechenden VM mit root anmelden. Macht man dies das erste Mal, sollte im TextModus eine Konfigurationswizard zum OS erscheinen. Alles nach Wünschen einrichten und die Firewall deaktivieren. Diese kann kann später in der graphischen Oberfläche komfortabler aktiviert und konfiguriert werden.

Mit Putty auf die VM verbinden und als root anmelden.

rpm -q vnc-server gdm

auf der Konsole ausführen. Installiert den VNC-Server und GDM bzw. gibt die Versionsnummern aus, wenn diese bereits installiert wurden.

/etc/gdm/custom.conf

mit vi editieren so dass das Ende der Konfigurationsdatei so aussieht:

[servers]
0=VNC

[server-VNC]
name=VNC Server
command=/usr/bin/Xvnc -SecurityTypes None -geometry 1024x768 -depth 16 \
-BlacklistTimeout 0
flexible=true

GDM starten:

/usr/sbin/gdm

Nun im XenCenter auf den “Graphical Desktop” umschalten oder mit einem VNC Viewer mit der VM verbinden. Als nächstes die Firewall aktivieren und konfigurieren und darauf achten, dass Port 5900 offen ist.

Damit gdm nach einem Neustart nicht wieder neu gestartet werden muss, kann man den Runlevel von 3 auf 5 setzen.

Dazu die Datei /etc/inittab editieren.

Grundvorraussetzung: Der XenServer muss über eine funktionierende Internetanbindung (Stichwort DNS Server und Std-GW) verfügen, bzw. den FTP-Server im LAN erreichen können.

Beim anlegen der VM den Installationspfad angeben, wie z.B.: ftp://ftp.uni-frankfurt.de/pub/Mirrors/centos/5.3/os/i386/

Den Unterpfad zur XEN-Varriante (images/xen/) wird durch das XenCenter automatisch angefügt.

Nur noch starten … und via VNC kann die Installation nun sogar mit einer grafischen Oberfläche durchgeführt werden.

FERTIG!!

XenServer Tools in einer CentOS installieren oder ein Update durchzuführen:

ISO aktivieren

cd /mnt
mkdir cdrom
mount /dev/xvdd /mnt/cdrom
cd cdrom
bash install.sh
...
reboot

FERTIG!!!

Nach Installation des 3DM 2 auf dem XenServer muss die Firewall noch konfiguriert werden.

Port 888 muss dazu geöffnet werden:

iptables -I RH-Firewall-1-INPUT 13 -p tcp -m state --state NEW -m tcp --dport 888 -j ACCEPT

Dann nur noch speichern:

iptables-save > /etc/sysconfig/iptables

Jetzt sollte der Zugriff auf das WebInterface des RaidControllers möglich sein: https://x.x.x.x:888

FERTIG!

Hinweis: Mit XenServer 5.6 wurde die Netzwerkkarte inzwischen anstandslos vom Setup erkannt und installiert.

Treiber bauen:

• Die DDK VM herunterladen und auf den XenServer importieren und starten.
• Passwort im XenCenter in der DDK VM Konsole festlegen.
• IP mit ‘ifconfig’ ermitteln.
• Intel Treiber herunterladen und zip Archiv entpacken.
• WinSCP mit der VM verbinden und das tar gz Archiv auf die VM kopieren.
• Terminalverbindung herstellen. z.B. mit Putty (komfortabler) oder im XenCenter
• Nun den Treiber entsprechend der Anleitung von Intel bauen.
• Das e1000e-Kernelmodul e1000e.ko von ‘/lib/modules/2.6.18-128.1.6.el5.xs5.5.0.505.1024xen/kernel/drivers/net/e1000e’ nun mit WinSCP herunterladen
• DDK VM herunterfahren
• Kernelmodul auf den XenServer ins Benutzerverzeichnis von root mit WinSCP kopieren (IP sie XenCenter).
• Terminalsession zum XenServer aufbauen.
• Folgende Befehle ausführen:

  find /lib/modules/2.6.18-128.1.6.el5.xs5.5.0.505.1024xen -name e1000e.ko -exec rm -f {} \; || true
  find /lib/modules/2.6.18-128.1.6.el5.xs5.5.0.505.1024xen -name e1000e.ko.gz -exec rm -f {} \; || true
  install -D -m 644 e1000e.ko /lib/modules/2.6.18-128.1.6.el5.xs5.5.0.505.1024xen/kernel/drivers/net/e1000e/e1000e.ko
  /sbin/depmod -a || true

• ‘ifconfig -a’ zeigt nun das neue Interface mit dem Namen: __tmp1440398073
• ‘lspci’ zeigt noch: 00:19.0 Ethernet controller: Intel Corporation Unknown device 10ef (rev 05)
• ‘update-pciids’ ausführen.
• lspci zeigt nun: 00:19.0 Ethernet controller: Intel Corporation 82578DM Gigabit Network Connection (rev 05)
• Verzeichnis nach ‘/etc/sysconfig/network-scripts’ wechseln
• Die Datei “ifcfg-eth0″ nach “ifcfg-eth1″ kopieren (‘cp ifcfg-eth0 ifcfg-eth1′)
• Mit ‘ifconfig -a’ die MAC Adresse ermitteln.
• Die neue Datei ifcfg-eth1 anpassen. Komfortabel geht das von WinSCP aus. Aus eth0 wird eth1 und die MAC ändern.
• Reboot, dann sollte ‘ifconfig -a’ sauber das NIC als eth1 anzeigen.
• Die NIC muss nun noch mit ‘xe pif-introduce’ dem XenServer bekanntgegeben werden:
  ‘xe pif-introduce host-uuid=<TAB> mac=<siehe ifconfig> device=eth1′

!FERTIG!

Eine Installation des XenServers auf ein SoftwareRaid mit Raid1 Spiegel ist so nicht möglich. Einen Umweg gibt es über eine weitere Platte auf der sich die eigentliche XenServer-Installation befindet. Somit wäre dann das StandardRepository und somit die VMs durch eine gespiegelte Platte geschützt.

Vorgehensweise:

1. 3 Platten in den Rechner, die Systemplatte sollte sich von den Spiegelplatten unterscheiden, so dass sie leichter beim Installieren erkannt werden können.
2. Spiegel im RaidBIOS einrichten und MIRROR als ähnlich bezeichnen.
3. Installation auf die Singleplatte vornehmen.
4. An der Console des XenServer anmelden (egal ob direkt, oder im XenCenter).

5. dmraid -ay

   sollte etwa soetwas ausgeben:

   /dev/mapper/isw_bibabu_MIRROR

   und das Raid ist nun aktiv

6. Raid als StorageRepository hinzufügen:

   xe sr-create host-uuid=TabTabFügtHierAutomatischEin name-label=SR_MIRROR type=lvm content-type=user shared=false device-config-device=/dev/mapper/isw_bibabu_MIRROR

7. Im XenCenter das neue SR als default setzten über Kontextmenü
8. FERTIG!

Die einfache Installation der Tools im XenCenter funktioniert leider nicht, da die Linux Version nicht korrekt ermittelt werden kann, bzw nicht unterstützt wird. Eine manuelle Installation fungiert aber dennoch, zumindest für die Xen-Version des Openfilers. Hier die Befehlskette für XenServer 5.6, 5.5 und 5.0

Einfach die Befehle wie unten eingeben:
Wichtig: die Tools ISO muss  korrekt ausgewählt sein und eine Verbindung zum Internet bestehen (StdGW in den Openfiler-Settings).

Alle XenServer-Versionen:

conary update beecrypt=contrib.rpath.org@rpl:devel
conary update rpm=rpm.rpath.org@rpl:devel/4.4.4
mount /dev/xvdb /mnt/cdrom
cd /mnt/cdrom/Linux/

XenServer 5.6:

rpm -ivh --nodeps xe-guest-utilities-5.6.0-578.i386.rpm
rpm -ivh --nodeps xe-guest-utilities-xenstore-5.6.0-578.i386.rpm

XenServer 5.5:

rpm -ivh --nodeps xe-guest-utilities-5.5.0-466.i386.rpm

XenServer 5.0:

rpm -ivh --nodeps xe-guest-utilities-5.0.0-367.i386.rpm)

Alle XenServer-Versionen:

cd /
umount /mnt/cdrom

Danach sollte in der Serverübersicht alle Daten angezeigt werden.