Seite 1 von 2

vSphere Client für Linux

Verfasst: 14.05.2010, 14:19
von mop
Hallo,

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

Danke mop

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

Gruß Peter

Verfasst: 14.05.2010, 14:32
von continuum
Mecker hier
http://communities.vmware.com/thread/49061?tstart=50

hilft zwar nicht aber beruhigt vielleicht etwas ;-)

Verfasst: 14.05.2010, 15:07
von 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 ...

Verfasst: 14.05.2010, 15:12
von Dayworker
Da ist es wohl wirklich am einfachsten/sinnvollsten, eine Win-VM mit dem Vi-/vSphere-Clienten aufzusetzen.

Verfasst: 14.05.2010, 15:23
von 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) ...

Verfasst: 14.05.2010, 15:28
von Dayworker
Also mit 2 VMs, wobei eine einen ESX(i) hostet, könnte man das ausprobieren...

Verfasst: 14.05.2010, 15:41
von 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 ... ;)

Verfasst: 14.05.2010, 16:06
von 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

Verfasst: 14.05.2010, 16:15
von 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.

Verfasst: 14.05.2010, 16:24
von McStarfighter
Naja, es muß ja nicht DIESES Wochenende sein ... ;)

Verfasst: 14.05.2010, 16:46
von 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 ;-)
8)

Verfasst: 14.05.2010, 16:56
von McStarfighter
Hm, dann sollte es doch unter Wine kein Problem sein ... Warum kommt da nur im VMTN keiner drauf? "grübel"

Verfasst: 14.05.2010, 23:01
von 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?

Verfasst: 15.05.2010, 00:04
von McStarfighter
Welche Wine-Version? Welches Linux? Wie bist du genau vorgegangen?

Verfasst: 15.05.2010, 00:26
von mschoen
McStarfighter hat geschrieben: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

Verfasst: 15.05.2010, 00:50
von 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 :?:

Verfasst: 15.05.2010, 01:10
von 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...

Verfasst: 15.05.2010, 01:14
von 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 ...

Verfasst: 15.05.2010, 17:11
von mschoen
Auch mit der .44 ändert sich bei mir nichts...

Verfasst: 15.05.2010, 18:38
von McStarfighter
Sehr sehr ärgerlich ... Ahnung vom Debugging müßte man haben ...

Verfasst: 15.05.2010, 19:05
von 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.

Verfasst: 15.05.2010, 20:14
von 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

Verfasst: 15.05.2010, 20:43
von 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 :?:

Verfasst: 15.05.2010, 20:51
von mschoen
Dayworker hat geschrieben: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...