Re: value of RAM reported not correct in SLC 5.6
Le 17/06/2011 17:10, Lamar Owen a écrit : http://serverfault.com/questions/46600/rhel5-xen-dom0-max-memory KVM and Virtualization are both groups; installing the Virtualization group pulls in kernel-xen; this means you get a DomO instead of the kernel on bare metal, and you hit the DomO configured limit. Yes, I confused with SL 6.0 (RHEL 6.0) where Xen support has been removed, in favor of KVM . So it is indeed a limitation of Xen, with host as Dom0. Alain -- == Alain Péan - LPP/CNRS Administrateur Système/Réseau Laboratoire de Physique des Plasmas - UMR 7648 Observatoire de Saint-Maur 4, av de Neptune, Bat. A 94100 Saint-Maur des Fossés Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33 ==
Re: value of RAM reported not correct in SLC 5.6
On Friday, June 17, 2011 10:54:45 AM you wrote: > This seems to me a little bit weird. I am myself using KVM, but with > less than 32 GB on the host, and I am not aware that the system itself > (the host) becomes the first VM. I think it is doubtful, perhaps it > would stand better for Xen ? http://serverfault.com/questions/46600/rhel5-xen-dom0-max-memory KVM and Virtualization are both groups; installing the Virtualization group pulls in kernel-xen; this means you get a DomO instead of the kernel on bare metal, and you hit the DomO configured limit. On a CentOS 5.6 box I have here: # yum groupinstall Virtualization . Setting up Group Process Checking for new repos for mirrors Resolving Dependencies --> Running transaction check ---> Package gnome-applet-vm.i386 0:0.1.2-1.el5 set to be updated --> Processing Dependency: libxenstore.so.3.0 for package: gnome-applet-vm ---> Package kernel-xen.i686 0:2.6.18-238.12.1.el5 set to be installed Dependencies Resolved Installing: gnome-applet-vm i386 0.1.2-1.el5 base 76 k kernel-xeni686 2.6.18-238.12.1.el5 updates18 M libvirt i386 0.8.2-15.el5_6.4updates 3.0 M virt-manager i386 0.6.1-13.el5.centos updates 1.6 M virt-viewer i386 0.0.2-3.el5 base 25 k xen i386 3.0.3-120.el5_6.2 updates 1.9 M Installing for dependencies: bridge-utils i386 1.1-2 base 27 k e4fsprogs-libsi386 1.41.12-2.el5 base 108 k gnome-python2-gnomekeyring i386 2.16.0-3.el5base 16 k gtk-vnc i386 0.3.8-3.el5 base 80 k gtk-vnc-pythoni386 0.3.8-3.el5 base 12 k libvirt-pythoni386 0.8.2-15.el5_6.4updates 234 k python-virtinst noarch 0.400.3-11.el5 base 380 k xen-libs i386 3.0.3-120.el5_6.2 updates 167 k xz-libs i386 4.999.9-0.3.beta.20091007git.el5base 100 k
Re: value of RAM reported not correct in SLC 5.6
Le 17/06/2011 10:45, Aldo Saavedra a écrit : One of the RPMs installs/enabled virtualisation. Once installed the system itself becomes the first virtual machine (VM) on bootup without actually configuring any VMs. According to google searches the max RAM you can assign a VM is 32GB. Hi Aldo, This seems to me a little bit weird. I am myself using KVM, but with less than 32 GB on the host, and I am not aware that the system itself (the host) becomes the first VM. I think it is doubtful, perhaps it would stand better for Xen ? For a VM host, the more Ram you have, the better it is, so I don't see why it would be limited to 32 GB. I am neither aware of a limit of 32 GB per guest (64 bits). I even found a document from OpenSuse stating a (tested) limit of 512 GB : http://doc.opensuse.org/products/draft/SLES/SLES-kvm_draft/cha.kvm.limits.html Alain -- == Alain Péan - LPP/CNRS Administrateur Système/Réseau Laboratoire de Physique des Plasmas - UMR 7648 Observatoire de Saint-Maur 4, av de Neptune, Bat. A 94100 Saint-Maur des Fossés Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33 ==
Re: value of RAM reported not correct in SLC 5.6
On Friday, June 17, 2011 04:45:51 AM you wrote: > KVM > Virtualization > > One of the RPMs installs/enabled virtualisation. Once installed the > system itself becomes the first virtual machine (VM) on bootup without > actually configuring any VMs. > > According to google searches the max RAM you can assign a VM is 32GB. Ah, makes sense. And the RHEL install probably did not include those two packages..
Re: value of RAM reported not correct in SLC 5.6
On 06/08/2011 06:49 PM, Aldo F. Saavedra wrote: Hi, I'm having the following problem with an invariant of SL56, the cern flavour. I thought perhaps that someone may have come across this with SL56 Here in Sydney, we installed slc56 x86_64 on a Dell Power Edge R510 with 48Gb of RAM. The problem we have is that once the os is installed slc56 top, free and vmstat only reports 32Gb. All the yum updates were performed. To check we booted with the rescue mode, SLC 5.6 and all the commands report 48Gb . A further check we installed RHEL 5.6 x86_64 it reports 48Gb . Is there some tweak to the kernel that needs to be done? Or any cause to the problem. Any ideas are much appreciated. Cheers, Aldo Is this machine being a virtulization host? I know that on SL5 for xen hosts (I haven't verified it for KVM hosts) you only see the amount of memory that the host has left, not the total amount of memory. The best way I found to look at the full memory in this situation was to do a "xm list" which lists all the xen client's memory, as well as the hosts. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/SCF/FEF/SLSMS Group __
Re: value of RAM reported not correct in SLC 5.6
On 06/11/2011 10:53 AM, Alain Péan wrote: Le 10/06/2011 17:03, Stijn De Weirdt a écrit : we are running SL5.6 x86_64 (2.6.18-238.9.1) on a 96GB machine without issues. Hi all, It's a little bit off topic, but I thought that SLC was the CERN variant of Scientific Linux. And SL 5.6 is not yet released. I saw that SLC 5.6 was released months ago and is now the official release for CERN. So, for my information (and perhaps others), why is there a SLC 5.6 release and not yet a SL 5.6 one ? Thanks for the clarification ! Alain Short clarification, I'll let someone from CERN clarify longer if they want. SLC 5.6 has all the updates and packages from SL 5.6. Those packages have already passed our tests, and I assume CERN's tests. The reason SL 5.6 isn't out yet is due to two installer problems, not package problems. So if CERN modifies their installer different than plain SL, it is quite possible for them to beat the plain SL out with a release. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/SCF/FEF/SLSMS Group __
Re: value of RAM reported not correct in SLC 5.6
On Sat, Jun 11, 2011 at 12:45 PM, Lamar Owen wrote: > On Friday, June 10, 2011 08:29:49 PM you wrote: >> It's problematic, especially if one leaves >> the 32-bit versions of components and libraries dual-installed with >> the 64-bit, deletes one and not the other. > > Multilib support can indeed be a problem. In a very large memory system one > would be wise to make sure that the system is 'pure' 64 bit on x86_64. > (other 64-bit systems vary as to recommendations.) > >> The codebase for SL 5 and >> RHEL 5 uses significantlyou out of date kernels, glibc, and other core >> utilities. so yes: if you stretch the environment beyond the common >> resources at the time it was originally designed, you can enter the >> world of surprising corner cases. > > Given the fact of backporting, how 'out-of-date' the kernel, glibc, and other > core utilities are is difficult to determine. But one person's out-of-date > is another's 'stable' instead. Reminds me of this VAX in the corner, driving > a microdensitometer > > But that doesn't address the problem for the OP: why does SLC5.6 see things > so differently than upstream's code of the same version and built from the > same source? That's what the OP was asking about; and I'm looking forward to > seeing the OP post back about any new information. Me, too. I'm not assuming that our OP actually had identically configured RHEL 5.x and SL 5.x environments. But the CD based reports are interesting. > But what were the 'common' resources at the time of EL5's initial release? > What were the 'extreme' resources? IA64 systems were certainly available > with >32GB of RAM prior to EL5's introduction. I specified and got quoted an > Appro quad socket Opteron system with 64GB of RAM a year or more before EL5's > introduction in November of 2007; it was very expensive, too, with over 75% > of the cost of the whole machine being RAM, at the time. And my current > VMware hosts are a little over 4 years old; and they have 32GB of RAM (Dell > PE6950's, quad socket dual-core Opterons; wouldn't mind upgrading to quad > core or hex core chips if they were supported, and 64GB of RAM is an option > with all four sockets populated as they are). And those PE6950's shipped 8 > months before EL5.0 went GA. That may not have been common, though; I do > know they were expensive. But Dell at least has been pretty good about > keeping drivers, BIOS's, and other critical things like SAS controller and > DRAC firmware updated through the years, even for that hardware. It was bloody expensive. Let's see, 4 years ago I'd finished some work helping build, and design, blade servers, including a lot of RHEL 4 and some singificant SuSE integration. 8 Gig was considered hefty: 64 Gig was considered wonderful because they were so expensive and the profit was so high. > Uptime junkies need to get a life. Uptime isn't the be-all, end-all.even > if it is a part of the whole availability equation As you probably agree, > Nico. In an HA VMware situation, uptime of the hosts, as long as the > downtime is planned, is a non-issue. That should be valid for other > virtualization solutions, too, as long as you've configured it HA. Virtualization and its high availability is useful, but also not a be-all and end-all. It doesn't exercise kernels, it doesn't break locks, and if some error has eroded your filesystem, it doesn't give you a chance to fsck unless you actually reboot. It *does* massively reduce the cost of a reboot.
Re: value of RAM reported not correct in SLC 5.6
On Friday, June 10, 2011 08:29:49 PM you wrote: > It's problematic, especially if one leaves > the 32-bit versions of components and libraries dual-installed with > the 64-bit, deletes one and not the other. Multilib support can indeed be a problem. In a very large memory system one would be wise to make sure that the system is 'pure' 64 bit on x86_64. (other 64-bit systems vary as to recommendations.) > The codebase for SL 5 and > RHEL 5 uses significantlyou out of date kernels, glibc, and other core > utilities. so yes: if you stretch the environment beyond the common > resources at the time it was originally designed, you can enter the > world of surprising corner cases. Given the fact of backporting, how 'out-of-date' the kernel, glibc, and other core utilities are is difficult to determine. But one person's out-of-date is another's 'stable' instead. Reminds me of this VAX in the corner, driving a microdensitometer But that doesn't address the problem for the OP: why does SLC5.6 see things so differently than upstream's code of the same version and built from the same source? That's what the OP was asking about; and I'm looking forward to seeing the OP post back about any new information. But what were the 'common' resources at the time of EL5's initial release? What were the 'extreme' resources? IA64 systems were certainly available with >32GB of RAM prior to EL5's introduction. I specified and got quoted an Appro quad socket Opteron system with 64GB of RAM a year or more before EL5's introduction in November of 2007; it was very expensive, too, with over 75% of the cost of the whole machine being RAM, at the time. And my current VMware hosts are a little over 4 years old; and they have 32GB of RAM (Dell PE6950's, quad socket dual-core Opterons; wouldn't mind upgrading to quad core or hex core chips if they were supported, and 64GB of RAM is an option with all four sockets populated as they are). And those PE6950's shipped 8 months before EL5.0 went GA. That may not have been common, though; I do know they were expensive. But Dell at least has been pretty good about keeping drivers, BIOS's, and other critical things like SAS controller and DRAC firmware updated through the years, even for that hardware. > It's worse with old systems: kernel patches to deal with outlier, > wierd hardware aren't necessarily backported, they're more likely to > get in the much more recent kernel codebase, and scheduling downtime > to do BIOS updates gets even harder when someone keeps saying > "n-o-o-o! I've got an uptime of 635 days, we can't reboot it! > prove to me that this will fix things first!" Uptime junkies need to get a life. Uptime isn't the be-all, end-all.even if it is a part of the whole availability equation As you probably agree, Nico. In an HA VMware situation, uptime of the hosts, as long as the downtime is planned, is a non-issue. That should be valid for other virtualization solutions, too, as long as you've configured it HA.
Re: value of RAM reported not correct in SLC 5.6
Le 10/06/2011 17:03, Stijn De Weirdt a écrit : we are running SL5.6 x86_64 (2.6.18-238.9.1) on a 96GB machine without issues. Hi all, It's a little bit off topic, but I thought that SLC was the CERN variant of Scientific Linux. And SL 5.6 is not yet released. I saw that SLC 5.6 was released months ago and is now the official release for CERN. So, for my information (and perhaps others), why is there a SLC 5.6 release and not yet a SL 5.6 one ? Thanks for the clarification ! Alain
Re: value of RAM reported not correct in SLC 5.6
On Fri, Jun 10, 2011 at 10:55 AM, Lamar Owen wrote: > On Thursday, June 09, 2011 07:22:56 PM you wrote: >> That's a significant chunk of RAM for such an old codebase. Is there >> any reason not to simply update to SL 6.0 and avoid the support >> problems? > > What are you talking about, being large for an old codebase? On x86_64 > upstream has supported far more than 48GB since version 3 days (128GB to be > exact, according to http://www.redhat.com/rhel/compare/ ). It can work, I've done it. It's problematic, especially if one leaves the 32-bit versions of components and libraries dual-installed with the 64-bit, deletes one and not the other. The codebase for SL 5 and RHEL 5 uses significantlyou out of date kernels, glibc, and other core utilities. so yes: if you stretch the environment beyond the common resources at the time it was originally designed, you can enter the world of surprising corner cases. It's worse with old systems: kernel patches to deal with outlier, wierd hardware aren't necessarily backported, they're more likely to get in the much more recent kernel codebase, and scheduling downtime to do BIOS updates gets even harder when someone keeps saying "n-o-o-o! I've got an uptime of 635 days, we can't reboot it! prove to me that this will fix things first!" > While I don't have a machine with more than 32GB of RAM currently, I wouldn't > have any problem using CentOS or SL 5.6 (or either SLC or SLF) on x86_64 with > that much RAM. The EL5.6 kernel isn't aged yet, not by a long shot. > > SLC5 to SLC6 is not an update, it is a major upgrade. There may be very > significant reasons to not upgrade for the OP. > > In any case, this doesn't answer the OP's question of why SLC5.6 doesn't see > the same thing as upstream EL5.6 but being built from the same source. I > would ask the OP to see what both SL (non-C) and CentOS 5.6 say about the > machine and see if either see things like SLC or like upstream. It should be > a pretty simple and quick test, especially if the OP uses the LiveCD to do it > (which should work ok, assuming all the tools are there). The LiveCD is a good idea.
Re: value of RAM reported not correct in SLC 5.6
we are running SL5.6 x86_64 (2.6.18-238.9.1) on a 96GB machine without issues. does the bios report 48GB of ram when the OS sees 32? (we had an other machine with bad ram/memcontroller that reported varying amounts of ram after every reboot) and how much ram is seen by dmidecode? stijn > On Thursday, June 09, 2011 07:22:56 PM you wrote: > > That's a significant chunk of RAM for such an old codebase. Is there > > any reason not to simply update to SL 6.0 and avoid the support > > problems? > > What are you talking about, being large for an old codebase? On x86_64 > upstream has supported far more than 48GB since version 3 days (128GB to be > exact, according to http://www.redhat.com/rhel/compare/ ). > > While I don't have a machine with more than 32GB of RAM currently, I wouldn't > have any problem using CentOS or SL 5.6 (or either SLC or SLF) on x86_64 with > that much RAM. The EL5.6 kernel isn't aged yet, not by a long shot. > > SLC5 to SLC6 is not an update, it is a major upgrade. There may be very > significant reasons to not upgrade for the OP. > > In any case, this doesn't answer the OP's question of why SLC5.6 doesn't see > the same thing as upstream EL5.6 but being built from the same source. I > would ask the OP to see what both SL (non-C) and CentOS 5.6 say about the > machine and see if either see things like SLC or like upstream. It should be > a pretty simple and quick test, especially if the OP uses the LiveCD to do it > (which should work ok, assuming all the tools are there). -- http://hasthelhcdestroyedtheearth.com/
Re: value of RAM reported not correct in SLC 5.6
On Wednesday, June 08, 2011 07:49:08 PM you wrote: > The problem we have is that once the os is installed slc56 top, free and > vmstat only reports 32Gb. All the yum updates were performed. > To check we booted with the rescue mode, SLC 5.6 and all the commands > report 48Gb . Hmm, perhaps it won't be as simple as checking with a LiveCD. Can you give the output of 'uname -svrmpio' (or uname -a, without the hostname). The output of dmidecode could be useful as well, and dmesg (either send privately or use pastebin rather than to the list, however).
Re: value of RAM reported not correct in SLC 5.6
On Thursday, June 09, 2011 07:22:56 PM you wrote: > That's a significant chunk of RAM for such an old codebase. Is there > any reason not to simply update to SL 6.0 and avoid the support > problems? What are you talking about, being large for an old codebase? On x86_64 upstream has supported far more than 48GB since version 3 days (128GB to be exact, according to http://www.redhat.com/rhel/compare/ ). While I don't have a machine with more than 32GB of RAM currently, I wouldn't have any problem using CentOS or SL 5.6 (or either SLC or SLF) on x86_64 with that much RAM. The EL5.6 kernel isn't aged yet, not by a long shot. SLC5 to SLC6 is not an update, it is a major upgrade. There may be very significant reasons to not upgrade for the OP. In any case, this doesn't answer the OP's question of why SLC5.6 doesn't see the same thing as upstream EL5.6 but being built from the same source. I would ask the OP to see what both SL (non-C) and CentOS 5.6 say about the machine and see if either see things like SLC or like upstream. It should be a pretty simple and quick test, especially if the OP uses the LiveCD to do it (which should work ok, assuming all the tools are there).
Re: value of RAM reported not correct in SLC 5.6
On Wed, Jun 8, 2011 at 7:49 PM, Aldo F. Saavedra wrote: > Hi, > > I'm having the following problem with an invariant of SL56, the cern > flavour. I thought perhaps that someone may have come across this > with SL56 > > Here in Sydney, we installed slc56 x86_64 on a Dell Power Edge R510 with > 48Gb of RAM. > > The problem we have is that once the os is installed slc56 top, free and > vmstat only reports 32Gb. All the yum updates were performed. > > To check we booted with the rescue mode, SLC 5.6 and all the commands report > 48Gb . > > A further check we installed RHEL 5.6 x86_64 it reports 48Gb . > > Is there some tweak to the kernel that needs to be done? Or any cause to the > problem. Any ideas are much appreciated. That's a significant chunk of RAM for such an old codebase. Is there any reason not to simply update to SL 6.0 and avoid the support problems?
