Skip to content

LVM Systemd Service

Da ich neulich in ein Phänomen rein gelaufen bin, das ich so seit langem nicht mehr gesehen habe..

Kunde wollte einen SLES12 mit folgender Partitionierung haben...

Zwei interne Platten /boot als eigenes md Device ohne LVM... danach ein zweites md Device mit LVM

drauf.

Anscheinend hat sowohl SLES12 als auch OpenSuSE Leap mit dieser Partitionierung Alzheimer....

Beim durchbooten vergisst der LVM das Er seine Volgroup aktivieren soll

Über die Sinnhaftigkeit der Partitionierung kann man streiten... aber was solls...

Um das Problem zu lösen...

hab icch mir folgendes Systemd  Manifest zusammen gedübelt.

Description=LVM activation
DefaultDependencies=no


Before=local-fs.target
Before=basic.target shutdown.target
Conflicts=shutdown.target

[Service]
ExecStart=/sbin/vgchange --available y
Type=oneshot
TimeoutSec=0
RemainAfterExit=yes

[Install]
WantedBy=basic.target

Danach klappts auch wieder mit der Nachbarin LVM.

Resizing von OCFS2 auf primary primary DRBD

Bevor mir jetzt einer von Euch sagt Iiiiih wieso macht Du so einen ekligen Scheiss?

Ja ich finds auch nicht geil....... aber der völlig verarmte $Kunde wollte mir kein SAN geben.... daher müssen wir mit diesem Schüttertool DRBD leben und weils grad aktuell ist

 Filesystem Resizing auf Logical Volumes mit DRBD und ja.... OCFS2.

Glücklicherweise geht sowas heute on the Fly und das umounten bei OCFS2 ist mittlerweile unnötig.

Auf beiden Nodes das Logical Volume erweitern…

sles12clusternode0:~ # vgs

  VG     #PV #LV #SN Attr   VSize   VFree

  system   1   9   0 wz--n- 279.36g 59.36g

sles12clusternode0:~ #  lvextend -L +15G /dev/system/drbd0

sles12clusternode1:~ #  lvextend -L +15G /dev/system/drbd0

Size of logical volume system/drbd0 changed from 50.00 GiB (12800 extents) to 65.00 GiB (16640 extents).

  Logical volume drbd0 successfully resized

sles12clusternode0:~ #

Auf einer Node

sles12clusternode0:~ # drbdadm resize clusterfs

Zu gucken....

Watch cat /proc/drbd

Every 2.0s: cat /proc/drbd                              Fri Sep 16 12:33:56 2016

version: 8.4.6 (api:1/proto:86-101)

GIT-hash: 833d830e0152d1e457fa7856e71e11248ccf3f70 build by abuild@sheep14, 2016

-05-09 23:14:56

0: cs:SyncSource ro:Primary/Primary ds:UpToDate/Inconsistent C r-----

    ns:32501844 nr:28075344 dw:56191872 dr:29966413 al:7280 bm:0 lo:0 pe:6 ua:0

ap:0 ep:1 wo:f oos:11346944

        [====>...............] sync'ed: 27.9% (11080/15356)M

        finish: 0:06:32 speed: 28,884 (29,804) K/sec

sles12clusternode0:~ # tunefs.ocfs2 -S /dev/drbd0

sles12clusternode0:~ # df -h

Filesystem                Size  Used Avail Use% Mounted on

/dev/mapper/system-root    16G  4.3G   12G  27% /

devtmpfs                   64G     0   64G   0% /dev

tmpfs                      64G   54M   63G   1% /dev/shm

tmpfs                      64G   19M   63G   1% /run

tmpfs                      64G     0   64G   0% /sys/fs/cgroup

/dev/mapper/system-blubb   60G   59G  1.1G  99% /mnt

/dev/mapper/system-home    10G   10G   20K 100% /home

/dev/mapper/system-tmp    5.0G   33M  5.0G   1% /tmp

/dev/mapper/system-opt    4.0G   58M  4.0G   2% /opt

/dev/mapper/system-var     15G  1.4G   14G   9% /var

/dev/mapper/system-kdump  4.0G   33M  4.0G   1% /var/crash

53.51.138.142:/mnt         60G   59G  1.1G  99% /var/tmp/nfs

/dev/drbd0                 65G   45G   21G  69% /opt/omd

sles12clusternode0:~ #

Falls jetzt noch jemand wissen will wieso ich das nicht mit CLVM realisiert hab...... das Dumme Ding hat die Angewohnheit  das ich nicht von beiden Nodes aus LVM Snapshots ziehen kann. Daher ist es unter den Tisch gefallen und der Kunde selber ist jetzt auch nicht gerade das was man als Cluster affin betrachten würde. Sie wollten den Scheiss aber trotz vielen Warnungen haben.... und war der Meinung ein 200 Seiten Handbuch des Cluster Bauers würde alle Probleme erschlagen... bei dieser High Availability Lösunf für Arme  und Pfuscher tongue

Den guten Solaris Cluster wollte man ja nicht haben........ und SAN ist ja das böse..... es könnte ausfallen....... *kopf tisch*

Vmware Module sauber im Linux Gast installieren.

Install Vmware Modules

SLES 10

mkdir /var/tmp/vmware

Relevante Vmware Packages nach /var/tmp/vmware kopieren.

cd /var/tmp/vmware/

rpm -ivh --nodeps .rpm

SP1

zypper sa --type=YUM http://packages.vmware.com/tools/esx/5.5//sles10_i586/  vmware-collection </code>

SLES 11

SP1

i 586

zypper addservice --type=YUM http://packages.vmware.com/tools/esx/5.5/sles11.1/i586 vmware-tools

amd64

zypper addservice --type=YUM http://packages.vmware.com/tools/esx/5.5/sles11.1/x86_64 vmware-collection

SP2

amd64

zypper addservice --type=YUM http://packages.vmware.com/tools/esx/5.5/sles11.2/x86_64 vmware-collection

i586

zypper addservice --type=YUM http://packages.vmware.com/tools/esx/5.5/sles11.2/i586 vmware-collection

SP3

i586

zypper addservice --type=YUM http://packages.vmware.com/tools/esx/5.5/sles11.3/i586 vmware-collection

amd64

zypper addservice --type=YUM http://packages.vmware.com/tools/esx/5.5/sles11.3/x86_64 vmware-collection

Zypper

zypper install vmware-tools-collection vmware-tools-esx-kmods-default vmware-tools-esx mware-tools-vmxnet3 vmware-tools-pvscsi

PAE Kernel Wichtig

zypper install vmware-tools-esx-kmods-pae vmware-tools-pvscsi-kmp-pae vmware-tools-vmmemctl-kmp-pae vmware-tools-vmxnet3-kmp-pae vmware-tools-vsock-kmp-pae vmware-tools-collection vmware-tools-services

RHEL 5

kdir /var/tmp/vmware

Relevante Vmware Packages nach /var/tmp/vmware kopieren.

cd /var/tmp/vmware/

rpm -ivh --nodeps .rpm

RHEL 6

yum localinstall --nogpgcheck .rpp

RHEL 4

 mkdir /var/tmp/vmware 

Relevante Vmware Packages nach /var/tmp/vmware kopieren.

cd /var/tmp/vmware/

rpm -ivh --nodeps .rpm

Check Modules!

Check auf den vmtools Prozess

pgrep -fl vmtoolsd


/sbin/lsmod

modprobe vmxnet3

lsmod | grep vm

Wie es ungefaehr aussehen sollte.

vmxnet3                35122  0 
vmci                   92131  1 vsock
vmmemctl               13390  0 
vmxnet                 18490  0 

Achtung!!!!

Das ganze schlägt fehl wenn:

/usr/lib/vmware-tools  
/etc/vmware*
existiert.. oder nicht sauber installiert ist
Vmware nicht entfernt wurde.
Im Zweifel den ganzen Gammel erst suchen und abräumen

Bitte Vmware Tools nicht am Paketmanager vorbei installieren!!

Linux Disk aublasen

Disk im Esxi größer ziehen..

 echo 1 > /sys/block/sdb/device/rescan
dmesg |grep cap


pvresize /dev/sdb


legato:~ # lvextend  -L +"WivielGigabyte ich habenwill" /dev/mapper/backupvg-advfs
legato:~ # xfs_growfs /dev/mapper/backupvg-advfs

Spacewalk Channels auf der Shell konfigurieren

Da ich grade im aktuellen Projekt von Heimatbasis aus arbeite ... ergeben sich mithin VPN Obskuritäten.

Kurz und gut.. wenn ich mich beim Kunden über VPN einwähle komme ich nicht an die GUI des Spacewalkserver ran.

However... da beim Kunden die ganze Linuxlandschaft erneuert werden muss und auch Bestandsysteme aktualisiert werden sollten.

Teilweise SLES10/11  Uraltsysteme.   Dem Spacewalkserver mussten also heute neue Repositories bei gebogen werden.

Die Rettung in diesem speziellen Fall ist der spacecmd.

Wir legen also einen übergeordneten Software Channel an.


spacecmd {SSM:0}> softwarechannel_create sles11sp1

Channel Name: sless11sp1
Channel Label: sles11sp1
Base Channels
-------------
sles11sp2
sles11sp3
Select Parent [blank to create a base channel]:
Architecture
------------
i386-sun-solaris
ia32
ia64
ppc
sparc-sun-solaris
x86_64
Select: x86_64

Hiermit wird der übergeordnete Channel angelegt.

Wir  spendieren unserem sles11sp1 Channel jetzt noch Untergeordnete Channels wie Update, Base und was eben sonst noch so gebraucht wird.

spacecmd {SSM:0}> softwarechannel_create sles11sp1base

Channel Name: sles11sp1base
Channel Label: sless1sp1base
Base Channels
-------------
sles11sp1
sles11sp2
sles11sp3
Select Parent [blank to create a base channel]: sles11sp1
Architecture
------------
i386-sun-solaris
ia32
ia64
ppc
sparc-sun-solaris
x86_64
Select: x86_64

Im letzten Schritt dübeln wir unserem neu angelegten Vater und Sohn Channel noch ein Repository unter. Den ohne Repository auch keine Software im Channel. smile

spacecmd {SSM:0}> repo_create
Name: sles11sp1base
URL: https://whatever:youraccountis@nu.novell.com/repo/$RCE/SLES11-SP1-Pool/sle-11-x86_64/

Man will ja auch sehen ob alles richig gemacht wurde...
spacecmd {SSM:0}> repo_details sles11sp1base
Repository Label:   sles11sp1base
Repository URL:     https://whatever:youraccountis@nu.novell.com/repo/$RCE/SLES11-SP1-Pool/sle-11-x86_64/
Repository Type:    yum

Zu guter letzt dübeln wir das Repo endgültig unter den Softwarechannel..

spacecmd {SSM:0}> softwarechannel_addrepo sless1sp1base sles11sp1base

Bei der Systematik des addrepo Kommandos muss nur beachtet werden das zuerst Channel und dann Repo genannt werden.

Jetzt kann man lustig sein Repo aufsyncen und die Uralt Clients in den Spacewalk rein hängen. smile

CentOS 7 Network Manager und dhclient

los werden.

systemctl disable NetworkManager

yum remove dhclient-4.2.5-27.exl.centos.x86_64

CentOS hat ja durchaus seine Vorteile stabile Basis, reguläre Patche, und der Support eines großen Herstellers.

Seit dem Systemd Wahn ist das DIng so dermaßen buggy das man eigentlich nur noch den Schaden begrenzen kann, ich hatte es jetzt vermehrt bei Tests, wo eine statische IP mit dem  Parameter  NM_CONTROLLED="no" im ifcg_eth0  konfiguriert wurde,  das der dhclient oder möglicherweise der Network Manager selbst der Meinung waren dhcp Anfragen auf den nächstbesten DHCP Server zu schicken.

Das hat den unschönen Nebeneffekt das mal kurz das Gateway verbogen wird und der tolle Networkmanager  die /etc/resolv.conf umrprügelt.

Wer also wenigstens momentan, stabile statische Netzwerkconfigs hin dübeln will, ohne die Automagie von Systemd dem sei empfohlen den Kram abzuklemmen.

CentOS7 Textinstaller WTF

Wenn mir noch ein Linuxer erzählen will Solaris sei kryptisch und unkomfortabel, den lach ich geradewegs aus.

Der RHEL/Centos 7 Textinstaller vom Mini ISO ist ja wohl allerübelstes Frickelzeug!!!

Da konnte der CentOS6 Installer ja mehr und war bedienbar. Nein mich interessiert es nicht ob die einen neuen Installier in Python bauen mussten, wegen Systemd oder andren Hinrkrämpfen.

Nicht mal ein Softraid lässt sich mit dem Ding konfigurieren. Alter... Falter.. Spielzeug.Konfiguriert man das Softraid auf einer secondary shell manuell mit mdadm kommandos, raucht der Installer mit Python Meldungen ab.  Geschweige denn wenn man überhaupt per ALT F2 auf eine zweite Shell kommt und einem der logind nicht einen Strich durch die Rechnung macht. /dev/tty ja da war noch was… 

Sogar Debian oder SuSE Installer erlauben es ein Softraid zu konfigurieren... von dem haendischen Einpflegen der  REPO Urls in den Textinstaller will ich gar nicht anfangen... ein Armutszeugnis.

Per Kickstartskript geht's dann problemlos, aber über den Installier …. no fucking way…  wie kann man als selbsternannte Enterprise Company sowas in eine Enterprise Distri rein basteln????

Linux bleibt eben doch das pickelgesichtige Gymnasiasten OS und ist von echtem Enterprise ganz ganz weit weg.

Neue Wege im Job

Unlängst habe ich ja eine kostenlose Schulung für Projektkollegen zum Thema Linux allgemein gehalten.

Bei den Kollegen dieses Dienstleisters kam das wohl ganz gut an un dieser hat mich an einen anderen Kunden weiter "verhökert".

Letzte Woche hatte ich nun erstmals die  Gelegenheit, eine  Schulung vor zahlendem Publikum zu halten.

Thematischer Schwerpunkt der Schulung war der Betrieb von Debian Linux, mit Postfix und Apache. Interessant war aus meiner Sicht vor allem das die Admins des Kunden alle aus der Windowswelt kamen und von Linux oder anderen  Unixoiden bisher keinerlei Schimmer hatten.

Wirklich, das ist eine Herausforderung!

Insbesondere deswegen weil man Kollegen die Basics bei bringen muss die man selber eigentlich schon seit Ewigkeiten gefressen hat und man nicht mehr groß drüber nach denkt.

Man beginnt also mit der Erklärung wo kommt Linux her, was sind die Verwandten, stellt die wichtigsten Linuxdistributionen vor, insbesondere die im Enterprise Betrieb relevanten.

Weisst auf die Inkonsistenzen zwischen den Distributionen und auch innerhalb der Distributionen hin. Man geht auch auf das Thema Dokumentation und brauchbare Lektüre ein.

Auch wenn Debian jetzt das Hauptthema war, habe ich versucht die Schulung so gut wie möglich plattformübergreifend zu gestalten, damit der Schock nicht zu groß wird wenn im Datenbankbereich ein anders Unioxid einziehen sollte. Was ja gerade bei einem Einsatz von DB/2 oder Oracle RDBMS ziemlich wahrscheinlich ist.

Es war für mich eine echte Herausforderung mich in Anfänger hinein zu denken, ganz unten wieder zu beginnen und mir selbst im Vorfeld bei dem Zusammenstellen der Unterlagen Fragen zu stellen die für einen Anfänger wichtig sein könnten.

Angefangen beim Installieren, über Fehlersuche, wie grenze ich Fehler ein, wo suche ich die Fehler.

Wofür ist ein Paketmanager gut, was hat dieser für Funktionen, was kann ich damit anstellen.

Wie erkläre ich dem zahlenden Publikum das Linux nicht die Wale rettet nur weil es im Linuxmagazin stand?

Das auch das Thema Security bei Linux aktuell nicht  besser aus sieht wie beim Rest der Welt?

Auch Thematiken wie ich mir das Leben mit Skripten oder One Liner kam im Laufe der Zeit dran oder der Verweiss auf die  hohe Priorität ein funktionierendes Monitoring, insbesondere der Platten. smile

Schau mer mal ob da noch was nachkommt. smile

Mahatma Fatal Error die zweite mit GRUB2.

Nach vielem Rumgewürge.. sprich booten von Netinstall Images...

dem mehrfachen ausprobieren von Späßen wie dem hier..

 
mount /dev/md0 /mnt/ 
mount --bind /proc /mnt/proc
mount --bind /run /mnt/run
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
apt-get install --reinstall grub-pc dpkg-reconfigure grub-pc

Dem draufhämmern von Grub auf /dev/sda1 /dev/sdb uws... und so fort

Dem variieren der Vorgehensweise....

grub-mkdevicemap -n

update-grub

grub-install /dev/sda

grub-install /dev/sdb

Im übrigen gab es da keine Fehlermeldungen, für GRUB2 war alles "geil". 

und der wiederholten Message... beim Reboot.

Grub error: symbol not found: grub_divmod64_full

Komm ich leider zum Schluss..... Frickelscheiss ist eben doch Frickelscheiss.

Absolut nix gegen FOSS, ich bin ja selbst ein großer Anhänger von FOSS, aber solche Probleme einen Bootloader zu restaurieren hatte ich noch nie, bzw. ich kann mich nicht erinnern das ich mir jemals so einen Abgebrochen habe. Also das kann es echt nicht sein.

Immerhin funktioniert der Workaround, die Büchse vom USB Stick anzubooten und dann im Chroot,  die einzelnen Services wieder anzufahren.  Immerhin genug Zeit um sich mit einer richtigen Lösung zu beschäftigen.

Grub2 oder Mahatma Fatal Error am Karfreitag

Heute hab ich eine schon etwas angegraute Debian Squeeze Kiste, auf Wheezy hoch gezogen. Eigentlich kein großes Ding. 

Sources.list anpassen.

aptitude update

aptitude dist-upgrade

So der übliche Vorgang und bisher gab es da auch noch nie Schmerzen.. Nach dem Reboot hat mich allerdings folgende Message begrüßt.

Grub error: symbol not found: grub_divmod64_full

Haa da steht man doch drauf besonders am Karfreitag... Also Anbooten vom Netinstall Image... Reinstallation des GRUB, vom Netinstall Image auf /dev/md0 und auch auf Einzeldevices grandios gescheitert.... ha Super, da steh ich drauf.

Beim manuellen Hinmounten und ankucken des Grub Directories erst mal nahe am Herzinfarkt gewesen. Das Ding ist ja händisch fast nicht mehr zu administrieren, drei Millionen Configfiles kryptischer gehts kaum noch. In der Grub Konsole selber hat man so ziemlich alles geändert was mal funktioniert hat. Enorm hilfreich sowas. Das ist eben funktionierende SOftware! Die administriert sich von selbst.

mounten ins /chroot und händisch umbiegen... auch grandios gescheitert.  

Also noch mal von vorne....

mounten vom Netinstall.... Rescue Mode anschmeissen...

chrooten

ifconfig -a 192.168.x.x

route add default gw 192.168.x.x

ping heise.

mount /dev/pts  (sonst klappts nämlich nicht mit dem SSH )

/etc/initd.s/ssh start

Netz steht.... ab ins gemütliche Arbeitszimmer... den Keller rockt nicht.

grub-mkdevicemap -n

update-grub

grub-install /dev/sda grub-install /dev/sdb


Reboot....

Toll...

Grub error: symbol not found: grub_divmod64_full

Der Vollständigkeit halber......

cd /boot/grub

ls |wc -l

 194

194 Files im

/boot/grub...
wer denkt sich so eine beknackte Struktur eigentlich aus?

Ok Noch mal von vorne.... anbooten vom Netinstall... Prozedur kennen wir ja schon...

systemd aka crapware oder mounten war gestern

Meine Abneigung gegen System ist ja nichts grundsätzlich neues, da ich mir gestern im Büro ein Testsystem aufgesetzt habe, mit mehreren Platten drin hat sich bei der verwendeten SuSE ein interessanter Effekt eingestellt.

 

 Mar 24 15:01:28 installserver.site systemd[1]: Timed out waiting for device dev-mapper-vg_build\x2dsrc.device.
Mar 24 15:01:28 installserver.site systemd[1]: Dependency failed for /usr/src.
Mar 24 15:01:28 installserver.site systemd[1]: Dependency failed for Local File Systems.
Mar 24 15:01:28 installserver.site systemd[1]: Dependency failed for Remote File Systems (Pre).

 

Beim  Booten der Büchse ist beim Systemstart jedesmal der Device Mappe des LVM abgestorben. Im Redhat Bugtracker gibt's dazu auch ein Ticket.  Süss ist auch das da…. Im Archlinux Forum bin ich dann auf folgenden Workaround gestolpert.. 

Aber Leute ehrlich das kann es doch nicht sein. Der Dreck landet im kommenden RHEL 7 und im kommenden SLES…  diese SMF für Arme hat kein vernünftiges Loging der Services zumindest hab ich bisher keines gefunden.  

In der SMF krieg ich wenigstens Logs für jeden einzigen Service und wieso dieser fehlschlägt, bei Systemd fehlt das bisher völlig. Sowas soll in Enterprise Umgebungen einziehen?

Dont fuckin kiddin me... 

Erfahrungen eines Schulungswochenendes als Trainer

Am letzten Wochenende, habe ich meine erste Schulung gegeben. Training on the Job hab ich ja früher schon gemacht, aber als Teacher vor einer Gruppe zu stehen ist doch etwas neues. smile

Linux LVM Grundlagen und Verwendung der gängigen Packagemanager  yum, apt und zypper plus Zielrichtung Installation Legato Networker und Legato Clients für Nachwuchsadmins und Interessierte aus dem Netapp und Backuplager eines größeren Systemhauses.

Leider hab ich mich etwas bei der Zeit verschätzt und wir sind mit dem Themenblock nicht komplett durch gekommen.

Das ganze hat sehr viel Spass gemacht, insbesondere deswegen weil man mal wieder Wissen weiter geben konnte und es in diesem Fall auch auf fruchtbaren Boden gefallen ist.

Auch die Vorbereitung der Schulung war durchaus spannend. Das erstellen von Schulungsmaterial entbehrt nicht einer gewissen Mühe und das Konzept mit einer permanenten Schulungsumgebung, so das die Schulung auch am Stand X  weiter geführt werden kann fand ich durchaus gut.

Was ich bei meinen ersten Schritten als Teacher über mich selbst gelernt habe, ist das ich mittlerweile wohl zu viel voraussetze.  Es gibt eben doch noch Leute die beim Anlegen von Usern Hilfestellung brauchen und einem mal das Rootpassword unterm Hintern weg ziehen, weil der Teacher zu faul ist einzelne Kommandos zu verwenden sondern gleich mit Kommandosubstitution anfängt und useradd mit passwd kombiniert. wink

Aber Spass gemacht hat es auf jeden Fall, insbesondere die komplette Schulungsumgebung in KVM zu pressen war wirklich spannend. smile

Allerdings muss ich meine Schulungsunterlagen doch noch mal optimieren. cool


LVM Legastheniker at its Pest...

Beim hiesigen Kunden steht ja eine große Migration von SAP Systemen, Oracle und DB/2 Datenbanken von HP-UX. Solaris und AIX auf das Gespann Linux und Vmware an.

Die Migration läuft  verstärkt seit dem Frühjahr. Einige Projekte des Kunden sind zu Teilen schon migriert oder befinden sich auf dem besten Weg dorthin. Allerdings tun sich mittlerweile Abgründe auf wie das ganze Designed, oder eben nicht designed wurde.

Das fängt bei der ganz einfachen Geschichte an das man nicht verstanden hat, wofür ein Logical Volume Manager eigentlich da ist. Wir sind uns ja alle einig das ein LVM, sei das jetzt Veritas, Suns Sozialhilfe Volume Manager, oder HP-UX und LInux LVM den gleichen Zweck erfüllen.  Sie sind dazu da Platten zu verwalten mittels einer Abstraktionsschicht die nicht durch Partitions und Anzahl der Disken begrenzt ist. Soweit so gut, da gehen wir glaub ich alle d'accord. Oder?

Die großen Geister die hinter dieser Migration stehen und diese auch geplant haben, waren aber noch viel Genialer.....

Wir sind uns ja einig einen Platte ist eine physikalische Größe die vor allem durch Physik auch begrenzt wird. cool

Bei Vmare liegt ja noch zwischen der eigentlichen Pladde und dem virtualisierten Linux noch der Hypervisor dazwischen der einen Diskpool verwaltet, in dem Disken erzeugt werden die aber drunter auch noch eine Physik haben......

Der virtualisierte Gast, nimmt das was aus dem Pool des ESX kommt wiederum als Physik war. Soweit richtig? Der Vwmare Spezialist mag mich da gerne korrigieren.

Also ich hab erst einen Kuchen an Diskspace auf dem Storage und einen weiteren Kuchen an Diskspace in der Vmware Farm. Dieser wird dann wiederum aufgeteilt in kleine Bröckchen die an die Gäste weiter gereicht werden. Im Endeffekt hab ich im Gast keinerlei Ahnung wie sich das Ganze dann physikalisch wirklich zusammen setzt.

Das alles ist aber alles noch harmlos. Das allergrößte kommt nämlich jetzt..

Wie wir alle wissen.... kann ein Linux vier Primary Partitions verwalten.

Was haben die überlegenen Hirne der Designer dieses Setups also gemacht?

Man nehme die Disk aus dem Vmware Diskpool... mappe diese an die Vmware Gaeste.

|-------------------------------------------|    

|Plain Disk                                  |

|--------------------------------------------|

Im Linux selber wird die Platte dann genialerweise noch mal in vier Primary Partitions aufgeteilt. eek

|----------------------------------------------|

| |

| Pripar   |   Pripar      |    Pripar | Pripar|

| |
|----------------------------------------------|

Ja ihr bekommt auch schon das gruseln? wink

Recht so. laugh

Denn was machen die Idioten?

Entschuldigung für die Wortwahl, aber ich kann es nicht anders sagen....

Auf die Primary Partitions wird eigens eine Volume Group drauf geballert...

Es gibt also durchaus Setups wo mehrere Volume Groups auf einer Disk liegen.

Das sieht dann in etwa so aus....

--------------------------------------------

| Pripar1| Pripar2 | Pripar3| Pripar4 |

|vg_sap  |vg_oracle|vg_iwg |vg_bla |

| | | | |

-------------------------------------------

Da die Volume Groups in Partitions eingesperrt sind... hat das natürlich den offensichtlichen Nachteil das schon mal durch die Partition Grenzen setzt.

Die Vmware Jungens aber eher dazu tendieren eine bestehende  Disk zu extenden, als eine neue Disk anzulegen.  Das man unter den Volume Groups noch Logical Volumes anlegen kann .... und damit auch wesentlich flexibler als mit wildem rumgepartioniere agieren kann, kommt den Herren gar nicht in den Sinne... oder wird dann vom Linux Papageien der Designer als der einzig richtige Weg verkauft.

Das ganze Setup hat also schon den Geschmack der Fäulnis in sich, noch bevor es richtig belastet wird.

Das die ganze Idee wohl doch nicht ganz so brilliant und es ein Fehler war nicht die Leute zu fragen die wirklich was von Logical Volume Management verstehen zu fragen, tritt nun immer mehr  zutage.

Persönlich hätte ich das ja anders gemacht.

----------------------------------------------------

|  Disk                                                         |

----------------------------------------------------

pv auf die Disk

Volume Group angelegt.

Sagen wir mal... VG_SAP  oder VG_ORA je nach Einsatzzweck.

In der Volume Group selbst Logical Volumes angelegt. Beispielsweise so.

lvcreate sap_data oracle_logs  oracle_bin sap_bin  

Was man eben so braucht, das ganze mit XFS formatiert.

Dann hätte man sich den Scheiss nämlich gespart und sich gar nicht erst ins Knie geschossen. Das extenden von Disks seites Vmware und im virtualisierten Linux wäre damit nämlich kein Stress gewesen. 

echo 1 > /sys/block/sdirgendwas/device/rescan

partprobe
fdisk -l

pvscan

vgextend

lvextend

xfs_growfs /dev/ora_dg/whatever

------------------------------------------------------


Den Vmware Jungs scheint langsam aufzufallen das in den Gastsystemen was falsch läuft. Der Linuxpapagei und Jünger des Designer Teams... versucht das ganze noch mit Semantik zu kaschieren und den  Jungs von Software aus Polen die Schuld zu zuschieben.

O Ton mir Gegenüber... "Das ist die Vorgabe von Software aus Polen" ich kann mir nicht vorstellen das die kleine Butze in der unmittelbaren Nähe von Heidelberg solche schwachsinnigen Vorgaben macht.

Das mir diese Woche noch ein Angebot gemacht wurde, die hiesige  Umgebung ab März  zu betreuen, habe ich gleich  dankend abgelehnt, nicht mal für 120 Euro in der Stunde würde ich diesen Sumpf übernehmen.

Soviel Schmerzensgeld kann niemand bezahlen. Die Arme Sau die das übernimmt, wird ein verdammt beschissenes Jahr erleben. normal

Whackshit !!!!!

ep 13 12:05:45 appsrvbox kernel: [13048]    48 13048   116276
2142   0       0             0 httpd
Sep 13 12:05:45 appsrvbox kernel: Out of memory: Kill process 5649
(httpd) score 9 or sacrifice child
Sep 13 12:05:45 appsrvbox kernel: Killed process 12257, UID 5006,
(php-cgi) total-vm:321888kB, anon-rss:16132kB, file-rss:1368kB
Sep 13 12:05:45 appsrvbox kernel: suphp invoked oom-killer:
gfp_mask=0x280da, order=0, oom_adj=0, oom_score_adj=0
Sep 13 12:05:45 appsrvbox kernel: suphp cpuset=/ mems_allowed=0
Sep 13 12:05:45 appsrvbox kernel: Pid: 13045, comm: suphp Not tainted

Der Linux Kernel ist echt ein unglaublicher Optimist wenn es um seine murksige Scpeicherverwaltung geht...

Bevor mir die Testinstanz in der VM noch mal einfriert... der Kernel mit Amnesie im Wachkoma hängen bleibt, für eine Panic hats nämlich nicht mehr gereicht, willkommen in der Steinzeit.

greifen wir zur Holzhammermethode und begrenzen was er vergeben darf.

vi /etc/sysctl.conf

vm.overcommit_memory = 2

vm.overcommit_ratio = 80


sysctl -p