Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

Server2,HW-Upgrade,VI-Client,supp.Host-OS,Permission,Optimum

Hilfe bei Problemen mit der Installation oder Benutzung des VMware Server 2.

Moderatoren: irix, continuum, Dayworker, Tschoergez

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Server2,HW-Upgrade,VI-Client,supp.Host-OS,Permission,Optimum

Beitragvon Dayworker » 19.10.2008, 17:43

Normalerweise ist das Upgraden der Hardware einer VM ja kein Problem, solange man nicht den VMServer2 verwendet.
Hier haben sich die Programmierer wohl extrem vertan, denn nach einem Upgrade kann man die Rekonfiguration dieser VM über den mitgeliefertem VI-Client vergessen. Es ändern sich eigentlich nur die "virtualHW.version" und die "ddb.virtualHWVersion" von "4" auf "7" und fortan bricht der VI-Client jede Änderung mit einer Meldung ab:

Code: Alles auswählen

Die Einstellungen für diese virtuelle Maschine (Name der VM) können nicht bearbeitet werden. Die Hardwareversion für diese virtuelle Maschine ist nicht mit dieser Version des VI-Clients kompatibel.
Zum Rekonfigurieren der VMs müssen Sie entweder die Webschnittstelle des Hosts oder eine Version des VI-Clients verwenden, die mit der Hardwareversion der VM kompatibel ist.


Fairer Weise muß man sagen, daß es vorher eine Warnung gibt und man diese auch verinnerlichen sollte und sich die Konsequenzen genau durchdenken sollte:

Code: Alles auswählen

Warnung: Inkompatible VM-Hardwareversion ermittelt.

Wenn sie das Upgrade fortsetzen, werden die VMs automatisch auf die höchste VM-hardwareversion aktualisiert, die von den jeweiligen Hosts unterstützt wird.

Diese Version des VI-Clients (Virtual Infrastructure) unterstützt lediglich die folgenden Versionen: Hardwareversion 4

Wenn die Hardwareversion einer VM höher ist als die vom VI-Client unterstützte Hardwareversion, kann die VM möglicherweise nicht über den VI-Client neu konfiguriert werden.

Das Upgrade der VM-Hardware kann nicht rückgängig gemacht werden.

Um die VMs nach dem Upgrade neu zu konfigurieren, muß die Webschnittstelle des Hosts oder eine Version des VI-Clients verwendet werden, die mit der Hardwareversion des Hosts kompatibel ist

Möchten Sie das Upgrade der VM-Hardware fortsetzen?


Das Upgrade selbst läuft dabei anscheinend in 2 Schritten ab und verewigt sich mit 3 Meldungen im Ereignislog zu dieser VM:

Code: Alles auswählen

Upgrading virtual hardware to version vmx-06
Message from (Hostname): You have successfully upgrade your virtual maschine.
Virtual hardware upgraded to version vmx-07


PS: Vielleicht haben die Entwickler den VI-Client deshalb auch so gut versteckt, um seine Schwächen zu kaschieren. Zumindest habe ich keinen Weg gefunden, diesen einfach per Link vom Web-Interface zu beziehen...



Änderungsliste:
[edit_11-02-09]
Titel geändert von VMserver2 final und das Hardware-Upgrade

[edit_29-04-09]
unterstützte Host-OS für Linux und Windows hinzugefügt
Titel geändert

[edit_22-06-09]
Permissions/Berechtigungen hinzugefügt
Titel geändert

[edit_23-06-09]
Postingüberschriften eingerichtet, Physik. Disk-Access hinzugefügt

[edit_25-06-09]
Versuch der optimalen Host-Config

[edit_28-06-09]
Beobachtungen bei 2 v.CPUs in einer VM

[edit_14-09-09]
Kopieren einer Windows-VM

[edit_20-09-09]
Tastatur-Probleme in den Gästen auf Linux-Hosts

[edit_27-10-09]
Änderungen in V2.0.2

[edit_14-11-09]
Vi-Client der Version 2.00

[edit_15-11-09]
Schnellverwaltung des VMserver2 von der CMD oder Ba$h aus

[edit_04-08-10]
VMware-Server End Of Availability on January 2010

[edit_23-09-12]
Zwang zu SSL und Weiterleitung auf Port 8333 abschalten

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Upgrading oder vielmehr Downgrading zur Version 2.0.x ;)

Beitragvon Dayworker » 01.11.2008, 14:43

Upgrading from VMware Server 1

Run the VMware Server 2 installer for your host to upgrade to VMware Server 2 from
VMware Server 1. The installer automatically uninstalls the previous version of the
software, except for tar installations, which require you to uninstall the previous
version of VMware Server manually as described in “Uninstalling a tar Installation of
VMware Server” on page 43.

There are some feature differences between these product versions:

- VI Web Access and VMware Remote Console replace the VMware Management Interface and VMware Server Console. See Chapter 3,
“Learning VMware Server Basics: Using VI Web Access,” on page 47.

- VMware Server 2 does not support physical (raw) disks.

- VMware Server 2 uses datastores to manage virtual machine locations. A datastore
is a storage location for VMware Server virtual machine files. The storage location
can be the local file system, a CIFS store (Windows only), or an NFS‐mounted file
system (Linux only).

Virtual machines that were registered in VMware Server 1 are automatically
registered in VMware Server 2. However, the locations for existing virtual
machines are not automatically added as datastores. It is recommended that you
add them manually. See “Managing Datastores” on page 110.

- VMware Server 2 creates hardware version 7 virtual machines by default. If you
want to use all features of VMware Server 2, it is recommended that you upgrade
virtual machines to hardware version 7.

You can import hardware version 3 and above virtual machines. However, the only
tasks VI Web Access can perform on hardware version 3 virtual machines are
power operations and upgrade. To upgrade the hardware version of older virtual
machines, see “Upgrading the Virtual Machine Version” on page 72.

- VMware Server 2 uses a different permissions model from VMware Server 1. After
you install VMware Server 2, log in as an administrator user to create and manage
permissions for non‐administrator users. See Chapter 10, “Managing Roles and
Permissions,” on page 201.

- VMware Server 2 automatically names both default and custom virtual networks.

The Networks section of the VI Web Access host Summary tab shows the name,
virtual network (VMnet), and network type of each virtual network. If you
customize virtual networking after installation, you must refresh the network, as
described in “Changing the Networking Configuration” on page 222.

For upgrades from VMware Server 1, if you bridged (mapped) virtual networks to
specific physical or virtual adapters, write down the settings you used.

Although VMware Server 2 generally preserves network settings during the
upgrade, it cannot preserve bridged settings created with VMware Server 1.

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Änderungen in V2.0.1

Beitragvon Dayworker » 04.04.2009, 15:56

Was hat sich geändert?
  • Das neue Version 2.0.1 ist offiziell am 31.03.09 freigegeben worden und trägt an meinem Download-Tag den 03.04.09 die Buildnummer 156745. Ich schreibe das so ausführlich, weil VMware den Server2.0.0 ohne Kommentar oder Releaseänderung auf einen anderen Download mit höherer Buildnummer gemappt hat. Die Buildnummer hat damit einen gewaltigen Sprung von der 122956 gemacht.
  • Zuerst einmal verbleiben bei der Deinst, unabhängig von der Beantwortung der VMserver-Nachfrage zur Serien-Nummer für eine erneute Inst, einer Version 2.0.1 jede Menge Dateien und Einstellungen im System. Eine manuelle Nacharbeit oder auch das im WS-Bereich verlinkte Tool von VMware scheinen dringendst angebracht.
  • Von der Optik an sich hat sich nichts verändert. Die Fehlermeldung über das ungültige Zertifikat ist logischer Weise geblieben, wie auch der zumindest unter W2k erfolglose Start der Dienste "VMware Authorization Service" und "Vmware Host Agent". Der Umweg unter W2k über "net start Dienst" als CMD ist geblieben, aber startet jetzt wesentlich schneller trotz unverändertem Host.
  • Der VI-Client wurde bis jetzt ersatzlos bei Linux32/64 und Windows gestrichen. Zumindest fand ich keine Datei mit dem Namen "VMware-viclient.exe". Er funktioniert aber immer noch ;) mit den bekannten Einschränkungen :cry:
    Vielleicht kann der beim "ESXi 3.5U4" mitgelieferte ja mehr und müßte mal ausprobiert werden.
  • Das "VMware Remote Console Plug-in" trägt auch die gleiche Versionsnummer 2.5.0.122581 wie schon bei Version 2.0.0.
  • Die VM-Tools tragen anstatt der 7396 jetzt die 7397 und brauchen laut einer Linux-VM nicht erneuert zu werden. :cool: Ich werds dennoch machen, vielleicht wurden ja endlich die Fehlermeldungen zum "HGFS" beseitigt.
  • Unter Linux wird auch eine Darwin.iso mitgeliefert und bietet damit wahrscheinlich auch die Möglichkeit "MacOS X" mit den VM-Tools zu beglücken. [edit]Kann ich mangels Linux-Host und MacOS nicht überprüfen, aber die Hoffnung geht zuletzt über Board :lol: [/edit]
  • neue Gäste wurden ebenso freigegeben:
      Support for New Guest Operating Systems
      VMware provides support for the following operating systems for Server 2.0.1:

    • Asianux Server 3.0 Service Pack 1
    • CentoOS 4.7
    • CentOS 5.2
    • Windows Essential Business Server (EBS) and Small Business Server (SBS) 2008
    • Windows Small Business Server 2003 Service Pack 2
    • Windows XP Service Pack 3
    • Windows Vista Service Pack 1


Die vollständigen Release-Notes finden sich unter http://www.vmware.com/support/server2/d ... er201.html und sind umfangreich.

Hier die einzelnen Dateigrößen und Beschreibungen im Überblick:

For Windows
VMware Server 2

Version 2.0.1 | 156745 - 03/31/09 507 MB EXE image VMware Server 2 for Windows Operating Systems. A master installer file containing all Windows components of VMware Server.
md5sum: d0eefaa79e42d13a693c4d732a460ba4(¹)

VIX API 1.6 for Windows.
Version 1.6.2 | 156745 - 03/31/09 37 MB EXE image
md5sum: ad531ed3c37c0a50fb915981f83ca133(¹)

For Linux
VMware Server 2 for Linux Operating Systems.
Version 2.0.1 | 156745 - 03/31/09 465 MB RPM image
md5sum: eb42331bbd9be30848826b8cab73e0ca(¹)

VMware Server 2 for Linux Operating Systems.
Version 2.0.1 | 156745 - 03/31/09 466 MB TAR image
md5sum: be96bc1696f4cef67755bfd2553ce233(¹)

VMware Server 2 for Linux Operating Systems 64-bit version.
Version 2.0.1 | 156745 - 03/31/09 434 MB RPM image
md5sum: 697a792c70d50e98a347c06b323bd20b(¹)

The core application needed to run VMware Server 2, 64-bit version.
Version 2.0.1 | 156745 - 03/31/09 436 MB TAR image
md5sum: f40498229772910d6a6788b7803f9c38(¹)

VIX API 1.6 for Linux.
Version 1.6.2 | 156745 - 03/31/09 17 MB TAR image
md5sum: 2ef6174b90cdd9a2832b57dbe94cfbb1(¹)

64-bit VIX API 1.6 for Linux.
Version 1.6.2 | 156745 - 03/31/09 21 MB TAR image
md5sum: 454aeba273f9a89c578223c95b262323(¹)

Benutzeravatar
Experte
Beiträge: 1519
Registriert: 25.04.2005, 17:20
Wohnort: Wiesbaden

Beitragvon McStarfighter » 04.04.2009, 21:36

Das mit der darwin.iso und dem Support für Mac OS X würde ich nicht unterschreiben. Darwin selbt wird wohl damit astrein gehen, aber für OS X müßten die VMware Tools für die Aqua-Oberfläche angepaßt werden. Und die ist was apple-eigenes, ohne freien Code ...

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 19.04.2009, 17:33

Der VI-Client wird ja nun nicht mehr mitgeliefert und ich glaube auch, dass das so bleiben wird. Damit gibt es nur noch ein Programm zur Verwaltung, dass leider nicht alle Übersichten des VI-Clients bietet.
Falls der VI-Client unter Windows dennoch genutzt werden soll, bleibt nur der Download der älteren Version 2.00 und dort den VI-Client zu entpacken. Am einfachsten dürfte das noch mit der Linux-Version *.tar.gz" klappen. Die Datei findet sich unter ./vmware-server-distrib/lib/hostd/docroot/client und läßt sich mit WinZIP, WinRAR oder auch 7Zip unter Windows problemlos entpacken, Linux hat ein geeignetes Programm sowieso an Board. 8)

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

offiziell unterstützte Host-OS

Beitragvon Dayworker » 29.04.2009, 18:00

Hier mal die offiziell von VMware unterstützten Host-OS

Windows 64‐bit host computers can run the following operating systems for 64‐bit extended systems:
  • Windows Server 2008 x64 Standard Edition
  • Windows Server 2008 x64 Enterprise Edition
    NOTE: Windows 2008 Server Core installations are not supported.
  • Windows Server 2003 x64 Standard Edition, SP1, SP2, R2
  • Windows Server 2003 x64 Web Edition, SP1, SP2
  • Windows Server 2003 x64 Enterprise Edition, SP1, SP2, R2

Windows 32‐bit host computers can run the following operating systems:
  • Windows Server 2008 Standard Edition
  • Windows Server 2008 Enterprise Edition
    NOTE: Windows 2008 Server Core installations are not supported.
  • Windows Server 2003 Standard Edition, SP1, SP2, R2
  • Windows Server 2003 Web Edition, SP1, SP2
  • Windows Server 2003 Enterprise Edition, SP1, SP2, R2
  • Windows Small Business Server 2003 Standard Edition, R2
  • Windows Small Business Server 2003 Premium Edition, R2
  • Windows 2000 Server SP3, SP4
  • Windows 2000 Advanced Server, SP3, SP4

Linux 64‐bit host computers can run the following operating systems for 64‐bit extended systems:
  • Mandriva Corporate Server 4
  • Red Hat Enterprise Linux 5.1
  • Red Hat Enterprise Linux 5.0
  • Red Hat Enterprise Linux AS 4.5
  • Red Hat Enterprise Linux ES 4.5
  • Red Hat Enterprise Linux WS 4.5
  • SUSE Linux Enterprise Server 10.1
  • SUSE Linux Enterprise Server 10 SP1
  • SUSE Linux Enterprise Server 10
  • SUSE Linux Enterprise Server 9 SP4
  • Ubuntu Linux 8.04
  • Ubuntu Linux 7.10
  • Ubuntu Linux 7.04
  • Ubuntu Linux 6.10
  • Ubuntu Linux 6.06

Linux 32‐bit host computers can run the following operating systems:
  • Mandrake Linux 10.1
  • Mandriva Corporate Server 4
  • Red Hat Enterprise Linux 5.1
  • Red Hat Enterprise Linux 5.0
  • Red Hat Enterprise Linux AS 4.5
  • Red Hat Enterprise Linux ES 4.5
  • Red Hat Enterprise Linux WS 4.5
  • SUSE Linux Enterprise Server 10.1
  • SUSE Linux Enterprise Server 10 SP1
  • SUSE Linux Enterprise Server 10
  • SUSE Linux Enterprise Server 9 SP4
  • TurboLinux Enterprise Server 10
  • Ubuntu Linux 8.04
  • Ubuntu Linux 7.10
  • Ubuntu Linux 7.04
  • Ubuntu Linux 6.10
  • Ubuntu Linux 6.06

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 31.05.2009, 20:07

Wie ich grad rausgefunden habe, kann man zur Verwaltung des VMserver2 auch den VI-Client aus dem ESXi-3.5.0-U3 (VMware-VMvisor-InstallerCD-3.5.0_Update_3-123629.i386.iso) mit der Buildnummer 119801 nehmen.

Meine Versuche mit dem ESXi-4.0.0 (VMware-VMvisor-Installer-4.0.0-164009.x86_64.iso) sind bisher leider nicht von Erfolg gekrönt, ich scheitere momentan nur an zuwenig Arbeitsspeicher auf dem Host. Der ESXi-4.00 will definitiv 2048MB an Arbeitsspeicher haben oder er zeigt seinen Pink-Screen...
Bild

Also ich habe mir jetzt mal das "VMware vSphere Client and Host Update Utility" des ESXi4U1 von knapp 112MB runtergeladen, dazu muß man lediglich bei VMware schon registriert sein.
Allerdings lassen sich damit noch immer keine VMs mit v.HW-Version 7 bearbeiten. Bild

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 05.06.2009, 21:17

Der ESXi-4 läuft zwar unter VMserver2.01 als Gast, jedoch provozieren alle innerhalb des ESXi-4 installierten VMs einen Reboot des selben. Damit läßt sich natürlich nicht arbeiten oder testen. Für weiteres ist der Fred ESX 4.0 in VM - Reboot beim Start einer VM lesenswert. Er bietet auch eine Antwort per Verlinkung ins offizielle VMware-Forum.

Falls da jemand noch eine Version 2.00 am laufen hätte, würde dieser jemand bitte mal den ESXi4 ausprobieren. 8)

Die dafür passende *.vmx gibts über den Fred Wichtig: ESXi 4 in Workstation 6.5.2 von Ulli. ;)

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Remote-Consolen-Plugin

Beitragvon Dayworker » 14.06.2009, 16:57

Das Remote-Plugin scheint öfter mal Probleme zu machen, meist hilft unter Windows dann ein anderer Browser (IE7 oder FF3). Falls beides nichts bringt, läßt es sich wieder über einen Restart der VMware-Dienste gefügig machen und manchmal hilft garnix. Dann scheint meist ein Deinstall des Plugins, gefolgt von einem kompletten Reboot und anschließendem Reinstall die größte Chance auf Lösung zu bringen.

Falls es aber mal zu Performanceproblemen bei Grafiksachen, wie Fenster-Öffnen/-Verschieben, in einer Windows-VM kommen sollte, lautet die Empfehlung die HW-Beschleunigung in den erweiterten Anzeigeeinstellungen der VM zu aktivieren oder damit zu experimentieren. Damit lassen sich keine Wunder bewirken, 3D bleibt deaktiv, aber manchmal ist ein langsamer Cursor besser als ein ruckelnder. ;)

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Permissions/Berechtigungen setzen

Beitragvon Dayworker » 22.06.2009, 22:41

Die Sache mit den Permissions/Berechtigungen für den Zugriff auf den VMserver2 ist anscheinend doch nicht so einfach, wie das Handbuch meint. Falls jemand in die Verlegenheit kommen sollte, hier mal eine kleine Anleitung.

Es gibt die 3 Voreinstellungen "No Access", "Read-Only" und "Admin". Diese lassen sich auch abändern oder klonen. Ich würde zur eigenen Sicherheit immer eine Voreinstellung klonen und dann entsprechend abändern, wer weiß wofür man das Original mal braucht. Dabei achtet der Server2 auch strikt darauf, mindestens einen Benutzer zu haben, der alle Berechtigungen hat. In Voreinstellung haben bei Windows nur Benutzer der Host-Gruppe "Admin/Administratoren" und bei Linux der bei der Inst angegeben Benutzer (kann auch jemand anders als der SU "root" sein) die Berechtigung für alle Einstellungen und VMs.
Ansonsten benötigt man 2 Schritte und wenn man das Anlegen von Host-Benutzern/-Gruppen mitrechnet sogar 3.
  1. Benutzer/Gruppe im Host-System anlegen
  2. "Administration" -> "Manage Roles": Berechtigungen für den/die Host-Benutzer/-Gruppen festlegen
  3. VMs auswählen -> Reiter "Permission" -> "Commands" -> "New Permission" -> Benutzer/Gruppe auswählen und unter "Role" das gewünschte Privileg zuweisen.
Achtung Falle :!: Die einzelnen VMs laufen aber dennoch nicht mit diesen möglicherweise eingeschränkten Rechten, sondern immer noch als:
  • User that powers on the virtual maschine
  • Local system account
  • This user
Lediglich der Zugriff auf die VMs und deren Anzeige/Konfig ist für diese(n) Benutzer(gruppe) beeinträchtigt. Falls also jemand die VMware-Dienste/Damons aus Sicherheitsgründen mit anderen Rechten gestartet sehen will, muß er dies schon selbst umstellen und dabei dann hoffentlich auch sicherstellen, daß die VMs noch HW-Zugriff auf angeschlossene Gerätschaften (Sticks, Scanner etc) haben. Wer die VMserver2-Dienste/Damons nur mit Gast-Rechten/Account startet, braucht sich über den nicht verfügbaren USB-Stick auch nicht zu wundern. ;) Allerdings habe ich auch nicht ausprobiert, in wie weit man diese Start-Rechten beschneiden kann, damit der Server überhaupt noch problemlos hochfährt...

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Physikalischer Diskaccess

Beitragvon Dayworker » 23.06.2009, 17:27

Einen Datenträger physikalisch einzubinden geht nach wie vor und eigentlich auch fast auf die gleiche Weise wie noch beim Server1. Allerdings mußt du beim Server2 die nötigen Eintragungen von Hand vornehmen, da es keine GUI-Unterstützung mehr dafür gibt.
Das Einbinden einer Partition bzw phys.Datenträgers ist auch immer mit Vorsicht zu genießen, ansonsten ist Datenverlust vorprogrammiert. NTFS wäre so ein Beispiel aufgrund seiner stetigen Weiterentwicklung.

continuum hat geschrieben:unter Vista und aehnlichem Zeugs wie 2k8 oder windows 7 funktionieren meines Wissens physikalische Platten ueberhaupt nicht mehr - das geht nur mit Windows oder Linux - aber nicht mit Vista und Kumpels


McStarfighter hat geschrieben:Ich wiederhole mich zwar, aber: Beginnend mit Vista und Server 2008 hat Microsoft den sogenannten "Raw Disk Access" erheblich eingeschränkt. Die derzeit einzige brauchbare Lösung ist ein spezieller Treiber von www.eldos.com, welcher aber erstens mindestens 850 $ kostet und zweitens nicht als Endnutzer-Produkt konzipiert ist; will heißen: Dieser Treiber muß von Softwareproduzenten wie eben VMware lizenziert und dann in die eigenen Produkte eingepflegt werden.
Dieser Raw Disk Access ist, wenn ich mich nicht irre, nur noch im Kontext des Systems anwendbar, nicht mehr im Userspace und auch nicht als Admin. Tja und ohne RDA gibt es bei KEINER Virtualisierungssoftware einen Zugriff auf physikalische Platten. Ausnahme: USB-Festplatten, wenn sie auch als solche in die VM durchgereicht werden.

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Versuch der Optimalen Host-Konfiguration

Beitragvon Dayworker » 25.06.2009, 21:01

Generell eines vorweg, die absolut optimale Konfiguration gibt es nicht. Sie ist meist stark Anwendungsabhängig und jede VM braucht im Normalfall (Ullis MOA, Linux-Live-Systeme, Win/Bart-PE usw mal außen vor) auch ihren Diskzugriff. Da kann man nichts dran ändern, ABER man kann den Disk-IO auf ein Minimum reduzieren und damit die Hostleistung besser für die Gäste verfügbar machen. Wer halt immer etwas mehr braucht, muß sich doch mit dem ESX(i) und seiner HCL (HW-Kompatibililililililililitäts-Liste) anfreunden. ;)

Für die bestmögliche Rechenleistung sollte der Host möglichst einen Kern mehr als gestartete VMs haben, schließlich braucht das Host-OS auch noch etwas für seine wenigen Belange. Wenn sich dazu mindestens 512MB für 32bittige und 1GB für 64bittige Host-OS gesellen, kann der Rest an physischen RAM problemlos für VMware reserviert werden. Per Default reserviert VMware max 90% des verfügbaren Host-RAMs für sich, daß kann aber manchmal schon zuwenig für den Host sein. Also verändert man bei Notwendigkeit das per Web-Access oder VI-Client in den Memory-Einstellungen des Hosts. Dabei gibt es noch 3 Möglichkeiten auf die Verteilung des Host-RAMs Einfluß zu nehmen, wobei Punkt 1 eindeutig zu bevorzugen ist:
  1. Fit all virtual maschine memory into reserved host RAM
  2. Allow some virtual maschine memory to be swapped
  3. Allow most virtual maschine memory to be swapped
Den darunter befindlichen Hinweis von VMware sollte man wörtlich nehmen und ist selbsterklärend:
Swapping virtual maschine memory allows more virtual maschines to run but can degrade system performance if the virtual machines us their memory intensively.


Kommen wir mal zu den virtuellen HDDs.
Neue Disks legt man, ausreichend Platz immer voraus gesetzt, bevorzugt als "Preallocated" an. Das bedeutet, daß das Disk-File schon den kompletten Speicherplatz belegt. Das bringt vor allem beim Schreiben und auch beim Lesen Geschwindigkeitsvorteile in der VM, da die v.HDD hoffentlich am Stück liegt (Stichwort Defragmentierung) und ihre Datei-Fragmente (*.vmdk) daher nicht quer über die Host-HDD einsammeln muß. Der Split in 2GB ist eigentlich nur notwendig, wenn das Filesystem nicht mit größeren Dateien umgehen kann. Es erleichtert jedoch auch das Backup einer VM. 2GB als Datei kann man noch bequem auf DVD/BD/HDVD sichern, bei 100GB bleibt leider nur noch die HDD als kostengünstiges Medium übrig.
Dazu gibts für jede v.HDD auch noch 2 Einstellungen im Schreibverhalten der VM, die Optimierung auf Performance und die Optimierung auf Sicherheit. Beide lassen sich in meinen Augen recht einfach erklären, Performance = Write Back (Schreiben wenn Zeit dazu ist) und Sicherheit = Write Thru (Schreiben wenn angefordert).

Independent Mode: Erklärung folgt!

Eine für die Gäste optimale "config.ini" könnte daher so aussehen:
e-e-e hat geschrieben:setz' mal als erstes in der /etc/sysctl.config deines Linux-Hosts den Parameter vm.swappiness=0
und dann füge in die *.vmx der VMs folgende Zeilen ein :
MemAllowAutoScaleDown="FALSE"
mainMem.useNamedFile = "FALSE"
mainMem.partialLazyRestore = "FALSE"
mainMem.partialLazySave = "FALSE"
sched.mem.pshare.enable = "FALSE"
Dazu würde ich noch aufnehmen
mks.enable3d = "false"
Denn 3D-Support im Server2 läuft im Gegensatz zur WS6.5.x nicht.

sambu hat geschrieben:Die Config befindet sich hier:
  • Linux - /etc/vmware/config
  • Windows - Documents and Settings\All Users\Application Data\VMware\VMwareServer\config.ini
Erklärungen folgen!

sambu hat geschrieben:Eine vmx kann defragmentiert werden mit:
vmware-vdiskmanager -d meineDisk.vmdk

Shrink der virtuellen Disk:
vmware-vdiskmanager -k meineDisk.vmdk


Für Linux-Hosts mit wenig pRAM macht sich laut Ronny auch eine SSD sehr gut. Er schrieb dazu im Thread VMWare-Maschine "schläft ein"
e-e-e hat geschrieben:Hallo,

ich krame mal den alten Thread wieder vor.
Ich habe gestern mal eine 64 GB SSD (SATA2) in mein System eingebunden (siehe Signatur) und dort auf einzelnen Partitionen Swap (12 GB), /var/tmp (6 GB), /tmp (29 GB) und /dev/shmfs (12 GB) - was ich mir wahrscheinlich hätte sparen können - eingerichtet. Dann habe ich dem VMware Server erlaubt, einigen vRAM auszulagern, und habe noch eine VM gestartet.
Fazit:
Die Auswirkungen gleich nach dem Start sind minimal, mir ist aber sehr geringes o.g. Einschlafverhalten aufgefallen (die VMs reagierten heute morgen ca. 1 Minute etwas träge). Eine SSD scheint als Tuning für einen Linux-Host bei zu wenig RAM, ganz gut zu funktionieren.

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beobachtungen mit 2 v.CPU-Kernen in einer VM

Beitragvon Dayworker » 28.06.2009, 17:55

Nachdem im ESXi4-Bereich ein Posting namens cpuid.coresPerSocket keine Wirkung im W2003 Enterprise auftauchte, habe ich mit dem genannten Tool "mpdetect" mal ein wenig im Server2.01 getestet.

Der passende Hintergrund dazu verbirgt sich im c't-Artikel Mit Händen und Füßen - Maßnahmen und Tools zur Nutzung vieler Kerne und das Prog ist downloadbar unter http://www.heise.de/ct/06/08/links/206.shtml
Wobei zu sagen ist, daß sich das unter Linux wesentlich einfacher entweder über "numactl" von Andi Kleen oder über die Ausgabe von "/proc/cpuinfo" rausfinden ließe. ;)

Ich habe also einige Tests gemacht und meine bisherigen Vermutungen haben sich teilweise bestättigt. Der Server2 sieht bei 2v.CPU-Kernen in einer VM meistens 2 Singlecores in einem Dual-Sockel-Board und Bilder sagen ja bekanntlich mehr als Worte. So sieht ein E6600 auf dem Host aus...
Bild

...und so wird in einer VM mit monitor.virtual_exec="hardware" dann dieselbe CPU angezeigt:
Bild
Jetzt wird es kompliziert. :roll:
Der Parameter "monitor.virtual_exec" ist enorm wichtig. Falls dieser nicht gesetzt ist, lautet die VMware-Vorgabe dafür "automatic". Dieser Vorgabe folgend, erscheint im "vmware.log" auf einer Conroe-CPU die Einstellung "dynamic". Leider wechselte dann bei jedem Prog-Aufruf die Erkennung der Package-ID und die Anzeige wäre damit nicht reproduzierbar. Mit der Einstellung "Software" hingegen ist die Package-ID zumindest bei Win-Win-Systemen immer gleich der Ausgabe der Host-CPU. Eine Erklärung dafür könnte ein Eintrag im VMware-Log sein:
Software virtualization is incompatible with long mode on Intel EM64T CPU. Virtual execution will begin in software mode, but will automatically switch to hardware mode if the enters long mode.

Durch diesen ständigen Wechsel wäre dann in meinen Augen auch klar, weshalb die Last von Host und Gast mit 2 CPU-Kernen ansteigt, obwohl die VM im Leerlauf dümpelt.
Wie sich das Ganze nachher in Rechenleistung oder dessen Verlust darstellt, müßte man mal bei Gelegenheit überprüfen...

Zum Vergleich habe ich auch mal die Ausgabe meines Q6700 als Host-CPU gepinnt:
Bild

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Kopieren einer Windows-VM

Beitragvon Dayworker » 14.09.2009, 09:04

F2B hat geschrieben:Also zum klonen einer VM im gleichen Netzwerk reicht es, die VM im Ordner einfach zu kopieren, umzubenennen und der VM logischerweise eine andere IP geben.
Aber wie ändere ich die Sid?

I.P. hat geschrieben:sysprep funktioniert gut, ist aber einigermaßen aufwändig.

sysinternals newsid funktioniert genauso gut und einfacher.

beide haben vor und nachteile, wenns nur um das clonen einer vm geht und man selbst den ganzen vorgang durchführt ist newsid einfacher.

der vorgang bei newsid ist immer der selbe:

1. newsid.exe auf einer lokalen hdd in der quellvm ablegen
2. verzeichnis kopieren
3. clon ohne netzwerk starten (virtuelle nic not connected)
4. newsid als administrator ausführen
5. reboot
6. vm-hostnamen ändern
7. reboot (hier kann auch die nic schon wieder connected sein)

ich weiss, 4+6 kann man auch in einem schritt mit newsid erledigen, ich machs aber immer so weil es sich bewährt hat, fehlerunanfällig ist und 1 reboot nur ein paar minuten mehr kostet, das ist es wert.

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Tastatur-Probleme in den Gästen auf Linux-Hosts

Beitragvon Dayworker » 20.09.2009, 22:04

VMware hat Probleme mit nichtfunktionierenden Keyboards bzw einzelnen Tasten beim Server2 schon vorhergesehen, Server1 unterstützt neuere Kernel garnicht erst, und widmet diesen auch ein eigenes Kapitel "Keyboard Mapping on Linux Hosts" im Manual ab Seite 184ff. Betroffen sind davon eigentlich alle Distributionen, die zur selben Zeit wie Ubuntu 8.10 veröffentlicht wurden und/oder auf der Kernel-Version 2.6.27+ beruhen. Im Endeffekt liegt das Problem in den Veränderungen im X-Server, da für die Grafikeinstellungen ab sofort allein der Kernel zuständig ist. Ein typisches Merkmal dafür ist das fehlende Bildschirmflackern beim Laden der GUI, während die Grafiktreiber initialisiert werden oder eine nicht mehr vorhandene oder einfach leeren xorg.conf. Je nach Distribution läuft es wohl auf 2 Sachen hinaus:
  1. Heribert hat geschrieben:Das Problem hatte ich auch und konnte es lösen in dem ich in ~/.vmware/config folgenden Eintrag eingesetzt habe:

    xkeymap.nokeycodeMap = true

    Falls die Datei nicht existiert, lege sie einfach neu an. Die Virtuelle Maschine und VMware selbst müssen vorher geschlossen werden.
  2. ds2k5 hat geschrieben:xkeymap.keycode.108 = 0x138 # Alt_R
    xkeymap.keycode.106 = 0x135 # KP_Divide
    xkeymap.keycode.104 = 0x11c # KP_Enter
    xkeymap.keycode.111 = 0x148 # Up
    xkeymap.keycode.116 = 0x150 # Down
    xkeymap.keycode.113 = 0x14b # Left
    xkeymap.keycode.114 = 0x14d # Right
    xkeymap.keycode.105 = 0x11d # Control_R
    xkeymap.keycode.118 = 0x152 # Insert
    xkeymap.keycode.119 = 0x153 # Delete
    xkeymap.keycode.110 = 0x147 # Home
    xkeymap.keycode.115 = 0x14f # End
    xkeymap.keycode.112 = 0x149 # Prior
    xkeymap.keycode.117 = 0x151 # Next
    xkeymap.keycode.78 = 0x46 # Scroll_Lock
    xkeymap.keycode.127 = 0x100 # Pause
    xkeymap.keycode.133 = 0x15b # Meta_L
    xkeymap.keycode.134 = 0x15c # Meta_R
    xkeymap.keycode.135 = 0x15d # Menu
    ...wobei die Keycodes von 2. auf einen Link nach https://bugs.launchpad.net/ubuntu/+bug/289098 beruhen...

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Änderungen in V2.0.2

Beitragvon Dayworker » 27.10.2009, 16:34

Änderungen in V2.0.2

VMware Server Version 2.0.2 | 27 October 2009 | Build 203138
Document last updated: October 26, 2009

Die Release Notes finden sich wie immer unter http://www.vmware.com/support/server2/d ... er202.html oder nachfolgend :D

Known Issues

The following issues are known to occur with VMware Server 2.0.2.

  • VMware Tools notifies you to upgrade VMware Tools even when the latest version is installed.
    After you log in to a guest operating system as a non built-in administrator and upgrade VMware Tools from Server 2.0 to Server 2.0.2, VMware Tools shows the following message: VMware Tools can be upgraded although it is the latest version.
    This issue is applicable to Windows Vista and Windows 2008 guest operating systems running on Windows Vista or Windows 2008 hosts.
    Workaround: Log in by using the built-in administrator account in Windows Vista or Windows 2008 guest operating system before upgrading VMware Tools.
  • VI Web Access login screen fails to load occasionally
    The login screen of VI Web Access occasionally fails to load, especially when you try to access a Server 2.0.2 installation by using VI Web Access for the first time.
    Workaround: Refresh VI Web Access or access VI Web Access in another instance of the Web browser.
  • When attempting to install VMware Server on a Windows host, you might see the message Please verify the md5 hash value of this executable and then press 'Yes' to continue.
    Workaround: This message is sometimes displayed when the installer package size is large. You can check the md5 hash value to verify the package before you continue the installation. The md5 hash values are listed on the VMware Server 2 download page.
  • When attempting to install VMware Server on a Windows 2003 Server host, you might see the error message Error 1718. File installer_name.msi was rejected by digital signature policy.
    Workaround: For more information and possible workarounds, see http://support.microsoft.com/kb/925336. Make sure that your operating system has all the latest updates applied.
  • When attempting to install VMware Server on a Windows 2003 Server host, you might see the error message System Administrator has set policies to prevent this installation.
    Workaround: Right-click the installer file, choose Run as, and enter the Administrator username and password. Additional configuration steps might be required. See http://social.technet.microsoft.com/for ... d36217225/.
  • When upgrading on a Windows host, the installer might prompt you to reboot the system. After the system is rebooted, you might see the message This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer Package.
    Workaround: Manually restart the installation from the VMware Server installer executable.
  • On Windows Server 2008, network settings are not preserved when upgrading to the release version of VMware Server 2.
  • On Windows, the VMware Server desktop and Start menu shortcuts use the NetBIOS name in the connection URL. This might cause VI Web Access to fail to connect to VMware Server. VMware Remote Console connections might also fail, with the error Error opening the remote virtual machine machine_name: The host name could not be resolved.
    Workaround: Enter the correct host name as the Fully Qualified Domain Name (FQDN) when prompted by the Windows installer. Or, if the URL specified in the shortcut does not work, use the correct host name, IP address, or localhost, as appropriate, in the connection URL. You can also manually enter the short name and the FQDN, or localhost, in the /etc/hosts file.
  • When you connect to VI Web Access using Firefox 3, a Security Connection Error is displayed, indicating that the VMware Server host is using an invalid security certificate. The certificate is not trusted because it is self signed.
    Workaround: To allow VI Web Access to connect to the host:
    1. Click Or you can add an exception.
    2. Click Add Exception.
    3. Click Get Certificate.
    4. Verify that Permanently store this exception is selected.
    5. Click Confirm Security Exception.
  • If you use a CIFS datastore and the Windows Credential Manager becomes unavailable for that storage location, virtual machines using that datastore become inaccessible. If you attempt to remove the CIFS datastore from VMware Server while virtual machines are stored on the datastore or virtual CD/DVD drives are connected to ISO image files on the datastore, it will fail with an error message indicating that resources are in use.
    Workaround:
    • If you have a virtual machine stored on a CIFS datastore that is inaccessible:
      1. Remove the virtual machine, but DO NOT delete the associated disk files.
      2. Move the virtual machine files to a non-CIFS datastore (unless you want to re-add the CIFS datastore).
    • If any virtual machines are connected to an image file stored on a CIFS datastore that is inaccessible:
      1. Edit the virtual machine's CD/DVD drive and disconnect the image file or remove that CD/DVD drive from the virtual machine.
      2. Move the ISO image to a non-CIFS datastore (unless you want to re-add the CIFS datastore).
    • After you complete these steps for all virtual machines using the CIFS datastore:
      1. Remove the datastore.
      2. Add the datastore.
      3. Add the virtual machine to the inventory.
  • On some SLES hosts, VMware services do not start automatically after reboot.
    Workaround: To start VMware services, log on to the host as root and enter the command: /etc/init.d/vmware-mgmt start
  • If you click Install VMware Tools in VI Web Access after uninstalling VMware Tools, the VMware Tools image is not mounted in the guest.
    Workaround: To successfully mount the VMware Tools image:
    1. In VI Web Access, click Eject Installer to cancel the VMware Tools installation.
    2. In VMware Remote Console, disconnect the CD/DVD drive by selecting Devices > CD/DVD Drive 1 > Disconnect.
    3. In VI Web Access, click Install VMware Tools.
    4. In VMware Remote Console, complete the VMware Tools installation.

  • Automatic VMware Tools upgrade might fail in Windows 2003 Server guests.
    Workaround: Upgrade VMware Tools interactively.
  • In RHEL 4.6 AS 64-bit guests, mouse behavior is not correct after VMware Tools is installed.
    Workaround: Restart the guest or the Xsession after VMware Tools is installed.
  • On RHEL systems, sometimes the arrow keys that allow you to cycle between multiple instances of VMware Remote Console in full screen mode are grayed out and cannot be used.
    Workaround: Close all instances of VMware Remote Console and delete the file /tmp/vmware-$USER/vmplayer-daemon-$DISPLAY (for example, /tmp/vmware-root/vmplayer-daemon-:0.0). Then restart one or more instances of VMware Remote Console.
  • In Netware 6 guests with VMware Tools installed, it is not possible to transfer control of the mouse from VMware Remote Console back to your computer unless you press Ctrl+Alt.
  • Connected devices are not listed in the VMware Tools control panel Devices tab.
    Workaround: Users that have the appropriate permissions can connect and disconnect devices using VI Web Access or VMware Remote Console.
  • The vmnet-netifup daemons do not terminate when VMware Server is stopped.
    Workaround: Disable IPv6 on your host.
  • If you create quiesced backups and you set vmwriter.overwriteSnapshots to TRUE in the VMware VSS Writer configuration file, existing snapshots for all virtual machines on that host are overwritten unless the snapshots are locked.
    Workaround: Lock any snapshots that you don't want to overwrite in the Configure VM Snapshots tab.
  • On Red Hat Enterprise Linux 5 with SELinux enabled, the host agent will not start due to library loading errors.
    Workaround: Use the chcon command to change the security context for any libraries that fail to load, for example: chcon -t texrel_shlib_t /usr/lib/vmware/vmacore/libvmacore.so.1.0.
  • On Linux hosts, USB devices are not correctly released from a powered off virtual machine. It is possible to connect released devices to another virtual machine, but then neither virtual machine can successfully use the devices when both virtual machines are powered on.
    Workaround: Do not attempt to share a USB device between virtual machines. Manually disconnect the USB device before you connect it to a different virtual machine.
  • If you rename a virtual machine in the VI Web Access inventory panel, the virtual machine is not automatically moved to the correct alphabetical position in the inventory list. Collapsing and expanding the inventory list does not fix navigation in the inventory panel, which can cause other unexpected results.
    Workaround: Refresh the page after renaming a virtual machine.
  • If you create a new preallocated virtual disk (by selecting the Allocate all disk space now file option) in the Add Hardware wizard, you can only add one new preallocated disk at a time. If you select More Hardware and attempt to add a second new preallocated virtual disk before you finish adding the first preallocated virtual disk, the wizard might hang in a Loading state.
    Workaround: Click Finish after adding each new preallocated virtual disk, rather than selecting More Hardware to create multiple virtual disks at the same time. Alternatively, do not select Allocate all disk space now.
  • When adding a new permission, the error Database temporarily unavailable or has network problems is displayed.
    Workaround:
    1. Stop the VMware Server host agent (at the command line, enter /etc/init.d/vmware-mgmt stop).
    2. Create a backup copy of the /etc/vmware/hostd/authorization.xml file.
    3. Open the /etc/vmware/hostd/authorization.xml file in an editor and set NextAceId to the next integer value that is not being used as as an ACEDataId. For example, if the file contains the entry setting NextAceId to 11, set NextAceId to 12.
    4. Save the updated file.
    5. Restart the host agent (at the command line, enter /etc/init.d/vmware-mgmt start).
  • If you use the Quick Find feature in the Create Permissions dialog box in VI Web Access, the search might fail with a general system error.
    Workaround: Close the dialog box and reopen it before attempting to search again.
  • If you use Avira AntiVir antivirus software on Windows hosts, you might have problems running virtual machines.
  • If you have a legacy version of Neoteris Secure Application Manager installed on a client system where you are running VMware Remote Console, VMware Remote Console may fail to connect to a virtual machine on a Windows host.
    Workaround: Uninstall Neoteris Secure Application Manager and upgrade to the most recent version, available through Juniper Networks.
  • When you attempt to install a new version of the VMware Remote Console add-on over an existing version in Internet Explorer version 7.0.5730.11, a message indicating that the installation was canceled is displayed, and the installation fails. It is not possible to delete the add-on.
    Workaround: Upgrade Internet Explorer to a more recent version.
  • On some Linux guest systems, including Red Hat Enterprise Linux 4 and Suse 9.3, the guest operating system binds virtual network adapters to specific MAC addresses. When the MAC address changes (for example, when the virtual machine is cloned), you must update the associated guest operating system configuration.
  • If you are not using the default ports (8222/8333) for VI Web Access, clicking Help from the virtual network editor on the host displays a failure to load page error in the Web browser instead of the appropriate help page.
    Workaround: Change port number in the help URL or access the virtual network editor help from VI Web Access.


Resolved Issues

The following issues are resolved in Server 2.0.2:

Security Fixes

  • NEW: Exception handling privilege escalation on Guest Operating System
    This release addresses a security vulnerability in exception handling. Improper setting of the exception code on page faults might allow for local privilege escalation on the guest. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2009-2267 to this issue.
  • NEW: Directory Traversal Vulnerability on Linux-based hosts
    This release addresses a directory traversal vulnerability that is present on host systems and that may allow for remote retrieval of any file from the host system. In order to send a malicious request, the attacker will need to have access to the network on which the host resides. The issue is present on Linux-based hosts only, not on Windows-based hosts. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2009-3733 to this issue.

Miscellaneous

  • Disk Stress Test fails with data corruption error
    WLK DiskStress test fails with data corruption error on LSI Logic virtual device.
  • Server 2.0.1 does not allow vmnet-bridge service to be run in the foreground
    The vmnet-bridge service has a parameter -d for putting it in daemon mode. Without using the -d parameter, the vmnet-bridge service should be able to run in the foreground. This was not working. This issue is resolved in this release.


Hier die einzelnen Dateigrößen und Beschreibungen im Überblick:

For Windows
VMware Server 2

Version 2.0.2 | 203138 - 10/26/09 507 MB Binary (.exe)
VMware Server 2 for Windows Operating Systems. A master installer file containing all Windows components of VMware Server.
md5sum: a6430bcc16ff7b3a29bb8da1704fc38a(¹)

VIX API 1.6 for Windows.
Version 2.0.2 | 203138 - 10/26/09 37 MB Binary (.exe)
md5sum: 827e65e70803ec65ade62dd27a74407a(¹)

For Linux
VMware Server 2 for Linux Operating Systems.
Version 2.0.2 | 203138 - 10/26/09 483 MB Binary (.gz)
md5sum: 95ddea5a0579a35887bd15b083ffea20(¹)

VMware Server 2 for Linux Operating Systems 64-bit version.
Version 2.0.2 | 203138 - 10/26/09 452 MB Binary (.rpm)
md5sum: 35c8b176601133749e4055e0034f8be6(¹)

The core application needed to run VMware Server 2, 64-bit version.
Version 2.0.2 | 203138 - 10/26/09 451 MB Binary (.gz)
md5sum: cc7aef813008eeb7150c21547d431b39(¹)

Bisher noch nicht gelistet:
VIX API 1.6 for Linux.
Version 1.6.2 | 156745 - 03/31/09 17 MB TAR image
md5sum: 2ef6174b90cdd9a2832b57dbe94cfbb1(¹)

64-bit VIX API 1.6 for Linux.
Version 1.6.2 | 156745 - 03/31/09 21 MB TAR image
md5sum: 454aeba273f9a89c578223c95b262323(¹)

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Vi-Client der Version 2.00

Beitragvon Dayworker » 14.11.2009, 15:48

Da die Download-Links für die Versionen 2.00 und 2.01 nicht mehr funktionieren, findet sich nur noch über https://www.vmware.com/freedownload/log ... t=server20 eine indirekte Möglichkeit dazu. Nach der notwendigen Anmeldung einfach runterscrollen zu den vorherigen Versionen, dann eine der v2.00-Versionen als *.tar.gz oder auch die *.exe downloaden und dort die Datei VI-Client.exe extrahieren. ;)

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Schnellverwaltung des VMserver2 von der CMD oder Ba$h aus

Beitragvon Dayworker » 15.11.2009, 13:50

Schnellverwaltung des VMserver2 von der CMD oder Ba$h aus

Da es das vmware-cmd ja nun beim VMserver2.X nicht mehr gibt, ersetzt vmrun dieses und bietet dazu auch erweiterte Möglichkeiten in der Plattform-Verwaltung von Server1 (server1), Server2 (server) und Workstation (ws) an. Leider ist die Syntax in meinen Augen ein bisken tricky. Besonders die Angabe mit dem Datastore, dem unbedingten Leerzeichen danach und der Beachtung von Groß-/Kleinschreibung der VMX-Bezeichnung sorgt nicht unbedingt gleich für erste Erfolge. Ich werde in diesem Forumsbereich aber nur auf den VMserver2 eingehen. Für die WS sei aber zumindest soviel gesagt, daß die Authentifizierung gegenüber dem Host mit Eingabe von -u serveruser und -p serverpasswort entfällt.
Beide (Server1/2 und WS) hingegen bieten die Möglichkeit, sich mit einem Benutzernamen und dazugehörenden Paßwort im Gast-OS anzumelden. Dazu gehören die Parameter:
  • -gu
  • -gp
Das macht natürlich nur dann auch einen Sinn, wenn man dem Gast auch noch ein Programm zum Starten (hier "c:\Program Files\myProgram.exe" und /usr/bin/X11/xclock -display :0) übergeben will und das sich dann noch feiner über
  • -noWait
  • -activeWindow
  • -interactive
oder
  • Complete-Path-To-Program [Program arguments]
beeinflussen läßt. Die Anführungszeichen sind dabei wie immer nur bei Leerzeichen im Pfad oder Programmnamen erfoderlich.

Hier mal ein Beispiel für Windows:
vmrun -h https://127.0.0.1:8333/sdk -u serveruser -p serverpasswort -gu gastuser -gp gastpasswort -T server suspend "[standard] Windows Entwicklung/Windows Entwicklung.vmx" runProgramInGuest "c:\Program Files\myProgram.exe"

...und dasselbe Beispiel für Linux:
vmrun -h https://127.0.0.1:8333/sdk -u serveruser -p serverpasswort -gu gastuser -gp gastpasswort -T server suspend "[standard] Linux Entwicklung/Linux Entwicklung.vmx" runProgramInGuest /usr/bin/X11/xclock -display :0

Die Power Commands sind in Summe 6. Sie teilen sich in Parameter und parameterlose Kommandos auf:
  • suspend
  • reset
  • stop
  • start
Die ersten 3 Kommandos verfügen noch über die Unterscheidung in hard und soft, während start zusätzlich die Parameter gui und nogui anbietet. Zu diesen 4 Kommandos mit Parameter gesellen sich noch die zwei parameterlosen Kommandos:
  • pause
  • unpause


Die vollständige Liste sämtlicher Kommandos und Parameter ist über die folgenden 3 Bilder ersichtlich, die allerdings noch unter der VMserver-Version 2.01 erstellt wurden.
Bild
Bild
Bild

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

VMserver End Of Availability on January 2010

Beitragvon Dayworker » 04.08.2010, 17:53

VMserver End Of Availability on January 2010

Laut http://www.vmware.com/support/policies/ ... icy_server ist der VMserver offiziell am Ende seiner Verfügbarkeit angelangt und Support wird nur noch im Rahmen des kostenpflichtig abgeschlossenen Supportzeitraumes maximal jedoch bis zum 2011/06/30 gewährt. Die originale Randnotiz dazu lautet:
VMware Server was declared End Of Availability on January 2010. Support will be limited to Technical Guidance for the duration of the support term.

Benutzeravatar
King of the Hill
Beiträge: 12021
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Zwang zu SSL und Weiterleitung auf Port 8333 abschalten

Beitragvon Dayworker » 23.09.2012, 02:14

Zwang zu SSL und Weiterleitung auf Port 8333 abschalten

Das Problem mit SSL und dem verschlüsselten Port 8333 ist, daß der VMserver2 zum einen nur ein selbstsigniertes Zertifikat mitbringt, welches dadurch von jedem Browser bemängelt wird, und zum anderen, daß die Verbindung zu diesem Port in 10% aller Verbindungsversuche fehlschlägt. Ändern läßt sich das nur per manuellem Eingriff in die Datei "proxy.xml", auffindbar unter Windows in "%systemroot%\Dokumente und Einstellungen\All Users\Anwendungsdaten\VMware\VMware Server\hostd\proxy.xml" und Linux in "/etc/vmware/hostd/proxy.xml". Andernfalls werden alle Verbindungsversuche auf den unverschlüsselten Port 8222 per Redirect-Anweisung doch wieder auf den verschlüsselten 8333 umgeleitet.
Damit die manuelle Änderung nicht gleich wieder durch den RAM-Inhalt überschrieben wird, müssen dazu alle VMware-Dienste abgeschaltet sein. Das erreicht man entweder unter Linux auf der ba$h per "/etc/init.d/vmware stop ; /etc/init.d/vmware-mgmt stop" bzw unter Windows in der Computer-Verwaltung oder CMD per "net stop VMAuthdService & net stop VMwareServerWebAccess". Den Dienst "VMwareHostd" braucht man nicht extra beenden, da dieser vom Dienst "VMAuthdService" abhängig ist.
Hier der originale Dateiinhalt von "proxy.xml":

Code: Alles auswählen

<ConfigRoot>
 <httpPort>8222</httpPort>
 <httpsPort>8333</httpsPort>
 <EndpointList>
 <_length>5</_length>
 <_type>vim.ProxyService.EndpointSpec[]</_type>
 <e id="0">
 <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
 <accessMode>httpAndHttps</accessMode>
 <pipeName>/var/run/vmware/proxy-webserver</pipeName>
 <serverNamespace>/</serverNamespace>
 </e>
 <e id="1">
 <_type>vim.ProxyService.LocalServiceSpec</_type>
 <accessMode>httpsWithRedirect</accessMode>
 <port>8307</port>
 <serverNamespace>/sdk</serverNamespace>
 </e>
 <e id="2">
 <_type>vim.ProxyService.LocalServiceSpec</_type>
 <accessMode>httpsWithRedirect</accessMode>
 <port>8308</port>
 <serverNamespace>/ui</serverNamespace>
 </e>
 <e id="3">
 <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
 <accessMode>httpsOnly</accessMode>
 <pipeName>/var/run/vmware/proxy-vpxa</pipeName>
 <serverNamespace>/vpxa</serverNamespace>
 </e>
 <e id="4">
 <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
 <accessMode>httpsWithRedirect</accessMode>
 <pipeName>/var/run/vmware/proxy-mob</pipeName>
 <serverNamespace>/mob</serverNamespace>
 </e>
 </EndpointList>
</ConfigRoot>


Wenn man jetzt alle Einträge mit "httpsWithRedirect" in "httpAndHttps" ändert, kann man sich entweder per HTTP oder HTTPS verbinden. Die Datei "proxy.xml" sieht dann wie folgt aus:

Code: Alles auswählen

<ConfigRoot>
 <httpPort>8222</httpPort>
 <httpsPort>8333</httpsPort>
 <EndpointList>
 <_length>5</_length>
 <_type>vim.ProxyService.EndpointSpec[]</_type>
 <e id="0">
 <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
 <accessMode>httpAndHttps</accessMode>
 <pipeName>/var/run/vmware/proxy-webserver</pipeName>
 <serverNamespace>/</serverNamespace>
 </e>
 <e id="1">
 <_type>vim.ProxyService.LocalServiceSpec</_type>
 <accessMode>httpAndHttps</accessMode>
 <port>8307</port>
 <serverNamespace>/sdk</serverNamespace>
 </e>
 <e id="2">
 <_type>vim.ProxyService.LocalServiceSpec</_type>
 <accessMode>httpAndHttps</accessMode>
 <port>8308</port>
 <serverNamespace>/ui</serverNamespace>
 </e>
 <e id="3">
 <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
 <accessMode>httpAndHttps</accessMode>
 <pipeName>/var/run/vmware/proxy-vpxa</pipeName>
 <serverNamespace>/vpxa</serverNamespace>
 </e>
 <e id="4">
 <_type>vim.ProxyService.NamedPipeServiceSpec</_type>
 <accessMode>httpAndHttps</accessMode>
 <pipeName>/var/run/vmware/proxy-mob</pipeName>
 <serverNamespace>/mob</serverNamespace>
 </e>
 </EndpointList>
</ConfigRoot>

Nach der Änderung muß man die zuvor beendeten Dienste über "net start VMAuthdService & net start VMwareHostd & net start VMwareServerWebAccess" bzw "/etc/init.d/vmware start ; /etc/init.d/vmware-mgmt start" neu starten.










Hinweis:
Ich bitte darum eventuell aufkommende Fragen und Probleme in ein eigenes Posting zu plazieren, damit sich dieser Sticky-Thread nicht zu sehr ins Uferlose ausdehnt und weiterhin als "Leitfaden" oder "Gute Seele" dienen kann :!: Falls Unkorrektheiten oder sogar Fehler vorhanden sein sollten, dann einfach per PN melden. Ich werd's dann zeitnah korrigieren oder erweitern. :D


Zurück zu „VMserver 2“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast