Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einführung
2 Virtuelle Maschinen im Unternehmen
3 Virtualisierungssoftware – eine Marktübersicht
4 Auswahl der möglichen virtuellen Maschine
5 Auswahl der richtigen Virtualisierungssoftware
6 Auswahl der richtigen physikalischen Infrastruktur
7 Installation und Update des Wirt-Systems
8 Verwaltung der Virtualisierungssoftware
9 Virtuelle Netzwerke
10 Virtuelle Festplatten
11 Erstellung einer virtuellen Maschine
12 Verwaltung der virtuellen Maschinen
13 VMware VirtualCenter
14 Skriptierung und Programmierung unter VMware und MS Virtual Server
15 Backup, Restore und Disaster Recovery
16 Templates (VM-Vorlagen)
17 Zusatzsoftware
18 Nützliche Adressen im Web
A Clustereinrichtung und Beispielumgebungen
B Kommandozeile und wichtige Dateien
C Häufige Fragen
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
VMware und Microsoft Virtual Server von Dennis Zimmer
Virtuelle Server im professionellen Einsatz
Buch: VMware und Microsoft Virtual Server

VMware und Microsoft Virtual Server
geb., mit CD
612 S., 49,90 Euro
Rheinwerk Computing
ISBN 978-3-89842-701-2
Pfeil 7 Installation und Update des Wirt-Systems
Pfeil 7.1 Vorbereitung
Pfeil 7.2 VMware GSX
Pfeil 7.2.1 Installation unter Microsoft Windows
Pfeil 7.2.2 Update Microsoft Windows
Pfeil 7.2.3 Deinstallation Microsoft Windows
Pfeil 7.2.4 Installation Linux
Pfeil 7.2.5 Update unter Linux
Pfeil 7.2.6 Deinstallation unter Linux
Pfeil 7.3 Microsoft Virtual Server
Pfeil 7.3.1 Installation
Pfeil 7.3.2 Update
Pfeil 7.4 VMware ESX
Pfeil 7.4.1 Installation
Pfeil 7.4.2 Update


Rheinwerk Computing - Zum Seitenanfang

7.4 VMware ESX Zur nächsten ÜberschriftZur vorigen Überschrift

Da VMware ESX auf einem RedHat-Linux basiert, sollte auch hier eine spezielle Partitionierung der Festplatten erfolgen. VMware ESX selbst bietet zwar schon eine automatische Partitionierung an, die jedoch entscheidend verbessert werden kann.


Tabelle 7.4 Partitionierung VMware ESX

Mountpoint Größe Dateisystem/Partitionstyp

/boot

100 MB

ext3/primär

/

500 MB

ext3/primär

/tmp

500 MB

ext3/extended

/var

1000 MB

ext3/extended

/usr

1500 MB

ext3/extended

/usr/local

100 MB

ext3/extended

/opt

350 MB

ext3/extended

swap

1000 MB

swap

/local

übriger Speicher minus vmcore und vmfs/swap

ext3/extended

vmcore

100 MB

vmcore dump wird später über die Webadministration angelegt, ist allerdings jetzt schon einzuplanen. Die Anlage ist jedoch auch ohne MUI über den Partitionierungsmanager bei der Installation möglich.

/vmfs/swap

gleiche Größe wie vorhandener physikalischer Hauptspeicher

VMware Swap wird für Memory Overcommitment verwendet und wird später über die Web-Administrationsoberfläche angelegt. Die Anlage ist jedoch auch ohne MUI

über den Partitionierungsmanager bei der Installation möglich.


Zusätzliche Festplatten bzw. LUNs werden normalerweise direkt mit dem VMFS-Dateisystem formatiert, damit sie für die virtuellen Maschinen benutzbar sind.


Rheinwerk Computing - Zum Seitenanfang

7.4.1 Installation Zur nächsten ÜberschriftZur vorigen Überschrift

Bei der Installation des ersten VMware ESX Servers, müssen Sie den Server komplett von Hand installieren, allerdings sind Sie nach dem Abschluss der Installation in der Lage, weitere VMware ESX Server über eine automatisierte Installationsroutine aufzusetzen. Näheres zum Thema automatisierte Installation finden Sie in Kapitel 8, Verwaltung der Virtualisierungssoftware, unter dem Stichwort VMware ESX Scripted Installation.

Vor der Installation des VMware ESX Servers sollten Sie, vorausgesetzt Sie wollen nicht vom SAN booten, alle vorhandenen FibreChannel-Anschlüsse abziehen, damit Sie nicht durch die womöglich vorhandenen LUNs unnötig durcheinander kommen. Des Weiteren sollten Sie sich noch dessen versichern, dass keine Hardware vorhanden ist, die vom VMware ESX Server nicht unterstützt wird. Da es auch für manche zertifizierte Serverhardware zu beachtende wichtige Informationen bzgl. der Installation gibt, ist auch ein Besuch der VMware-Webseite ratsam. Weiterer wichtiger Punkt sind die Netzwerkkarten, wobei mindestens eine Netzwerkkarte Pflicht ist, wohingegen bei der Verwendung von VMotion drei empfohlen werden.

Der für das Verständnis der Installationsfragen doch sehr wichtige Unterschied zwischen Service Console und VMkernel ist Ihnen zum jetzigen Zeitpunkt alles andere als klar. Um etwas Deutlichkeit in die Sache zu bringen, machen wir hier einen kurzen Exkurs, der nur die wichtigsten Grundlagen aufbereitet.

Service Console

Die Service Console stellt das eigentliche Wirt-Betriebssystem dar, das allerdings nicht vergleichbar mit einem normalen Betriebssystem wie Linux oder Windows ist, da es für den Betrieb des VMkernels und damit der Virtualisierungssoftware optimiert ist. Hier laufen aber alle »normalen« Betriebssystemprozesse wie zeitgesteuerte Skripte, Webserver und Backupprogramme ab.

  • Wirtbetriebssystem, in das der VMkernel sich später integriert
  • Bootmenü (Lilo)
  • Kommandozeile
  • Web-Administrationsoberfläche oder MUI
  • Authentifizierung für MUI oder Remote Console
  • Fernsteuerung der virtuellen Maschinen
  • Programmierschnittstelle und SNMP-Verwaltung
  • zeitgesteuerte Skripte
  • Drittanbietersoftware, beispielsweise Backup-Software
  • sonstige Software, z. B. vmkusage

VMkernel

Dies ist die eigentliche Virtualisierungs-Engine, die sich beim Hochfahren des VMware ESX Servers während des Startprozesses in die Service Console »einhängt« und unter anderem eine Hardwaretrennung zwischen Service Console und VMkernel vornimmt. Der VMkernel an sich benötigt momentan 24 MByte physikalischen Hauptspeicher. Er erfüllt die folgenden Aufgaben:

  • Steuerung der virtuellen Maschinen
  • Ressourcenkontrolle der virtuellen Maschinen
  • Zugriff auf das VMFS-Dateisystem
  • Verwaltung der virtuellen Festplatten
  • Verwaltung der virtuellen Netzwerke

Ich hoffe, der Unterschied, der doch für das Verständnis einiger der folgenden Installationsschritte sehr wichtig ist, ist nun ein wenig klarer geworden. Wenn nun alle Klarheiten beseitigt sind, können Sie die VMware ESX Server-CD ins Laufwerk des Wirt-Systems einlegen und von ihr booten.

Abbildung 7.20 Bootauswahlmenü des VMware ESX Servers

Wenn das Bootmenü erscheint, werden Ihnen erst einmal mehrere Bootoptionen (Abbildung 7.20) angezeigt:

  • default: Dies ist die normale Installationsroutine mit grafischer Oberfläche, die automatisch oder bei keiner Angabe aufgerufen wird.
  • noapic: Diese Auswahl deaktiviert APIC (Advanced Programmable Interrupt Controller). Für manche ältere Hardware oder wegen einer Empfehlung des VMware Supports empfiehlt sich diese Auswahl.
  • text: Bei dieser Auswahl wird keine grafische Oberfläche gestartet, was durch nicht unterstützte Grafikkarten oder Monitore notwendig werden kann.
  • driverdisk: Hier können Sie spezielle Treiber von VMware für neuere, noch nicht von der CD-Version unterstützte Geräte einbinden.
  • bootfromsan: Seit VMware ESX Version 2.5 existiert diese Auswahl, mit der Sie eine grafische Installation mit SAN-Unterstützung aufrufen können. Hier benötigen Sie keine lokalen Festplatten.
  • bootfromsan-text: Ebenfalls seit VMware ESX Version 2.5, können Sie hier mit SAN-Unterstützung im Textmodus installieren.

Da sich die grafische Oberfläche und der Text-Modus nicht sonderlich voneinander unterscheiden, der Text-Modus aber in jeglicher Konfiguration funktionieren sollte, gehe ich hauptsächlich auf letzteren ein. Dazu wählen Sie text für den Textmodus aus, und Linux wird von der CD geladen.

Falls nun Fehlermeldungen wie unknown PCI Device erscheinen, ist ein Gerät installiert, das nicht von VMware ESX unterstützt wird, d. h., Sie können dieses Gerät später nicht verwenden. Mit ein wenig Linux-Kenntnissen, was die Treiberverwaltung anbetrifft, könnten Sie dieses Gerät zu einem späteren Zeitpunkt möglicherweise manuell für die Service Console bereitstellen. Beim VMkernel und damit bei der Verwendung der virtuellen Netzwerke funktioniert das aber keinesfalls. Da eine solche Konstellation nicht von VMware unterstützt wird, ist ein Anpassen der Service Console um eigene Treiber nur für »Spielsysteme« angebracht. In produktiven Umgebungen sollten Sie keinesfalls Geräte ohne VMware-Unterstützung einsetzen, weil Sie damit ein unnötiges Risiko eingehen.

Abbildung 7.21 Hier wird eine AMD-Ethernetkarte nicht vom VMkernel, aber von der Service Console unterstützt. Daher kann sie später wenigstens zur Verwaltung des ESX Servers über die Service Console genutzt werden.

Eine weitere Fehlermeldung kann die Unterstützung der Hardware nur durch die Service Console anzeigen, die dann PCI Devices unusable by virtual machines lautet. Das stellt an sich kein wirkliches Problem dar, wenn es sich wirklich um das Gerät wie beispielsweise um eine Netzwerkkarte handelt, die Sie nicht für die virtuellen Netzwerke, sondern nur für die Service Console nutzen wollen.

Abbildung 7.22 Soll ein Standardinstallation, eine angepasste Installation oder eine Aktualisierung des bestehenden Systems durchgeführt werden?

Als nächster Schritt wird Ihnen, wie in Abbildung 7.21 zu sehen, angeboten, eine Standardinstallation (Default), eine angepasste (Custom) Installation oder ein Update des bestehenden System beispielsweise mit einem neuen Release durchzuführen. Die beiden folgenden Installationsschritte beziehen sich auf Tastaturbelegung und Mauskonfiguration (Abbildungen 7.22 und 7.23). Wenn Sie die deutsche Tastaturbelegung verwenden möchten, müssen Sie hier de oder de_latin auswählen, für eine amerikanische Tastatur us.

Abbildung 7.23 Auswahl der Tastaturkonfiguration, z. B. us (amerikanische Tastatur) oder de (deutsche Tastatur)

Die Mauskonfiguration bezieht sich nur auf die Installation und die spätere Service Console. Da Sie normalerweise später immer remote über SSH (z. B. Putty) oder die Web-Administrationsoberfläche zugreifen, ist diese Konfiguration nicht sonderlich wichtig. Sie ist es durchaus, falls später mittels KVM Switch auf den ESX Server zugegriffen wird, denn dann wäre eine funktionierende Maus schon sehr praktisch.

Abbildung 7.24 Auswahl des Mausmodells innerhalb der Service Console

Danach muss die EULA akzeptiert und die Lizenzschlüssel des VMware ESX Server und der Virtual SMP Unterstützung müssen eingegeben werden (Abbildung 7.24). Jedoch auch eine spätere Einrichtung der Lizenzinformationen über die Webadministration ist problemlos möglich. Neu angelegte oder bereits vorhande virtuelle Maschinen lassen sich allerdings bis zur korrekten Eingabe der ESX Server-Lizenz nicht starten. Falls Sie über eine zeitlich begrenzte Lizenz verfügen, werden die virtuellen Maschinen nach Ablauf des Zeitraumes in den Suspend-Modus geschaltet und können erst nach Eingabe einer gültigen Lizenz wieder gestartet werden.

Abbildung 7.25 Eingabemaske für die Lizenzschlüssel des ESX Servers und der Virtual SMP-Funktion

Jetzt ist die Zuordnung der Massenspeicher-Adapter zu treffen. Zur Auswahl stehen, wie nicht anders zu erwarten, die Service Console und der VMkernel, aber auch eine Mischumgebung, die Shared genannt wird und beiden Kandidaten den Zugriff gewährt. In Abbildung 7.26 sehen Sie beispielsweise einen Adaptec 2940 SCSI-Adapter, der zwar sowohl der Service Console als auch dem VMkernel zugewiesen ist, bei dem aber trotzdem zwei Treiber mit verschiedenen Zuordnungen aufgelistet sind.

Abbildung 7.26 Zuordnung des/der Massenspeicher-Adapter für Service Console oder virtuelle Maschinen

Begründen kann man dies, da der VMkernel eigene Kernelmodule, also Treiber mitbringt und lädt, die von der Service Console nicht verwendet werden können. Deshalb wird der Treiber aic7xxx.o (Adaptec Treiber), nochmals getrennt aufgeführt und auch vom VMkernel exklusiv geladen. So können trotz zweifacher Auflistung des gleichen Adapters mit unterschiedlichen Treibern und unterschiedlicher Zuordnung Shared und VMkernel auf die angeschlossenen Controller mit den Festplatten zugreifen.

Abbildung 7.27 Zuordnung der Netzwerkkarten

Im nächsten Schritt der Installation wird die Zuordnung der physikalischen Netzwerkkarten des Wirt-Systems eingerichtet. Beispielsweise sind im Wirt-System (Abbildung 7.27) zwei Netzwerkkarten eingebaut, nämlich eine 3Com 3cSOHO100 und eine 3Com 3c905C. Erstere wird hier der Service Console zugeordnet (da für diese Netzwerkkarte nur ein Treiber der Service Console verfügbar ist, kann sie auch nicht den virtuellen Maschinen zugeordnet werden), die zweite Netzwerkkarte ist ausschließlich den virtuellen Maschinen zugeordnet. Später werden Sie alle Netzwerkkarten, die den virtuellen Maschinen zugeordnet sind, nicht in der Netzwerkauflistung der Service Console finden und auch nicht ansprechen können.

Normalerweise wird hier eine Netzwerkkarte der Service Console und alle weiteren werden dem VMkernel zugeordnet. Falls Ihnen nur eine Netzwerkkarte zur Verfügung steht, müssen Sie diese hier als Shared konfigurieren, damit sowohl Service Console als auch VMkernel darauf zugreifen können. Falls Sie sich bei den Zuordnungen der Geräte unsicher sind, kann ich Sie beruhigen, denn die Zuordnung kann auch nach der Installation neu konfiguriert bzw. angepasst werden. Dies gilt auch für alle weiteren Einstellungen, ausgenommen bestimmte Teile der Partitionierung wie beispielsweise der Bootpartition. Dieser Teil der Installation sieht in der grafischen Installationsroutine ein wenig anders aus. Es sind nämlich mehrere Installationsschritte zu einem Dialog zusammengefasst, wie man in Abbildung 7.28 sieht. Hier sehen Sie besser als in der Textversion die Möglichkeit des Teilens zwischen VMkernel und Service Console, das einfach durch Aktivieren der Shared with Service Console- Funktion geschieht.

Abbildung 7.28 Die Gerätezuordnung über die grafische Installationsoberfläche

Die nächste Frage bei der Textinstallation behandelt den zugeordneten Hauptspeicher der Service Console. Da er direkt mit der Anzahl der gleichzeitig lauffähigen virtuellen Maschinen auf einem System zusammenhängt, sollten Sie sich schon vorher über einen entsprechenden Puffer im physikalischen Hauptspeicher Gedanken gemacht haben. Wie Sie Tabelle 7.5 entnehmen können, würden Sie bei 10 virtuellen Maschinen 272 MB physikalischen Hauptspeicher für die Service Console benötigen.


Tabelle 7.5 Benötigter Hauptspeicher der Service Console

RAM Service Console virtuelle Maschinen

192 MB

bis zu 8 virtuelle Maschinen

272 MB

bis zu 16 virtuelle Maschinen

384 MB

bis zu 32 virtuelle Maschinen

512 MB

mehr als 32 virtuelle Maschinen

800 MB

maximal verwaltbarer RAM


Nun wird es ernst, steht doch die Partitionierung der Festplatte an, die Sie entweder manuell oder automatisch durchführen können. Eine Empfehlung meinerseits finden Sie in Tabelle 7.4, die allerdings an Ihre Umgebung, also Ihre lokalen Festplatten anzupassen ist.

Abbildung 7.29 Soll die Partitionierung der Festplatte automatisch oder manuell passieren?

Wenn Sie innerhalb des Partitionierungs-Setups sind, können Sie über den Button New eine neue Partition anlegen. Diese Partitionen werden immer hinter den schon bestehenden angelegt. Innerhalb des dann erscheinenden Add Partition-Fensters, können Sie sich den Mountpoint und das Dateisystem aussuchen sowie die Größe (Abbildung 7.30) der Partition festlegen. Wichtig ist die Auswahl Force to be a primary Partition, die Sie nur auswählen sollten, wenn Sie eine primäre Partition anlegen wollen. Ansonsten wird automatisch eine Extended-Partition erstellt.

Abbildung 7.30 Anlage einer neuen Partition

Als Nächstes steht die Netzwerkkonfiguration der Service Console auf dem Programm. Hier sind Rechnername, IP-Adresse, Gateway und DNS Server anzugeben. DHCP sollten Sie nur verwenden, falls Sie mit DHCP-Reservierungen arbeiten, weil dynamische IP-Adressen bei Servern nicht sehr sinnvoll sind. Fest vergebene IP-Adressen sind natürlich der empfohlene Weg, da es ansonsten bei einem längeren Ausfall des DHCP-Servers zu Problemen kommt.

Abbildung 7.31 Netzwerkeinstellungen der Service Console. Über diese Netzwerkadresse läuft später die Verwaltung des ESX Servers (SSH und Webadministration)

Danach wird nach der Zeitzone gefragt, die in unseren Breiten meist Europe/Berlin ist. Normalerweise können Sie Hardware Clock set to GMT ausgewählen, was die CMOS-Uhr auf GMT (Greenwich Mean Time) setzt.

Nun müssen Sie ein Root-Passwort eingeben, das aus mindestens 6 Zeichen bestehen muss. Da diesem Root-Benutzer eine Art Allmacht auf dem System eingeräumt wird und er über entsprechende Rechte verfügt, sollten Sie das Passwort jedoch deutlich komplexer wählen. Später melden Sie sich auch mit dem Benutzernamen root und dem von Ihnen vergebenen Kennwort an der Kommandozeile und der MUI an.

Da Sie nicht immer mit den vollen Rechten arbeiten müssen, empfiehlt es sich, im nächsten Installationsschritt auch einen normalen Benutzer anzulegen, wobei auch hier die Kennwortlänge von 6 Zeichen gilt. Nach einer Meldung, die auf das Installationsprotokoll unter /tmp/install.log hinweist, beginnt die eigentliche Installation. Sollte jetzt ein Abbruch erfolgen, liegt es mit ziemlicher Sicherheit an der Serverhardware.

Wenige Minuten später sollte die Abschlussmeldung der Installation erscheinen und ein Reboot des Servers sich anschließen. Wenn Sie den Systemstart im Auge behalten, wird Ihnen mit ziemlicher Sicherheit eine lange Ladezeit des VMkernels auffallen. Dies ist absolut normal, da es einige Zeit in Anspruch nimmt, diesen VMkernel zu laden und zu aktivieren. Falls Sie später einmal einen Neustart aus der Ferne anstoßen und auf den Server pingen, wird der Server nach einiger Zeit kurz antworten, danach aber wieder verstummen, bis er dann komplett hochgefahren ist. Dies hängt mit dem Laden des VMkernels zusammen, der ja mit der Hardwaretrennung zwischen VMkernel und Service Console beschäftigt ist.

Von jetzt an können Sie sich an der MUI anmelden und von dort aus die restlichen Schritte konfigurieren. Dies wären VMCore Dump (falls Sie diese nicht schon bei der Partitionierung anlegt haben), VMkernel Swap (wird nur bei Memory Overcommitment benötigt) und eine virtuelles Netzwerk. Wie Sie diese Dinge genau anlegen, können Sie in den entsprechenden Kapiteln dieses Buches nachlesen.

Vmkusage

Ein Tool, das Sie direkt nach der Installation des VMware ESX Servers installieren sollten, nennt sich vmkusage. Dieses Tool ermittelt auf der Basis des rrdtool alle 5 Minuten verschiedene Auslastungsdaten des ESX Servers und der laufenden virtuellen Maschinen. Diese Auswertung wird Ihnen über die URL http oder https://ESXServer/vmkusage bereitgestellt. Die Leistungsdaten können Sie nach Zeitraum (Aktuell, Tage, Woche) und nach verschiedensten Kriterien einsehen (Netzwerk, Massenspeicher, Prozessor, Hauptspeicher etc.).

Abbildung 7.32 Ansicht der Vmkusage-Webseite, auf der Ihnen die Leistungsdaten aller VMs und des Wirt-Systems bereitgestellt werden.


Rheinwerk Computing - Zum Seitenanfang

7.4.2 Update topZur vorigen Überschrift

Ein Update ist quasi eine »Komplettinstallation« von VMware ESX. Aber so ganz komplett ist sie dennoch nicht, da sämtliche Konfigurationsanpassungen unberührt bleiben. Ebenso wie bei VMware GSX ändern sich auch hier bei jedem Update die VMware Tools und sollten zeitnah auf den virtuellen Maschinen eingespielt werden. Eine Lauffähigkeit ist aber auch mit einer alten VMware Tools-Version gewährleistet, sofern Sie nicht allzu weit zurückliegt. Das Update selbst können Sie recht einfach über die VMware ESX-CD mit der aktuellsten Version einspielen. Dazu muss einfach von dieser CD gebootet und nach der Auswahl der Installationsart (Text, Grafische Oberfläche, siehe Abbildung 7.20), Upgrade existing System gestartet werden.

Falls das Update nicht über CD, sondern über eine Installationsdatei geschehen soll, müssen Sie den ESX Server im Linux-Modus booten. Das heißt, der VMKernel wird nicht mitgestartet. Ein Problem stellt sich ein, wenn Sie das Update aus der Ferne anstoßen wollen und nur über SSH (Secure Shell) auf das System gelangen.


TIPP
Geben Sie einfach auf der Kommandozeile /sbin/lilo –R linux ein, um den Boot-Modus auf Linux umzustellen. Danach müssen Sie das System über /sbin/reboot nur neu starten, um in den Linux-Modus zu gelangen. Sobald das System wieder läuft, können Sie das Update einspielen, und beim nächsten Neustart (wird aus dem Upgrade-Skript abgefragt) ist wieder alles wie gewohnt.

Beim Einsatz von Aufrufen innerhalb der /etc/inittab z. B. durch Backupclients, ist darauf zu achten, sie vor jedem Update zu sichern, da die Datei immer durch den Update-Prozess wieder in ihren Originalzustand zurückversetzt wird.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Vmware und Microsoft Virtual Server
Vmware und Microsoft Virtual Server


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchtipps
Zum Rheinwerk-Shop: Vmware vSphere 5.5






 Vmware vSphere 5.5


Zum Rheinwerk-Shop: Vmware vSphere 5.5






 Vmware vSphere 5.5


Zum Rheinwerk-Shop: Vmware View






 Vmware View


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Office 365






 Office 365


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern