I had promised to do this and post my results a week ago and got thoroughly tied up over the holidays - sorry about that. It was a good Christmas for us though! :)
So - I did get around to loading up a server with the latest version of F10 (32-bit in this case) to run the 32-bit version of VMware Server 2.0 (build 122956) to try and answer the burning question: Does selinux need to be disabled for VMware Server to run properly on F10?
I know the inpatient out there can't wait to read the whole post, so here's the answer:
Yes.
According to our testing (a friend of mine who also frequents this list was here too), the current version of VMware Server DOES NOT RUN on F10 (32-bit) unless selinux is DISABLED. Permissive mode doesn't cut it - it still causes VMware Server to not run.
Here are the details: Server: "Whitebox" Supermicro 1U chassis, dual 2.4GHz Pentium Xeon processors, 4GB RAM, Dual Gig-E NICs, dual 250GB IDE drives
OS: F10 32-bit, with all patches as of 12-28-08 Kernel: 2.6.27.9-159.fc10 (PAE version - required to see the full 4GB)
We loaded a fresh copy F10 with all of the required development tools and supporting stuff VMware Server needs to compile, and left selinux in its default (enforcing) mode and targeted policy. The system was intentionally updated with all of the latest available patches. After rebooting (kernel update that included a switch to the PAE kernel), we then installed VMware Server from the RPM via Package Kit. The initial RPM install went as expected with no errors or issues beyond the warning that the RPM is not signed (Request to VMware: Please, PLEASE make sure that you always sign your RPMs!).
Next up was to configure the system. We fired up a terminal window, switched user to root, and then launched vmware-config.pl as normal. The script properly found everything it needed, set up the virtual networks, and compiled all of the modules against the PAE kernel with no errors at all. All of the services reported in as having started successfully when the script exited, which was when the trouble started.
We immediately picked up an selinux error saying that one of the modules required the ability to use text relocation. No big deal here, which is why I don't remember off hand which module committed the offense. I'll go back and pull it up next chance - I'm on a different system right now. The selinux troubleshooter gave us the required command to address this issue, so we fixed the problem and off we went.
...Or so we thought.
It seems that something else in selinux is interfering with a new VMware Server 2.0 service called VirtualMachines. I'm not sure what the problem is, how it happens, or why. What happens is that you can launch Firefox to talk to VMware server (http://localhost:8222 in this case) and get the VMware Server login page. However, from there you are unable to login. The system times out with a message basically saying that communication with the back-end server processes has been lost. Further checking (service vmware status) shows that several VMware Server services are actually NOT running.
Upon trying to restart the vmware services (service vmware restart), we see that the VirtualMachines service has failed. There are no errors I can see, and nothing in dmesg out of the ordinary.
Next, we placed selinux into permissive mode to see if anything might pop up or change, and then rebooted the system. We saw exactly the same behavior from VMware Server as before when selinux was in enforcing mode.
Finally, we disabled selinux altogether and rebooted once more. This time, VMware Server came up and ran flawlessly. In fact, it was impressively fast given the age of the hardware.
Just for grins, we then completely erased VMware Server, rebooted, and double-checked to make sure everything about it was completely gone from the system. We then re-installed it using the exact same procedure as before. VMware Server installed and ran flawlessly. In fact, just to be sure again, we rebooted the server one more time. Again VMware Server came up and ran without issues.
Thus, in our testing of this, it is clear there are multiple issues with VMware Server and selinux. One of the issues is that a specific module requires text relocation, which is easily solved. The other issue is going to be a little more difficult to troubleshoot, but clearly there is something that conflicts between selinux and one of the new VMware Server services, and the only way to get around it at this point is to disable selinux.
I'll have the system handy for the next day or so to do some additional testing, but then I have to put it back into production. Let me know what specifics I should look for next to find the source of the problem.
Cheers,
Chris
-- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.
--Socrates
On Monday 29 December 2008 11:09:48 Christopher A. Williams wrote:
Thus, in our testing of this, it is clear there are multiple issues with VMware Server and selinux. One of the issues is that a specific module requires text relocation, which is easily solved. The other issue is going to be a little more difficult to troubleshoot, but clearly there is something that conflicts between selinux and one of the new VMware Server services, and the only way to get around it at this point is to disable selinux.
Thanks for this report, Christopher. I can't comment because I'm still not running Ver 2, but my issue with your previous posts on this question is addressed by this. Hopefully, Dan Walsh will appear before you lose access to the system and can try to help figure things out - he's always been extremely helpful to me when he's dealt with issues I've had.
On Mon, 2008-12-29 at 12:27 -0500, Claude Jones wrote:
On Monday 29 December 2008 11:09:48 Christopher A. Williams wrote:
Thus, in our testing of this, it is clear there are multiple issues with VMware Server and selinux. One of the issues is that a specific module requires text relocation, which is easily solved. The other issue is going to be a little more difficult to troubleshoot, but clearly there is something that conflicts between selinux and one of the new VMware Server services, and the only way to get around it at this point is to disable selinux.
Thanks for this report, Christopher. I can't comment because I'm still not running Ver 2, but my issue with your previous posts on this question is addressed by this. Hopefully, Dan Walsh will appear before you lose access to the system and can try to help figure things out - he's always been extremely helpful to me when he's dealt with issues I've had.
Well, the good news is I have to put this server back into production so that I can work on the other server. It's the identical hardware / software combo, but running on F9. We're going to transfer the VMs across to the freshly loaded F10 box and then do this all over again with the other machine.
The real issue for me is that I'll be traveling to London next week on business, and with no VPN access available for this, I'll be just a little too far away to get to either server. I'll still monitor the list though, and it seems several others have been able to reproduce exactly what I have found. Hopefully between all of us we can figure out what's going on here.
Cheers,
Chris
-- ==================================== "If you get to thinkin' you're a person of some influence, try orderin' someone else's dog around."
--Cowboy Wisdom
-------- Original Message -------- Subject: VMware Server 2.0, selinux, and F10 From: Christopher A. Williams chriswfedora@cawllc.com To: fedora-list@redhat.com Date: 12/29/2008 10:09 AM
Yes.
I can confirm your results. I've had SELinux disabled for a few years and just turned it on. Same results with the login page. VMWare Server 2 was working fine with SELinux set to Disabled. 32-bit machine. non-PAE kernel.
Note: I've dumped VMWare for VirtualBox now that 2.1.0 has network bridging alleviated.
Christopher A. Williams a écrit :
According to our testing (a friend of mine who also frequents this list was here too), the current version of VMware Server DOES NOT RUN on F10 (32-bit) unless selinux is DISABLED. Permissive mode doesn't cut it - it still causes VMware Server to not run.
Same diagnostic for me.
I've run VMware server 1.0.x without any issue with SElinux in permissive mode (until F9).
With VMWare server 2.0 SElinux must be disabled :( (same issue under F9 and F10)
It seems there is no communication between client and server (even if both on same machine). And "service vmware stop" hangs...
Really annoying (I need Selinux)
I don't understand how "permissive" mode can block something... We need a Selinux gourou..
++
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Christopher A. Williams wrote:
I had promised to do this and post my results a week ago and got thoroughly tied up over the holidays - sorry about that. It was a good Christmas for us though! :)
So - I did get around to loading up a server with the latest version of F10 (32-bit in this case) to run the 32-bit version of VMware Server 2.0 (build 122956) to try and answer the burning question: Does selinux need to be disabled for VMware Server to run properly on F10?
I know the inpatient out there can't wait to read the whole post, so here's the answer:
Yes.
According to our testing (a friend of mine who also frequents this list was here too), the current version of VMware Server DOES NOT RUN on F10 (32-bit) unless selinux is DISABLED. Permissive mode doesn't cut it - it still causes VMware Server to not run.
Here are the details: Server: "Whitebox" Supermicro 1U chassis, dual 2.4GHz Pentium Xeon processors, 4GB RAM, Dual Gig-E NICs, dual 250GB IDE drives
OS: F10 32-bit, with all patches as of 12-28-08 Kernel: 2.6.27.9-159.fc10 (PAE version - required to see the full 4GB)
We loaded a fresh copy F10 with all of the required development tools and supporting stuff VMware Server needs to compile, and left selinux in its default (enforcing) mode and targeted policy. The system was intentionally updated with all of the latest available patches. After rebooting (kernel update that included a switch to the PAE kernel), we then installed VMware Server from the RPM via Package Kit. The initial RPM install went as expected with no errors or issues beyond the warning that the RPM is not signed (Request to VMware: Please, PLEASE make sure that you always sign your RPMs!).
Next up was to configure the system. We fired up a terminal window, switched user to root, and then launched vmware-config.pl as normal. The script properly found everything it needed, set up the virtual networks, and compiled all of the modules against the PAE kernel with no errors at all. All of the services reported in as having started successfully when the script exited, which was when the trouble started.
We immediately picked up an selinux error saying that one of the modules required the ability to use text relocation. No big deal here, which is why I don't remember off hand which module committed the offense. I'll go back and pull it up next chance - I'm on a different system right now. The selinux troubleshooter gave us the required command to address this issue, so we fixed the problem and off we went.
...Or so we thought.
It seems that something else in selinux is interfering with a new VMware Server 2.0 service called VirtualMachines. I'm not sure what the problem is, how it happens, or why. What happens is that you can launch Firefox to talk to VMware server (http://localhost:8222 in this case) and get the VMware Server login page. However, from there you are unable to login. The system times out with a message basically saying that communication with the back-end server processes has been lost. Further checking (service vmware status) shows that several VMware Server services are actually NOT running.
Upon trying to restart the vmware services (service vmware restart), we see that the VirtualMachines service has failed. There are no errors I can see, and nothing in dmesg out of the ordinary.
Next, we placed selinux into permissive mode to see if anything might pop up or change, and then rebooted the system. We saw exactly the same behavior from VMware Server as before when selinux was in enforcing mode.
Finally, we disabled selinux altogether and rebooted once more. This time, VMware Server came up and ran flawlessly. In fact, it was impressively fast given the age of the hardware.
Just for grins, we then completely erased VMware Server, rebooted, and double-checked to make sure everything about it was completely gone from the system. We then re-installed it using the exact same procedure as before. VMware Server installed and ran flawlessly. In fact, just to be sure again, we rebooted the server one more time. Again VMware Server came up and ran without issues.
Thus, in our testing of this, it is clear there are multiple issues with VMware Server and selinux. One of the issues is that a specific module requires text relocation, which is easily solved. The other issue is going to be a little more difficult to troubleshoot, but clearly there is something that conflicts between selinux and one of the new VMware Server services, and the only way to get around it at this point is to disable selinux.
I'll have the system handy for the next day or so to do some additional testing, but then I have to put it back into production. Let me know what specifics I should look for next to find the source of the problem.
Cheers,
Chris
--
By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.
--Socrates
Must be a kernel issue, have you opened a bugzilla?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel J Walsh wrote:
Christopher A. Williams wrote:
I had promised to do this and post my results a week ago and got thoroughly tied up over the holidays - sorry about that. It was a good Christmas for us though! :)
So - I did get around to loading up a server with the latest version of F10 (32-bit in this case) to run the 32-bit version of VMware Server 2.0 (build 122956) to try and answer the burning question: Does selinux need to be disabled for VMware Server to run properly on F10?
I know the inpatient out there can't wait to read the whole post, so here's the answer:
Yes.
According to our testing (a friend of mine who also frequents this list was here too), the current version of VMware Server DOES NOT RUN on F10 (32-bit) unless selinux is DISABLED. Permissive mode doesn't cut it - it still causes VMware Server to not run.
Here are the details: Server: "Whitebox" Supermicro 1U chassis, dual 2.4GHz Pentium Xeon processors, 4GB RAM, Dual Gig-E NICs, dual 250GB IDE drives
OS: F10 32-bit, with all patches as of 12-28-08 Kernel: 2.6.27.9-159.fc10 (PAE version - required to see the full 4GB)
We loaded a fresh copy F10 with all of the required development tools and supporting stuff VMware Server needs to compile, and left selinux in its default (enforcing) mode and targeted policy. The system was intentionally updated with all of the latest available patches. After rebooting (kernel update that included a switch to the PAE kernel), we then installed VMware Server from the RPM via Package Kit. The initial RPM install went as expected with no errors or issues beyond the warning that the RPM is not signed (Request to VMware: Please, PLEASE make sure that you always sign your RPMs!).
Next up was to configure the system. We fired up a terminal window, switched user to root, and then launched vmware-config.pl as normal. The script properly found everything it needed, set up the virtual networks, and compiled all of the modules against the PAE kernel with no errors at all. All of the services reported in as having started successfully when the script exited, which was when the trouble started.
We immediately picked up an selinux error saying that one of the modules required the ability to use text relocation. No big deal here, which is why I don't remember off hand which module committed the offense. I'll go back and pull it up next chance - I'm on a different system right now. The selinux troubleshooter gave us the required command to address this issue, so we fixed the problem and off we went.
...Or so we thought.
It seems that something else in selinux is interfering with a new VMware Server 2.0 service called VirtualMachines. I'm not sure what the problem is, how it happens, or why. What happens is that you can launch Firefox to talk to VMware server (http://localhost:8222 in this case) and get the VMware Server login page. However, from there you are unable to login. The system times out with a message basically saying that communication with the back-end server processes has been lost. Further checking (service vmware status) shows that several VMware Server services are actually NOT running.
Upon trying to restart the vmware services (service vmware restart), we see that the VirtualMachines service has failed. There are no errors I can see, and nothing in dmesg out of the ordinary.
Next, we placed selinux into permissive mode to see if anything might pop up or change, and then rebooted the system. We saw exactly the same behavior from VMware Server as before when selinux was in enforcing mode.
Finally, we disabled selinux altogether and rebooted once more. This time, VMware Server came up and ran flawlessly. In fact, it was impressively fast given the age of the hardware.
Just for grins, we then completely erased VMware Server, rebooted, and double-checked to make sure everything about it was completely gone from the system. We then re-installed it using the exact same procedure as before. VMware Server installed and ran flawlessly. In fact, just to be sure again, we rebooted the server one more time. Again VMware Server came up and ran without issues.
Thus, in our testing of this, it is clear there are multiple issues with VMware Server and selinux. One of the issues is that a specific module requires text relocation, which is easily solved. The other issue is going to be a little more difficult to troubleshoot, but clearly there is something that conflicts between selinux and one of the new VMware Server services, and the only way to get around it at this point is to disable selinux.
I'll have the system handy for the next day or so to do some additional testing, but then I have to put it back into production. Let me know what specifics I should look for next to find the source of the problem.
Cheers,
Chris
--
By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher.
--Socrates
Must be a kernel issue, have you opened a bugzilla?
Looks like the following bug covers the problem.
https://bugzilla.redhat.com/show_bug.cgi?id=464899
-
Christopher A Williams -
Claude Jones -
Daniel J Walsh -
Michael Cronenworth -
Remi Collet