vSphere Client für Linux

[mop]

Hallo,

es betrifft zwar nicht nur den ESXi, aber gibt es inzwischen eigentlich den VSphere Client auch für Linux?

Danke mop

[PeterDA]

Hi,
nicht das ich wüsste. Aber Linux-Menschen machen doch eh am liebsten alles per Comandozeile und das geht natürlich. Ansonsten gibts ja das Webinterface oder im Linux einfach VMware Player installieren und dort VI Client in einem Windows laufen lassen.

Gruß Peter

[continuum]

Mecker hier
http://communities.vmware.com/thread/49061?tstart=50

hilft zwar nicht aber beruhigt vielleicht etwas

[McStarfighter]

Na super, nen Linux-Client auf Adobe Flex-Basis ... Wie wäre es mit Perl, Python, Ruby, GTK, Qt, die sind wenigstens offen und nicht wieder gekettet an ne einzelne Firma. Zumal Adobe ja nicht grad mit Sicherheitsbeußtsein in ihren Produkten glänzt ...

Und an Flash ist das auch nocht gekoppelt ... grml ...

[Dayworker]

Da ist es wohl wirklich am einfachsten/sinnvollsten, eine Win-VM mit dem Vi-/vSphere-Clienten aufzusetzen.

[McStarfighter]

Ich hoffe ja immer noch, daß in absehbarer Zeit das NET Framework 3.5 unter Wine installierbar ist. Dann ist die derzeit größte Hürde für den vSphere-Client aus dem Weg geräumt. Denn derzeit ist NET 2.0 zwar im Gold-Status, aber NET 3.0 hat nur Bronze und NET 3.5 ist noch "Garbage" ...

http://appdb.winehq.org/objectManager.p ... n&iId=2586

Eine andere "Lösung" wäre das Erstellen entweder einer PortableApp, die das NET Framework in sich hat, oder ein ThinApp, bestehend aus NET 3.5 und dem Client.
Man könnte aber auch mal NET 3 unter nem aktuellen Wine installieren und dann den Client, evtl. klappts ja. Mir selbst fehlt leider die Möglichkeit, den Client an sich auch auszuprobieren (mangels ESX-Gegenstelle) ...

[Dayworker]

Also mit 2 VMs, wobei eine einen ESX(i) hostet, könnte man das ausprobieren...

[McStarfighter]

Hab nur die Power nicht dafür, das dauert bei mir ja noch ein wenig ...

Hättest du die Möglichkeit, das mal zu testen? Würde bestimmt vielen entgegenkommen ...

[mop]

hi,

danke für eure Antworten, auch wenn sie nicht unbedingt so ausgefallen sind, wie ich mir das gewünscht hätte

WebInterface wäre super, aber für den ESXi ja nicht möglich ..

Den Thread bei VMWare werd ich mir mal antun, wenn ich gaaanz viel Zeit hab ..

Wenn ich nur mein Linux Notebook mithabe, nutze ich schon die Kommandozeile, aber manchmal wäre ein wenig "bunt" doch ganz schön.

Naja, vielleicht hat ja jemand von euch mal Zeit und Lust, den gemachten Voschlag von McStarfighter auszuprobieren

Schönes Wochenende
mop

[Dayworker]

Du bist herzlich eingeladen, es auch mal zu probieren.

PS: Meine Frau erschlägt mich, wenn ich dieses WE wieder vor dem Rechner verbringe.

[McStarfighter]

Naja, es muß ja nicht DIESES Wochenende sein ...

[continuum]

falls es sich noch nicht herumgesprochen hat - fuer den Vsphere-client reicht definitiv dotnet 2 - auf MOA laeuft er auch - da gibt es auch nur dotnet 2

Mir selbst fehlt leider die Möglichkeit, den Client an sich auch auszuprobieren (mangels ESX-Gegenstelle) ...

faule Ausrede - den Client kann man sich aus dem dd-image extrahieren

[McStarfighter]

Hm, dann sollte es doch unter Wine kein Problem sein ... Warum kommt da nur im VMTN keiner drauf? "grübel"

[mschoen]

Nach einigen hin und her hab ich nun die VI4 Client installiert bekommen. Der Client lässt sich auch starten, das VMware Logo fehlt zwar, aber ist eher nebensächlich. Der Login scheitert jedesmal mit Timeout, was ich auf den Client zurückführe.

Einer schon weiter gekommen?

[McStarfighter]

Welche Wine-Version? Welches Linux? Wie bist du genau vorgegangen?

[mschoen]

Welche Wine-Version? Welches Linux? Wie bist du genau vorgegangen?

Hab gerade auf winehq.org ein Tut für den vSphere Client gefunden. Das probier ich gerade aus, ist allerdings noch mit garbage markiert...

Wine 1.1.42
Ubuntu 10.10 unstable x86

1. winetricks besorgen
2. darüber dotnet20, visualc2005 u. eine weitere lib (muss ich nochmal den namen gucken) installieren
3. vsphere client installieren
4. config anpassen auf http:80

[Dayworker]

Gibt es einen logischen Grund solch diffizile Tests auf einem Ubuntu 10.10 unstable x86 zu fahren?
Dürfte sich die Chancen auf einen Erfolg nicht wesentlich erhöhen, wenn man dafür ein vollfunktionales Linux nehmen würde und keine Alpha-Version?

Welches Tut auf winehq.org, meinst du das hier http://appdb.winehq.org/objectManager.p ... &iId=16919

[mschoen]

Im Moment sehe ich nicht, dass der Fehler bei der Ubuntu Version liegt. Hab das von dir gepostete Tutorial verwendet, das führte aber zum selben Problem, welches ich vorher auch schon hatte: "connection failure occured". Als Fehler werden nur ein paar Libs genannt, die er angeblich nicht finden kann obwohl sie im selben Ordner liegen wie auch die Binarys zum vSphere Client...

Muss noch hinzufügen, dass ich auch kein vCenter habe u daher die config die gleich der Client Binary ist geändert habe...

Vielleicht kann ja jemand das mal auch einem stable-Release testen...

[McStarfighter]

Ich würde ja auch eher sagen, man nehme die aktuelle Stable, die ist sogar LTS. Und um in Bezug auf Wine Aktualität zu halten, schmeißt du mal "ppa:ubuntu-wine/ppa" in die Liste der Repositories. Dann bekommst du nämlich auch die aktuelle Wine-Version und nicht "nur" die 1.1.42 (auch wenn ja schon nah am aktuellen, nämlich 1.1.44, ist).
Damit man sich die Arbeit ne Ecke einfacher machen kann (auch mit Winetricks), installiert man sich dann noch q4wine. Ist ne echt feine Sache und hilft doch sehr. Um es aber gleich zu sagen: q4wine ist ne Qt-basierte Applikation und daher primär in KDE zu nutzen.

Dies sollten dann auch gute Bedingungen für Tests sein.

Wenn das nicht ganz klappt: Ich KÖNNTE lizenzierte Ausgaben von Crossover Pro und Bordeaux4Linux zur Verfügung stellen, um auch diese zu testen. Aber bitte erstmal das normale Wine durchackern, um die Möglichkeit zu erarbeiten, auch ohne Zusatzkosten den Client unter Linux nutzen zu können ...

[mschoen]

Auch mit der .44 ändert sich bei mir nichts...

[McStarfighter]

Sehr sehr ärgerlich ... Ahnung vom Debugging müßte man haben ...

[stefan.becker]

O Gott, ein WINE-Krampf.

Macht euch schon mal darauf gefasst, dass es vielleicht irgendwann geht, aber nicht vollständig und mit der nächsten Version vielleicht noch etwas und mit der übernächsten garantiert nicht mehr.

WINE ist leider die Perfektion des Konjunktivs. Jede andere Lösung ist besser.

[mschoen]

Vielleicht hilft die viel beschworene Glaskugel...

Ne, ich find es schon ziemlich eigenartig, da einige Kommentare im AppPool auf eine funktionierende Version hindeuten... und bei Codeweavers ist es mit "not working" gekennzeichnet und das basiert ja nun bekannterweise auch auf wine...von Krampf kann man da schon nicht mehr sprechen...

in dem sinne

[Dayworker]

Also der vSphere-Client installiert bevor die eigentliche Client-Inst losgeht noch 2 weitere Bestandteile names "M$ Visual Studio C++ 2008 Redistributable - x86 -9.0.30729.17" und "M$ Visual J# 2.0 Redistributable Package - SE". Ohne die beiden läßt sich der Client zumindest unter XP32 auch nicht installieren.
Keine Ahnung wofür die genau gebraucht werden, weiß jemand mehr

[mschoen]

Also der vSphere-Client installiert bevor die eigentliche Client-Inst losgeht noch 2 weitere Bestandteile names "M$ Visual Studio C++ 2008 Redistributable - x86 -9.0.30729.17" und "M$ Visual J# 2.0 Redistributable Package - SE". Ohne die beiden läßt sich der Client zumindest unter XP32 auch nicht installieren.
Keine Ahnung wofür die genau gebraucht werden, weiß jemand mehr

Damit hab ich es auch schon probiert, brachte aber keine Veränderung...