Hi we have vmware-workstation and vmware-console in the tree. Hereby I would like to make a humble request to include an ebuild for vmware-gsx and vmware-mui. Both can be downloaded from www.vmware.com and evaluated for free. You have no idea how happy you would make be by including these ebuilds in the tree. No more Windows, SUSE or Red Hat, yahoo!!! I want to thank you a lot in advance for your time and effort you might put in this request. Gentoo rules!!!
John, I will be happy to look into the feasibility of doing this. It will not be soon, however. This will likely take a few weeks. I need to find a box at work that I can mess around with to try this out. Chris, do you see any major reasons why including these ebuilds would be a bad idea? If we do it, we probably want to have a vmware-gsx-eval and vmware-gsx ebuild. It does not make sense to have an ebuild only for the eval and not for the real deal. Hopefully, the differences in the installation process will be virtually nil.
Hi Josh, thanks a lot for your quick response. I'm looking forward to try the ebuild. Regarding the differences between "evaluation version" and "normal version". There are none. The only difference is the serialnumber you enter. I mentioned the evaluation version, because the people who don't need to buy VMWare GSX server but have the skills to create an ebuild can download VMWare legally and create/test an ebuild.
Josh, The installation would be the same as with VMware Workstation. It installs the "demo" version by default and supplying a proper serial number registers it. I see no problem with adding these ebuilds to portage. If you need any help, let me know. Also, if you're interested in maintaining VMware Workstation, I'd have no problem with that. With my new role as QA Manager for Release Engineering, I have less time to work on VMware stuff these days. That and my primary box is no longer x86, but amd64 (which I am happy to say runs VMware Workstation perfectly).
OK, sounds great. I will see what I can do.
Hi Josh, since you have responded positive on my bold request (muuhaha). Ik would like to make an extra addition to this request; besides vmware-gsx and vmware-mui would you be so kind to add vmware-tools to this request. Thanks !!!
Hi Josh, I just saw in the Gentoo Weekly Newsletter that Gentoo received a donation from EMC for a license of VMWare GSX Server (http://www.gentoo.org/news/en/gwn/20040816-newsletter.xml). If you still need a box for assisting with the creation of ebuilds you might be able to use this one. Also posted this message to make sure that effort is not duplicated and an other person is creating ebuilds for the Gentoo VMWare environment at the same time as you are.
Josh- could you update the status of this ticket? The last updates appear to be 60-90 days ago. I am also looking to assist w/ creating appropriate vmware gsx/tools/etc ebuilds for gentoo and have access to two gsx servers here in my office. Would you like any help?
Matthew- do you have something available? Maybe I can help you with testing/developing.
Is this ticket still alive, or should I create a new one and hope it doesn't get closed a duplicate. I would love to see an ebuild for GSX and the MUI in portage.
If you file another bug for this, it will get marked as a duplicate. As for an ebuild, the current active VMware team is essentially myself, so it will get done when I get to it. Attaching a working ebuild to this bug report will get it added faster. Waiting for me to eventually get around to it is probably the slowest method.
I've migrated most of my work over to ESX from GSX so I'm not sure I want to handle this ticket. However, if the package really is needed, i'll write it or maintain it since I dont think there are any other devs in the herd with GSX access. That said, I think most users will find ESX a much better value proposition than GSX. I'd really recommend users go with workstation or esx.
Matthew, I think an ebuild for GSX server would still be much appreciated by many gentoo users. Many (like us working for smaller organization) can't really afford ESX but are relying on GSX.
Hi, VMware just released their VMware Server (previously known as GSX server) for free: http://www.vmware.com/products/server/ It would really be great if someone with the required skills had the time to create ebuilds for the new VMware Server. Thank's a lot in advance for the time and efforts you might put in this request. /jmc
I'd very much like to, only I can't get the thing to download. Even with an already registered account it asks me a couple of questions and then dies with an internal server error when attempting to download. Once I get a copy I'll start looking into making an ebuild for it...
Turns out (thanks to Christian Hammond) that it's a bug in that the vmware web guys are working on, and for the time being the person who registers has to include a state and a US zipcode. Hopefully I'll get something going this weekend, but since the beta software isn't supposed to interact with old server versions, it would still be worthwhile getting the gsx-console ebuild into portage...
*** Bug 121866 has been marked as a duplicate of this bug. ***
I've just attached an ebuild for the vmware-server-console package to bug 119330. I'll be working on a full vmware-server package soon...
OK, so vmware is officially depreciating GSX and annoucing that vmware-server will take its place. Essentially, vmware needed a product to compete with XEN in the developer space where cost/new features are critical. So, vmware server is free and most of new beta type stuff will go into server, and only when stable, make it into ESX. So, it seems from a gentoo perspective we shouldnt spend much time at all going forward with GSX since we never had good support to start with and its a bit late. We can just encourage our users to migrate to vmware server earlier. I think Chris has been doing a great job supporting workstation, I've started to take over ESX related ebuilds, and we probably need someone to take over vmware server stuff. It looks like Mike Auty is doing that. Note that from my perspective, vmware server is still substantially deficient with regards to ESX. For development purposes, you can get a VMTN license for only a few hundred $$ which allows you to run a minimally limited version of ESX on several boxes. For any serious production purposes, a valid ESX license would be substantially more scaleable and more reliable than server. Note, that I worked with GSX on and off for over a year and just got tired of all the different issues it would have. On the other hand, the ESX machines have uptimes of several years and support twice the number of virtual machines as GSX with greater management. So, the above is really why I am holding back somewhat on getting involved with the non esx related ebuilds in gentoo. Going forward, if we need to resolve more naming, directory/path, symbolic link stuff so all the ebuilds work together - I'm all for it. On my laptop, I use both vmware-workstation and vmware-esx-console w/o problem however.
Why do I get the feeling I just got volunteered for something? 5:) Well, it turns out the nice people at VMware Support don't support Gentoo Linux. Even though I was posting a bug report. To help them improve their product. Nice. They've got a problem checking that the page_offset variable is the same for the running kernel as the source directory you point it to when building the modules. Sadly, I don't even know what a page_offset is when it's at home, but I'll keep plugging away and post what I can when I can back here... I can also post my the development ebuild I'm tryng to test out for server at the moment if people are interested...
I'd like to test our your ebuild, if it isn't too much trouble.
Created attachment 79240 [details] vmware-server-1.0.0.20925.ebuild Ok, a lot of disclaimers about this one. IT IS BROKEN. Ok, now here's as much else as I've got. It's heavily based upon (read copied from) the vmware-workstation 5.5.1 ebuild, and as such will require some of the auxiliary files from the files directory of portage, I'll not spam them to this bug unless I get a direct request to, but the changes should be obvious. Renames for the two patches (they both seem to apply properly) and a bit of editing the environment file (that starts 90vmware). It seems to install everything in the places it needs to, and should work, however whenever I've tried to get my copy of console to connect to it, console just hangs at 100% CPU. It's not clear if this is a console error or a server error, so I'm trying to hook up a windows copy of the console (which should install correctly). Please note this won't work with kernels newer than about 2.6.13, because of the way PAGE_OFFSET is verified, I'm working on that one, but I'd like to get a copy of server running from the ebuild first. Also note, there may be an error message about not being able to restart xinetd, that's just because it thinks /etc/init.d is actually /etc/vmware/init.d, a symlink should fix this but it's a low priority. Finally if anyone does figure what's going wrong with my setup, or gets it working, do please let me know cause at the moment I've had server working successfully once from their install script and then never again no matter what I've tried (ebuild, install script, everything). Hope this is of some use, sorry if it's a bit disorganized but I'm trying to squeeze this in amongst everything else I'm doing so it's all a bit hectic, sorry...
DOH! Well, I discovered that xinetd is now set with sensible defaults, to only allow access from localhost. No wonder the client was timing out. That seems to have fixed it, so it's quite possible that that ebuild may do a valid install (once you edit /etc/xinetd.conf). Lemme know if you get good results/bad results/weird results and I'll keep trying to fix it up until it's ready for use...
Created attachment 79249 [details] vmware-server-1.0.0.20925.ebuild - Version 0.0.2 Ok, looks like that last one was a bit old, and thus even more broken than this one. THIS IS STILL BROKEN. But, having said that, it may mostly work. All the same things still apply from comment 21, but in addition. Don't forget to allow xinetd to talk to other machines. I'm probably just going to mention this in red at the end of the ebuild, since I'd hate to be the cause of a security concern. Also, I still haven't fixed the xinetd symlink problem, but if before you run the perl config script you put a symlink from /etc/init.d/xinetd to /etc/vmware/init.d, then it should all go off without a hitch. Finally, I also haven't managed to patch the config script to check for the correct PAGE_OFFSET, that's highest on my priority list for the server ebuild, and should be dealt with next. Also, I'm probably going to try and update the console version so that it's build more like the workstation build than the old console builds. It might also be worth making a eclass, but I've never ventured that far yet... As always, if anyone else wants to help out or contribute, don't hesitate to get in touch with me, I can use all the help I can get!
Created attachment 79317 [details] vmware-server-1.0.0.20925.ebuild - Version 0.0.3 Right, that ebuild was also broken, but in a slightly more subtle way. It lets you connect to the server, but will then fail to actually boot the machine, since it's running as the wrong user. I really haven't had a chance to look into permissions on this thing (and the numerous perl warnings that portage helpfully points out during installation are also a bit of a bad thing(tm)), however this new ebuild now gives Suid root permission to /opt/vmware/server/sbin/vmware-authd (which the vmware installer does anyway). This will allow any user in the vmware group to actually boot up virtual machines. Sadly if you're not in the vmware group, you can still connect to the vmware server, but if you try to boot a machine you'll hang the server process and someone will have to manually delete the pid file from the /var/run/vmware directory. Doing a little digging it looks as though permissions on the /etc/vmware/config file may be the answer, but I still haven't gotten that far. Also this should now solve the xinetd symlink problem. I'm off to look into the only-works-with-less-than-2.6.13ish kernel problem...
Created attachment 79337 [details] vmware-server-1.0.0.20925.ebuild - Version 0.0.4 Latest version, this now includes a patch (which will be attached after this), to allow building on at least the 2.6.16_rc2 kernel, and probably all the lower ones between 2.6.16_rc2 and 2.6.12. Still haven't found a way to have vmware server *deny* a valid user on the box from getting into the server. If anyone can help, it'd be greatly appreciated... Next thing to look into is tarting up the vmware-server-console ebuild (check the other relevant bug for that one, I don't remember the number off the top of my head), and also to look into proper dependencies for this ebuild...
Created attachment 79338 [details, diff] vmware-server-1.0.0.20925-config3.patch Patch required to configure vmware-server on kernel sources above 2.6.12ish (maybe 13).
Well, an updated gsx-console ebuild has been committed, and since that's where I had been maintaining my vmware-server-console ebuild, I decided I'd start a new bug to track the ebuilds of both server and server-console. That means that if you'd like to keep an eye on the (currently) free vmware-server and it's ebuilds that I've been developing, they're now all being housed in bug 122500, and I'm probably going to leave this bug alone. Unless there's a lot of demand still for a deprecated gsx server ebuild, one probably won't get made for this, so it may be worth marking this bug as WONTFIX or similar...
unfortunately I dont have a dev-box to fix this myself and test, but looks like a modularx problem here. Can I suggest changing the DEPEND to: x86? ( || ( ( x11-libs/libXrandr x11-libs/libXcursor x11-libs/libXinerama x11-libs/libXi ) virtual/x11 ) || ( x11-libs/libXft virtual/xft ) virtual/xft is still xorg-x11, whereas all it needs is the Xft libs I think?
oh, and you might want to include a trialing bracket on that :)
also worth noting, it looks as though it requires glibc-2.3.6
Comment on attachment 79337 [details] vmware-server-1.0.0.20925.ebuild - Version 0.0.4 This is now obsolete, please see the latest version in bug 122500. Sorry for the move, but these aren't really gsx ebuilds, they're for vmware-server, so I've filed them under a new bug. Your CC will *not* be transfered automatically, please add yourself to the new bug if you'd like further updates.
Thanks John, I'll fix these dependencies up in version 0.0.6, which I'll be putting in bug 122500 when I get the pam problems I've been having sorted. Also, when you say it requires glibc-2.3.6, is that because it suffered problems with 2.3.5? I'll put in >=glibc-2.3.6 for the time being, but that may have consequences on getting this marked stable with any speed... Thanks again for your help, I really appreciate it! Any other pointers or comments will be greatfully accepted! 5:)
it depends on glibc-2.3.6 because thats what its built against :) It wont run with anything lower. Following on from that, why is this bug not closed as a duplicate? I'll do so now. Please email me if this you feel this is in error. *** This bug has been marked as a duplicate of 122500 ***
