Re: [CentOS] VMware (was Re: current bind version)
On Thu, 2011-02-24 at 22:47 -0600, Les Mikesell wrote: Player isn't good for most of my usage because most of the time I don't want the console display at all - I just connect to the guests remotely with freenx/ssh/vnc when necessary. And I have Server 1.x setups that have run for years with no attention or downtime. I agree that ESXi is better, but it wasn't free when I built the VMs and I'm running some native Centos stuff on the host along with several guests. Anyway, my point was that the fabled library ABI stability of RHEL turned out not to work for VMware Server 2.0. But CentOS did come through with bug-for-bug compatibility as promised, causing the same crashing behavior after the same minor-rev update. I went through this a while back both at work and at home. At work I converted the whole shebang from VMware Server 2.0 over to KVM. At home I went with ESXi. Both were fairly painless to do, though with ESXi you need a Windows box to manage it. Eventually, I'll probably convert the home machine to KVM. Maybe. OTOH, I like not having a boot drive (other than the SD card) on the box. Hmm... (thinking aloud) Is anyone doing KVM on a box from a USB stick or SD card? Saves a disk, and that's what VMware is doing with ESXi... -I ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 02/24/2011 10:47 PM, Les Mikesell wrote: On 2/24/11 8:56 PM, Scott Robbins wrote: On Fri, Feb 25, 2011 at 03:44:32PM +1300, Machin, Greg wrote: snip of good information Rather use ESXi 4.1 and get up and running quickly. If your hardware is not on the supported list there are other lists of tested hardware where people have it running on Unsupported hardware. Player is not a solution if the Virtual machine needs to be running 24/7. It's more suited to testing and demo use. Agreed--I haven't really found server, however, to be all that great for 24/7, so I assumed (and we know what happens when one assumes), that it was being used for testing. For any sort of production use, ESXi 4.1 is quite good. Player isn't good for most of my usage because most of the time I don't want the console display at all - I just connect to the guests remotely with freenx/ssh/vnc when necessary. And I have Server 1.x setups that have run for years with no attention or downtime. I agree that ESXi is better, but it wasn't free when I built the VMs and I'm running some native Centos stuff on the host along with several guests. Anyway, my point was that the fabled library ABI stability of RHEL turned out not to work for VMware Server 2.0. But CentOS did come through with bug-for-bug compatibility as promised, causing the same crashing behavior after the same minor-rev update. The ABI is not for things like VMWare when they screw up their updates ... it is for custom 3rd party software that you have spent $1,000,000.00 having developed that will stop working when the ABI changes. In the case of VMWare, they support RHEL, Fedora, Ubuntu, SuSE, etc. out of the box and they made a mistake with their RH compile. #1 is a far bigger issue than #2. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On Thu, Feb 24, 2011 at 10:36:28PM -0800, David Brian Chait wrote: I think you need to download the VI3 rather than 4.1 to use 32 bit support, but it does work. I have it in production on some older hardware and it has not let me down yet. I believe David is correct. We had some old machines we were going to use with 4.1, but they were 32 bit and so we weren't able to use them. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Oz: Looks dead, smells dead, yet it's moving around. That's interesting. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 2/25/11 4:48 AM, Johnny Hughes wrote: Anyway, my point was that the fabled library ABI stability of RHEL turned out not to work for VMware Server 2.0. But CentOS did come through with bug-for-bug compatibility as promised, causing the same crashing behavior after the same minor-rev update. The ABI is not for things like VMWare when they screw up their updates This was not a VMWare update. It was a glibc update - and the breakage was dramatic, not just the slow memory leak someone else mentioned. ... it is for custom 3rd party software that you have spent $1,000,000.00 having developed that will stop working when the ABI changes. Can you elaborate on that? I thought ABI stabity was a yes or no kind of question. What's different about VMWare other than RH selling a similar product? In the case of VMWare, they support RHEL, Fedora, Ubuntu, SuSE, etc. out of the box and they made a mistake with their RH compile. It seemed really odd - because at least the next few VMWare updates didn't fix it and they aren't exactly new at this game. The multi-distribution support mostly comes from including a bazillion libraries in the package that the distributions refuse to standardize enough to count on, but that doesn't include glibc... The workaround to switch to ESXi or Server 1.x was straightforward enough so I don't need more advice about that, but the situation seemed like more than a simple mistake. Does anyone have inside information on why it happened and wasn't fixed immediately by one side or the other? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 2/25/11 7:33 AM, Scott Robbins wrote: On Thu, Feb 24, 2011 at 10:36:28PM -0800, David Brian Chait wrote: I think you need to download the VI3 rather than 4.1 to use 32 bit support, but it does work. I have it in production on some older hardware and it has not let me down yet. I believe David is correct. We had some old machines we were going to use with 4.1, but they were 32 bit and so we weren't able to use them. There are cpus that are 64 bit (with the lm flag) but don't have hardware virtualization (vt). Not sure if they can run ESXi or not, but with server/player they can run 32-bit guests only. CPUs with the vt option (and in some cases this can be enabled/disabled in the bios) can run 64-bit guests under vmware server/player even if the host runs a 32-bit OS. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On Feb 25, 2011, at 5:48 AM, Johnny Hughes joh...@centos.org wrote: On 02/24/2011 10:47 PM, Les Mikesell wrote: On 2/24/11 8:56 PM, Scott Robbins wrote: On Fri, Feb 25, 2011 at 03:44:32PM +1300, Machin, Greg wrote: snip of good information Rather use ESXi 4.1 and get up and running quickly. If your hardware is not on the supported list there are other lists of tested hardware where people have it running on Unsupported hardware. Player is not a solution if the Virtual machine needs to be running 24/7. It's more suited to testing and demo use. Agreed--I haven't really found server, however, to be all that great for 24/7, so I assumed (and we know what happens when one assumes), that it was being used for testing. For any sort of production use, ESXi 4.1 is quite good. Player isn't good for most of my usage because most of the time I don't want the console display at all - I just connect to the guests remotely with freenx/ssh/vnc when necessary. And I have Server 1.x setups that have run for years with no attention or downtime. I agree that ESXi is better, but it wasn't free when I built the VMs and I'm running some native Centos stuff on the host along with several guests. Anyway, my point was that the fabled library ABI stability of RHEL turned out not to work for VMware Server 2.0. But CentOS did come through with bug-for-bug compatibility as promised, causing the same crashing behavior after the same minor-rev update. The ABI is not for things like VMWare when they screw up their updates ... it is for custom 3rd party software that you have spent $1,000,000.00 having developed that will stop working when the ABI changes. In the case of VMWare, they support RHEL, Fedora, Ubuntu, SuSE, etc. out of the box and they made a mistake with their RH compile. #1 is a far bigger issue than #2. Also, VMware could have made their module load across kernel updates without recompile if they had set their kernel module up to support KABI (kernel ABI) tracking, but they didn't. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On Feb 25, 2011, at 9:01 AM, Les Mikesell lesmikes...@gmail.com wrote: On 2/25/11 7:33 AM, Scott Robbins wrote: On Thu, Feb 24, 2011 at 10:36:28PM -0800, David Brian Chait wrote: I think you need to download the VI3 rather than 4.1 to use 32 bit support, but it does work. I have it in production on some older hardware and it has not let me down yet. I believe David is correct. We had some old machines we were going to use with 4.1, but they were 32 bit and so we weren't able to use them. There are cpus that are 64 bit (with the lm flag) but don't have hardware virtualization (vt). Not sure if they can run ESXi or not, but with server/player they can run 32-bit guests only. CPUs with the vt option (and in some cases this can be enabled/disabled in the bios) can run 64-bit guests under vmware server/player even if the host runs a 32-bit OS. I think the support goes like this: 32-bit OS (VI3) can run 32-bit software virtualization, but not 64-bit virtualization without hardware virtualization support. 64-bit OS (VI4) can't run without hardware virtualization support at all. VMware doesn't see software virtualization as performing well enough to continue supporting modern workloads, so it dropped it in 4.1 I believe. I think 4.0 might have supported 32-bit non-hardware virtualization though. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 25/02/11 14:52, Les Mikesell wrote: On 2/25/11 4:48 AM, Johnny Hughes wrote: Anyway, my point was that the fabled library ABI stability of RHEL turned out not to work for VMware Server 2.0. But CentOS did come through with bug-for-bug compatibility as promised, causing the same crashing behavior after the same minor-rev update. The ABI is not for things like VMWare when they screw up their updates This was not a VMWare update. It was a glibc update - and the breakage was dramatic, not just the slow memory leak someone else mentioned. I don't know this case specifically. But generally speaking, there are some cases where applications are built depending on a bug in a library to work properly. When that bug gets fixed in the library, the application breaks. ABI doesn't ensure that all applications will work forever. It only assures that the application binary interface doesn't change. That means that arguments being passed through library functions does not change, that functions does not disappear, looses or gains more arguments or that the return type from functions doesn't change. It does not guarantee that the behaviour of the functions doesn't change, if the behaviour was wrong to start with. kind regards, David Sommerseth ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 2/25/2011 8:36 AM, Ross Walker wrote: Also, VMware could have made their module load across kernel updates without recompile if they had set their kernel module up to support KABI (kernel ABI) tracking, but they didn't. That was the other strange thing. RHEL5 was never a 'supported' platform, so a stable module wasn't included. I sometimes see conspiracies where they might not exist, but the whole thing felt like running a Lotus product under a Microsoft OS back in the day when ever update would accidentally break the competitors product (all the way through SP6 to NT). And even before the absolute breakage, it was very difficult to stabilize the guest clock. The net effect here was that our internal developers who lean towards Windows anyway but will tolerate Linux if it works just gave up. The Windows-hosted version of Server 2.x didn't have those problems. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On Friday, February 25, 2011 11:04:23 am Les Mikesell wrote: RHEL5 was never a 'supported' platform, so a stable module wasn't included. According to VMware's documentation, RHEL5 was and is a fully supported platform for VMware Server 2.0 (see page 26 of the current 'VMware Server User's Guide' available at vmware.com for confirmation). The binary modules are found, for the x86_64 distribution, in vmware-server-distrib/lib/modules/binary/bld-2.6.18-8.el5-x86_64smp-RHEL5/ VMware Workstation has no issues with the glibc update; VMware is just not properly supporting VMware Server, has nothing to do with Red Hat (Ubuntu is also listed as a supported OS, yet when you do the glibc update that matches the one that causes the issues on RHEL, the same thing happens there). VMware would prefer you run ESX or ESXi instead of 'ye olde' GSX product now known as VMware Server. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
VMware Workstation has no issues with the glibc update; VMware is just not properly supporting VMware Server, has nothing to do with Red Hat (Ubuntu is also listed as a supported OS, yet when you do the glibc update that matches the one that causes the issues on RHEL, the same thing happens there). VMware would prefer you run ESX or ESXi instead of 'ye olde' GSX product now known as VMware Server. VMware server is a dead product and has been dead for many years, VMware refocused all of their efforts to ESXi/ESX back in 2008. -David ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On Fri, Feb 25, 2011 at 9:11 AM, David Brian Chait dch...@invenda.com wrote: VMware Workstation has no issues with the glibc update; VMware is just not properly supporting VMware Server, has nothing to do with Red Hat (Ubuntu is also listed as a supported OS, yet when you do the glibc update that matches the one that causes the issues on RHEL, the same thing happens there). VMware would prefer you run ESX or ESXi instead of 'ye olde' GSX product now known as VMware Server. VMware server is a dead product and has been dead for many years, VMware refocused all of their efforts to ESXi/ESX back in 2008. ... in the server world, maybe. VMWare Workstation is actively maintained and, as Lamar said, it has no issues with the glibc update. Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 2/25/2011 11:24 AM, Akemi Yagi wrote: On Fri, Feb 25, 2011 at 9:11 AM, David Brian Chaitdch...@invenda.com wrote: VMware Workstation has no issues with the glibc update; VMware is just not properly supporting VMware Server, has nothing to do with Red Hat (Ubuntu is also listed as a supported OS, yet when you do the glibc update that matchesthe one that causes the issues on RHEL, the same thing happens there). VMware would prefer you run ESX or ESXi instead of 'ye olde' GSX product now known as VMware Server. VMware server is a dead product and has been dead for many years, VMware refocused all of their efforts to ESXi/ESX back in 2008. ... in the server world, maybe. VMWare Workstation is actively maintained and, as Lamar said, it has no issues with the glibc update. And we didn't see any similar problems with VMWare server hosted on windows. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 02/25/11 8:04 AM, Les Mikesell wrote: Windows-hosted version of Server 2.x didn't have those problems. I found all versions of VMware Server 2.0.x to be unstable under load on multiple different platforms and essentially unusable. That was when I switched those systems over to VBox ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
You may want to try VMware-player if you, (like almost everyone else) preferred 1.x to 2.x. The later versions of player are more like 1.x, allowing you to install an operating system from ISO or whatever, and work quite well with 64 bit CentOS. If you want automation, forget player. Current versions are distributed as installer scripts, not rpm, and I don't think they have fixed the problem/feature that prevents running the script non-interactively. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
I have always had issues with VMware server and compiling of kernel modules, normally ended up costing a couple of days effort .. I have found 2 is more resource intensive than 1. Rather use ESXi 4.1 and get up and running quickly. If your hardware is not on the supported list there are other lists of tested hardware where people have it running on Unsupported hardware. Player is not a solution if the Virtual machine needs to be running 24/7. It's more suited to testing and demo use. Greg Machin Systems Administrator - Linux Infrastructure Group, Information Services -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Scott Robbins Sent: Friday, 25 February 2011 3:14 p.m. To: CentOS mailing list Subject: [CentOS] VMware (was Re: current bind version) On Thu, Feb 24, 2011 at 08:04:08PM -0600, Les Mikesell wrote: Can someone remind me why VMware server 2.x broke with a RHEL/CentOS 5.x glibc update? I switched back to 1.x which I like better anyway, but if the reason for putting up with oldness is to keep that from happening, it didn't work. You may want to try VMware-player if you, (like almost everyone else) preferred 1.x to 2.x. The later versions of player are more like 1.x, allowing you to install an operating system from ISO or whatever, and work quite well with 64 bit CentOS. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Adam: You failed me. Spike: Let's not quibble about who failed who. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On Fri, Feb 25, 2011 at 03:44:32PM +1300, Machin, Greg wrote: snip of good information Rather use ESXi 4.1 and get up and running quickly. If your hardware is not on the supported list there are other lists of tested hardware where people have it running on Unsupported hardware. Player is not a solution if the Virtual machine needs to be running 24/7. It's more suited to testing and demo use. Agreed--I haven't really found server, however, to be all that great for 24/7, so I assumed (and we know what happens when one assumes), that it was being used for testing. For any sort of production use, ESXi 4.1 is quite good. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Spike: What's Big Blue doing anyway? The Judge: I am preparing. Spike: It's interesting to me that preparing looks a great bit like sitting on your ass. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 2/24/11 8:56 PM, Scott Robbins wrote: On Fri, Feb 25, 2011 at 03:44:32PM +1300, Machin, Greg wrote: snip of good information Rather use ESXi 4.1 and get up and running quickly. If your hardware is not on the supported list there are other lists of tested hardware where people have it running on Unsupported hardware. Player is not a solution if the Virtual machine needs to be running 24/7. It's more suited to testing and demo use. Agreed--I haven't really found server, however, to be all that great for 24/7, so I assumed (and we know what happens when one assumes), that it was being used for testing. For any sort of production use, ESXi 4.1 is quite good. Player isn't good for most of my usage because most of the time I don't want the console display at all - I just connect to the guests remotely with freenx/ssh/vnc when necessary. And I have Server 1.x setups that have run for years with no attention or downtime. I agree that ESXi is better, but it wasn't free when I built the VMs and I'm running some native Centos stuff on the host along with several guests. Anyway, my point was that the fabled library ABI stability of RHEL turned out not to work for VMware Server 2.0. But CentOS did come through with bug-for-bug compatibility as promised, causing the same crashing behavior after the same minor-rev update. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 25/02/2011 1:13 PM, Scott Robbins wrote: On Thu, Feb 24, 2011 at 08:04:08PM -0600, Les Mikesell wrote: Can someone remind me why VMware server 2.x broke with a RHEL/CentOS 5.x glibc update? I switched back to 1.x which I like better anyway, but if the reason for putting up with oldness is to keep that from happening, it didn't work. You may want to try VMware-player if you, (like almost everyone else) preferred 1.x to 2.x. The later versions of player are more like 1.x, allowing you to install an operating system from ISO or whatever, and work quite well with 64 bit CentOS. I have begun to switch all my hosts without hardware virtualization, so can't use ESXi, to VirtualBox. With the addition of an init.d script it works well as a headless virtual host. The VirtualBox commandline support is far superior to VMware Server. With the help of puppet I have automated the entire host install, configuration, guest vm creation and guest install and configuration. VirtualBox was far easier to wrap puppet around than VMware Server was too. Ben ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 2/24/11 8:56 PM, Scott Robbins wrote: On Fri, Feb 25, 2011 at 03:44:32PM +1300, Machin, Greg wrote: snip of good information Rather use ESXi 4.1 and get up and running quickly. If your hardware is not on the supported list there are other lists of tested hardware where people have it running on Unsupported hardware. Player is not a solution if the Virtual machine needs to be running 24/7. It's more suited to testing and demo use. Agreed--I haven't really found server, however, to be all that great for 24/7, so I assumed (and we know what happens when one assumes), that it was being used for testing. For any sort of production use, ESXi 4.1 is quite good. Player isn't good for most of my usage because most of the time I don't want the console display at all - I just connect to the guests remotely with freenx/ssh/vnc when necessary. And I have Server 1.x setups that have run for years with no attention or downtime. I agree that ESXi is better, but it wasn't free when I built the VMs and I'm running some native Centos stuff on the host along with several guests. Anyway, my point was that the fabled library ABI stability of RHEL turned out not to work for VMware Server 2.0. But CentOS did come through with bug-for-bug compatibility as promised, causing the same crashing behavior after the same minor-rev update. Simple solution really, bring up an ESXi box and use Vmware's free converter tool to convert the old VMs to ESXi (in most cases while they are running). It is a pretty seamless changeover, and ESXi is far better from a supportability and performance standpoint. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 02/24/11 9:18 PM, Ben wrote: I have begun to switch all my hosts without hardware virtualization, so can't use ESXi, to VirtualBox. ESXi only needs hardware virtualization support for 64bit guest VMs. as long as you can live with 32bit VMs, you're good with older CPUs. I have it running a dozen or more VMs on a quad Opteron 850 system (4 x single core 2.4Ghz) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
On 25/02/2011 4:51 PM, John R Pierce wrote: On 02/24/11 9:18 PM, Ben wrote: I have begun to switch all my hosts without hardware virtualization, so can't use ESXi, to VirtualBox. ESXi only needs hardware virtualization support for 64bit guest VMs. as long as you can live with 32bit VMs, you're good with older CPUs. I have it running a dozen or more VMs on a quad Opteron 850 system (4 x single core 2.4Ghz) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Thanks, I did not know that. I could've swarn I had tested it on some old IBM x306. Will have to take a look into that. I still like that automation that I get with CentOS, puppet and VirtualBox. Ben ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] VMware (was Re: current bind version)
Thanks, I did not know that. I could've swarn I had tested it on some old IBM x306. Will have to take a look into that. I still like that automation that I get with CentOS, puppet and VirtualBox. Ben I think you need to download the VI3 rather than 4.1 to use 32 bit support, but it does work. I have it in production on some older hardware and it has not let me down yet. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
