Anyone familiar with RHEV (Red Hat Enterprise Virtualization)? Any ideas on how to emulate this on CentOS?
Thanks, Gene Poole
On Wed, Sep 7, 2011 at 3:24 PM, Gene Poole gene.poole@macys.com wrote:
Anyone familiar with RHEV (Red Hat Enterprise Virtualization)? Any ideas on how to emulate this on CentOS?
Thanks, Gene Poole
You simply need to install the Virtualizartion Group with yum to get it :)
How good is it? That will depend on what you prefer to use, between XEN & KVM and what you have used in the past.
Red Hat (and thus CentOS) has native XEN support but dropped XEN in favor of KVM (which is not as mature yet) in RH 6.
I think the only real difference between Red Hat's "Enterprise" Virtualization and CentOS Virtualization Group could be that Red Hat has a few commercial management tools included. But the underlying core functionality would be the same. I don't use RH, so I don't know exactly, this is just an assumtion.
But, be careful of mentioning anything other than actual CentOS related software on this list. Some people here don't like it and will get hostile toward you for mentioning it.
On 09/07/2011 09:34 AM, Rudi Ahlers wrote:
Red Hat (and thus CentOS) has native XEN support but dropped XEN in favor of KVM (which is not as mature yet) in RH 6.
This deserves clarification...
Red Hat is a business, and made a simple business decision. Maintaining Xen support would have meant maintaining a very large set of patches. They made the decision that the effort (and money) needed to maintain Xen outside of the mainline kernel was not worth it.
KVM was not chosen over Xen so much as KVM was a much less expensive hypervisor to support. As for it being mature or not; Well, put on your kevlar pants because that is a matter of opinion.
As a follow-up, Xen dom0 support began getting into the mainline kernel at 2.6.33 (EL6 is based on 2.6.32). It is very likely that we will see Xen dom0 support returned in the next major release.
On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
Red Hat is a business, and made a simple business decision. Maintaining Xen support would have meant maintaining a very large set of patches. They made the decision that the effort (and money) needed to maintain Xen outside of the mainline kernel was not worth it.
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
KVM was not chosen over Xen so much as KVM was a much less expensive hypervisor to support. As for it being mature or not; Well, put on your kevlar pants because that is a matter of opinion.
Which is better on C5 and C6 ?
As a follow-up, Xen dom0 support began getting into the mainline kernel at 2.6.33 (EL6 is based on 2.6.32). It is very likely that we will see Xen dom0 support returned in the next major release.
In about 4 or 5 years ??? :-)
Regards,
Paul.
On Wed, 7 Sep 2011, Always Learning wrote:
On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
Red Hat is a business, and made a simple business decision. Maintaining Xen support would have meant maintaining a very large set of patches. They made the decision that the effort (and money) needed to maintain Xen outside of the mainline kernel was not worth it.
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
That's fine if you just want to jump ship to a new version. But what if the new version breaks some things, or changes behaviour in a way you don't want, or removes a feature. Your choice effectively becomes do I back port things I want to an old version, or maintain patches that takes current back to the state I want.
Which is better on C5 and C6 ?
That's a matter for google, and not necessarily a simple one to answer. As was said, Xen was the standard option with C5, and KVM was with C6.
jh
On Wed, 2011-09-07 at 15:03 +0100, John Hodrien wrote:
On Wed, 7 Sep 2011, Always Learning wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
That's fine if you just want to jump ship to a new version. But what if the new version breaks some things, or changes behaviour in a way you don't want, or removes a feature.
If one compiled a 'new' version containing all those many existing patches, would not that 'new' version simply work exactly as the old version patched by countless alternations ?
Regards,
Paul.
On Wed, 7 Sep 2011, Always Learning wrote:
On Wed, 2011-09-07 at 15:03 +0100, John Hodrien wrote:
On Wed, 7 Sep 2011, Always Learning wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
That's fine if you just want to jump ship to a new version. But what if the new version breaks some things, or changes behaviour in a way you don't want, or removes a feature.
If one compiled a 'new' version containing all those many existing patches, would not that 'new' version simply work exactly as the old version patched by countless alternations ?
If that's all you're doing, there's no pain in having the patches. But what happens if you don't want *all* the patches?
jh
On Wed, 2011-09-07 at 15:39 +0100, John Hodrien wrote:
If that's all you're doing, there's no pain in having the patches. But what happens if you don't want *all* the patches?
A heavily patched programme is a messy compromise for system options which could be handled by run-time configuration options ?
Paul.
On Wed, 7 Sep 2011, Always Learning wrote:
On Wed, 2011-09-07 at 15:39 +0100, John Hodrien wrote:
If that's all you're doing, there's no pain in having the patches. But what happens if you don't want *all* the patches?
A heavily patched programme is a messy compromise for system options which could be handled by run-time configuration options ?
But without patches, you're either bound to an old version, or have to track upstream exactly. What if you don't want to?
jh
On Wed, 2011-09-07 at 15:50 +0100, John Hodrien wrote:
On Wed, 7 Sep 2011, Always Learning wrote:
A heavily patched programme is a messy compromise for system options which could be handled by run-time configuration options ?
But without patches, you're either bound to an old version, or have to track upstream exactly. What if you don't want to?
So, if I understand the situation, patches create flexibility in run-time options not available in run-time configuration files ?
Paul.
On Wed, 7 Sep 2011, Always Learning wrote:
On Wed, 2011-09-07 at 15:50 +0100, John Hodrien wrote:
On Wed, 7 Sep 2011, Always Learning wrote:
A heavily patched programme is a messy compromise for system options which could be handled by run-time configuration options ?
But without patches, you're either bound to an old version, or have to track upstream exactly. What if you don't want to?
So, if I understand the situation, patches create flexibility in run-time options not available in run-time configuration files ?
Not at all. What's your solution where the old product does things one way, the new product does things another way, and there's no config option to flick between the two? Patch in a config option?
jh
On 09/08/2011 12:53 AM, Always Learning wrote:
So, if I understand the situation, patches create flexibility in run-time options not available in run-time configuration files ?
Someone submits a patch as a quick-fix to a problem they've seen, which gets accepted and inserted into the package. Down the track, a better fix is submitted and accepted. All you need to do is pull the first patch file and insert the second one, update your spec file then rebuild the RPM.
If everything was all squashed up into one great big code base, you need to hunt around to find the change that was made, pull it out, make sure you code builds, then insert the new change, make sure it builds, etc. revise and repeat until you have something you can ship.
First method takes about 2-3 minutes.
Second method takes however long it takes, and may introduce other errors or issues.
The first method also means that if the patch changes something you need to adhere for legal reasons (like, say, branding), you just pull that patch from the spec file and it's a trivial exercise.
On Thu, 2011-09-08 at 13:23 +1000, Steve Walsh wrote:
Someone submits a patch as a quick-fix to a problem they've seen, which gets accepted and inserted into the package. Down the track, a better fix is submitted and accepted. All you need to do is pull the first patch file and insert the second one, update your spec file then rebuild the RPM.
............
Thank you for the explanation.
Paul.
On 09/07/2011 09:57 AM, Always Learning wrote:
On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
Red Hat is a business, and made a simple business decision. Maintaining Xen support would have meant maintaining a very large set of patches. They made the decision that the effort (and money) needed to maintain Xen outside of the mainline kernel was not worth it.
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
That's the form they come from the community in. You'd have to ask the devs for details.
KVM was not chosen over Xen so much as KVM was a much less expensive hypervisor to support. As for it being mature or not; Well, put on your kevlar pants because that is a matter of opinion.
Which is better on C5 and C6 ?
For what? That is a loaded question.
For me, I use C5 + Xen when I am backing *nix VMs and c6 + KVM when backing MS VMs as the PV drivers for windws are less than ideal.
As a follow-up, Xen dom0 support began getting into the mainline kernel at 2.6.33 (EL6 is based on 2.6.32). It is very likely that we will see Xen dom0 support returned in the next major release.
In about 4 or 5 years ??? :-)
They tend to release a new x-stream release every three years. EL6 is a year old, so I'd bet in two more years we will see EL7 and that both KVM and Xen will be supported.
On Wed, 2011-09-07 at 10:05 -0400, Digimer wrote:
"At what point did we forget that the Space Shuttle was, essentially, a program that strapped human beings to an explosion and tried to stab through the sky with fire and math?"
And it worked. A tremendous and useful achievement now scrapped.
Always Learning wrote:
On Wed, 2011-09-07 at 10:05 -0400, Digimer wrote:
"At what point did we forget that the Space Shuttle was, essentially, a program that strapped human beings to an explosion and tried to stab through the sky with fire and math?"
And it worked. A tremendous and useful achievement now scrapped.
And a national disgrace, that there was no replacement coming online 10 years ago... but email me offlist if you want a rant based on inside information....
mark "a seat on a rehabbed Shuttle? How many people do I have to beat up to get to the head of the line?"
Thanks Guys for the helpful info.
Paul.
On Wed, Sep 7, 2011 at 9:57 AM, Always Learning centos@u61.u22.net wrote:
On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
Red Hat is a business, and made a simple business decision. Maintaining Xen support would have meant maintaining a very large set of patches. They made the decision that the effort (and money) needed to maintain Xen outside of the mainline kernel was not worth it.
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
For the same reason that Red Hat uses patches to back port security updates and functionality into the kernel, httpd, and most of the other packages in RHEL. Introducing a version change may add/remove functionality, may alter configuration options, may be lest tested, etc. The point of using an "enterprise" distro is that change is kept to a minimum.
On Wed, Sep 7, 2011 at 10:17 AM, William Hooper whooperhsd@gmail.com wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
For the same reason that Red Hat uses patches to back port security updates and functionality into the kernel, httpd, and most of the other packages in RHEL.
I thought that was no longer true for the 6.x kernel.
On Wed, Sep 7, 2011 at 11:31 AM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Sep 7, 2011 at 10:17 AM, William Hooper whooperhsd@gmail.com wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
For the same reason that Red Hat uses patches to back port security updates and functionality into the kernel, httpd, and most of the other packages in RHEL.
I thought that was no longer true for the 6.x kernel.
The difference is that the kernel tarball provided in the SRPM is a Red Hat kernel, not a vanilla kernel. Just because the patches are not in the SRPM doesn't mean they don't exist.
Greetings,
On Wed, Sep 7, 2011 at 9:11 PM, William Hooper whooperhsd@gmail.com wrote:
I tried RHEV once for about a fortnight with Openfiler as storage.
I started to hate openfiler ever since they switched over from centos as a base to some other distro. Especially makes life difficult when handlung NTFS partition (by design or by coertion).
It has some sort of persistence mechanism in place for storage which I did not get an opportunity to wrap my head around further as I dont have the resources. Especially in storage.
RHEV is is a beast in itself.
Let us wait till RHEV 4.0 whivh has JBOSS as the base for the management tools.
above imho.
On Sep 7, 2011, at 9:57 AM, Always Learning centos@u61.u22.net wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
RHEL needs to keep the same ABI (application binary interface) for both kernel and user programs so third party VARs and software developer's binary packages will continue to be compatible during the lifetime of a release (5.X or 6.X).
In order to do that RH keeps (or makes all attempts to) the same versions of the software during the release while back porting security updates and must-have features that don't change these ABIs.
These back ported updates are the patches that are applied to the base package.
That should make it crystal clear.
-Ross
On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
On Sep 7, 2011, at 9:57 AM, Always Learning centos@u61.u22.net wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
RHEL needs to keep the same ABI (application binary interface) for both kernel and user programs so third party VARs and software developer's binary packages will continue to be compatible during the lifetime of a release (5.X or 6.X).
According to my brief 30 seconds understanding of ABIs from Wikipedia, that does not seem relevant to patching. The ABI is just a calling convention. The parameters used and the data exchanged is predetermined otherwise nothing would work. Parameters and data formats remains constant throughout the life-time of the software. That has always been the way for all inter-programme communications.
In order to do that RH keeps (or makes all attempts to) the same versions of the software during the release while back porting security updates and must-have features that don't change these ABIs.
Anything which is patched is, by definition, not the same version as the original version although the version number can remain the same and the functionality generally remains the same. Obviously the ABI should remain the same otherwise other programmes would be unable to successfully exchange 'data'.
These back ported updates are the patches that are applied to the base package.
Which means some systems, patched locally, may have to then re-apply their patches to the base system ?
That should make it crystal clear.
Regrettably it did not. Another poster, whose name I can't recall at this moment, explained the patched practise as being able to restrict charges to specific modules while maintaining unaltered core functionality and having the flexibility to customise a base package for specific requirements.
Best regards,
Paul.
On Sep 8, 2011, at 9:16 PM, Always Learning centos@u61.u22.net wrote:
On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
On Sep 7, 2011, at 9:57 AM, Always Learning centos@u61.u22.net wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
RHEL needs to keep the same ABI (application binary interface) for both kernel and user programs so third party VARs and software developer's binary packages will continue to be compatible during the lifetime of a release (5.X or 6.X).
According to my brief 30 seconds understanding of ABIs from Wikipedia, that does not seem relevant to patching. The ABI is just a calling convention. The parameters used and the data exchanged is predetermined otherwise nothing would work. Parameters and data formats remains constant throughout the life-time of the software. That has always been the way for all inter-programme communications.
Ok, let's say version X of a given software package has a security flaw in it. This security flaw has been fixed in version Y of the same package, but version Y has a slightly different functionality, maybe it is in some shared libs or maybe just in how it presents itself in procfs/configfs.
Now RH needs to fix this security flaw in the existing version X of the package, this package's existing interface needs to remain constant because software vendors have products out there that depend on it, so they reverse engineer or diff out the changes made to fix the security flaw without making any of the functionality changes.
This then becomes a patch to the existing version X. It is applied as a patch in the SRPM because it's easy to incorporate, track, document and back-out if necessary.
Over time the software packages and the kernel itself will accumulate multiple patches.
In order to do that RH keeps (or makes all attempts to) the same versions of the software during the release while back porting security updates and must-have features that don't change these ABIs.
Anything which is patched is, by definition, not the same version as the original version although the version number can remain the same and the functionality generally remains the same. Obviously the ABI should remain the same otherwise other programmes would be unable to successfully exchange 'data'.
Yes, RH packages are NOT the same as the originals, they have security patches and maybe some performance fixes from the originals, but they keep the ABI the same, and thus keep the version numbers the same. There are version numbers appended to the upstream version to differentiate the packages and determine the fix level of a given package through it's lifetime.
These back ported updates are the patches that are applied to the base package.
Which means some systems, patched locally, may have to then re-apply their patches to the base system ?
No, these patches are incorporated into the SRPMs used to build the binary RPM packages and they become the distribution, after a certain amount are accumulated they re-target the distribution at a point release 5.1, 5.2, etc.
That should make it crystal clear.
Regrettably it did not. Another poster, whose name I can't recall at this moment, explained the patched practise as being able to restrict charges to specific modules while maintaining unaltered core functionality and having the flexibility to customise a base package for specific requirements.
I'm sorry I wasn't very clear to begin with, maybe this helped?
-Ross
On 01/-10/-28163 02:59 PM, Always Learning wrote:
On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
On Sep 7, 2011, at 9:57 AM, Always Learningcentos@u61.u22.net wrote:
Perhaps a silly question, but why maintain patches ? Why not compile a new version and discard all the patches ? Patches are a messy manner to maintain programmes.
RHEL needs to keep the same ABI (application binary interface) for both kernel and user programs so third party VARs and software developer's binary packages will continue to be compatible during the lifetime of a release (5.X or 6.X).
According to my brief 30 seconds understanding of ABIs from Wikipedia, that does not seem relevant to patching. The ABI is just a calling convention. The parameters used and the data exchanged is predetermined otherwise nothing would work. Parameters and data formats remains constant throughout the life-time of the software. That has always been the way for all inter-programme communications.
In order to do that RH keeps (or makes all attempts to) the same versions of the software during the release while back porting security updates and must-have features that don't change these ABIs.
Anything which is patched is, by definition, not the same version as the original version although the version number can remain the same and the functionality generally remains the same. Obviously the ABI should remain the same otherwise other programmes would be unable to successfully exchange 'data'.
These back ported updates are the patches that are applied to the base package.
Which means some systems, patched locally, may have to then re-apply their patches to the base system ?
That should make it crystal clear.
Regrettably it did not. Another poster, whose name I can't recall at this moment, explained the patched practise as being able to restrict charges to specific modules while maintaining unaltered core functionality and having the flexibility to customise a base package for specific requirements.
Generally the reason that packages on RHEl have patches back-ported instead of simply updated to the latest version is because of the version dependencies other packages may have. The entire RHEL distribution, as are most others, is pervasively permeated by intricate package inter-dependencies. Changing the version number of one may well start a cascade of failed dependencies in other, apparently unrelated packages.
Also, the idea of backward API compatibility is not given much consideration in many FOSS projects in my experience. Injecting a new version of some software into the distribution may well disable parts of it that depend upon a now deprecated function.
It is well to remember that the reason new versions of RHEL take so long to appear is the effort that goes into making sure that every package contained therein will build and inter-operate correctly with all of the others. No-one concerned with getting it to work in the first place really wants to introduce potentially substantial changes.
On Wed, Sep 7, 2011 at 3:51 PM, Digimer linux@alteeve.com wrote:
On 09/07/2011 09:34 AM, Rudi Ahlers wrote:
Red Hat (and thus CentOS) has native XEN support but dropped XEN in favor of KVM (which is not as mature yet) in RH 6.
This deserves clarification...
Red Hat is a business, and made a simple business decision. Maintaining Xen support would have meant maintaining a very large set of patches. They made the decision that the effort (and money) needed to maintain Xen outside of the mainline kernel was not worth it.
Well, I merely stated the facts of what the Red Hat Virtualization package offers in the 2 different Red Hat releases, 5 & 6.
KVM was not chosen over Xen so much as KVM was a much less expensive hypervisor to support. As for it being mature or not; Well, put on your kevlar pants because that is a matter of opinion.
I'm sure many people will argue against this perception since XEN has been around much longer than KVM and, up to recently,"just worked" every time. So the amount of effot they (or any other Linux distro) had to put in to support it is minimal. At the same time, in a different camp, there are those who speculate that XEN was dropped since it's the defacto standard for Novell Suse / OpenSuse and it's direct competition for Red Hat.
As a follow-up, Xen dom0 support began getting into the mainline kernel at 2.6.33 (EL6 is based on 2.6.32). It is very likely that we will see Xen dom0 support returned in the next major release.
That would be nice and I'm sure Red Hat would gain some ground again but if you look on the trend on the web many people stopped using Red Hat (and derivatives of it, like CentOS) because of this very reason.
-- Digimer E-Mail: digimer@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "At what point did we forget that the Space Shuttle was, essentially, a program that strapped human beings to an explosion and tried to stab through the sky with fire and math?" _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Always Learning -
Digimer -
Gene Poole -
James B. Byrne -
John Hodrien -
Les Mikesell -
m.roth＠5-cent.us -
Rajagopal Swaminathan -
Ross Walker -
Rudi Ahlers -
Steve Walsh -
William Hooper