Greetings,
Apologies for Off thread (and possibly stupid) question: Where on the net one can find the RHEV-M general list like this one for centos
<rant> I have been tearing my hair for past week to make RHEV work with two boxens. One RHEV H and one running XP with two VMs uner VMware WS. One VM is openfiler for iscsi storage and another VM w2k3 for RHEVM. Search in foogle for the error "Network conenction error 5022" does not allow creation of the storage domain with couple of iscsi storage (openfiler) targets.
I troubled google uncle for answers but perhaps is angry with me. sigh.
And I know only *ONE* list which knows all the correct answers: centos [at] centos.org </rant>
Thanks for any pointers.
Regards,
Rajagopal
2011/1/5 Rajagopal Swaminathan raju.rajsand@gmail.com:
Greetings,
Apologies for Off thread (and possibly stupid) question: Where on the net one can find the RHEV-M general list like this one for centos
You cannot. contact your rhel support for your issue.
-- Eero
Greetings,
On Wed, Jan 5, 2011 at 4:26 PM, Eero Volotinen eero.volotinen@iki.fiwrote:
2011/1/5 Rajagopal Swaminathan raju.rajsand@gmail.com:
Greetings,
Apologies for Off thread (and possibly stupid) question: Where on the net one can find the RHEV-M general list like this one for centos
You cannot. contact your rhel support for your issue.
Thanks for the lightning fast reply!
But the issue is how can I suggest purchase of product/support without knowing if a product works in the first place?
Individuals cannot afford high-end hardware required for RHEV. But they are the ones who can propose it *after* trying that out with their own resources like machines without management ports and the such. I learnt RHCS that way (of course using Centos).
30 Days eval does not include support, I suppose.
Souds like old days of shrink wrap philosophy of last couple of decades. That too from a FLOSS company.
Disappointing for a hard-headed (and hard-nosed) supporter of redhat...
Regards,
Rajagopal
But the issue is how can I suggest purchase of product/support without knowing if a product works in the first place?
it is mainly kvm management interface and you can use kvm for free in centos ..
Souds like old days of shrink wrap philosophy of last couple of decades. That too from a FLOSS company.
There are some free alternatives, maybe you should use them instead.
-- Eero
On Wed, Jan 5, 2011 at 4:47 PM, Rajagopal Swaminathan raju.rajsand@gmail.com wrote:
.... snip ....
But the issue is how can I suggest purchase of product/support without knowing if a product works in the first place?
If you are really serious about evaluation, I am sure your local Redhat sales/marketing can work something out for you.
-- Arun Khan
.... snip ....
But the issue is how can I suggest purchase of product/support without knowing if a product works in the first place?
If you are really serious about evaluation, I am sure your local Redhat sales/marketing can work something out for you.
Actually I've tried to reply to this thread but as I've just enlisted to the list I failed to reply to this thread. I've tried to email Raju directly though but his is a summary of this email:
At the moment all RHEV evaluation installations are supported, evaluation engagements though are limited in scale to allow for this support. Evaluation engagements are managed by sales and partners.This is why for the time being you can't just download RHEV for evaluation. This means you got RHEV from one of our partners or sales people and you should be entitled to support.
Regardless of the said above, what can I do to help you with the evaluation?
What I understand with from the thread you are trying to use openfiler as your target, have you considered tgt? (I'm using this on all my setups) Farther more, please try to avoid exposing storage from a VMware workstation VM, the IO performance is far from being satisfactory and may result in poor evaluation experience. If you must have your storage in a VM then it's better to use KVM virtual machine (Found both on Centos or RHEL distributions), use virtio disk and network, and install RHEL/Centos 5.5 guests. Alternative, if you must use VMware is to use ESXi.
Please feel free to contact me for farther assistance - I can suggest other alternatives as well.
Thanks, Simon.
On Thu, Jan 6, 2011 at 6:31 AM, Simon Grinberg simon@redhat.com wrote:
What I understand with from the thread you are trying to use openfiler as your target, have you considered tgt? (I'm using this on all my setups) Farther more, please try to avoid exposing storage from a VMware workstation VM, the IO performance is far from being satisfactory and may result in poor evaluation experience. If you must have your storage in a VM then it's better to use KVM virtual machine (Found both on Centos or RHEL distributions), use virtio disk and network, and install RHEL/Centos 5.5 guests. Alternative, if you must use VMware is to use ESXi.
For RHEL 5 and CentOS 5, I found KVM to be useless. The management tool is not good, and the bridged networking requirement is very awkward, and it performed like a dog being beaten with a missing leg.
I'm interested in trying it for RHEL 6 and CentOS 6, but until then I'm personally relying on VMWare ESX for institution virtualization, and Virtualbox because it's a much more usable configuration interface tool and uses "Right-Ctrl" to release the mouse from the virtualized console instead of "Ctrl-Alt". VMWare could learn a lot from Sun's and now Oracle's efforts with that tool.
For RHEL 5 and CentOS 5, I found KVM to be useless. The management tool is not good, and the bridged networking requirement is very awkward, and it performed like a dog being beaten with a missing leg.
What guest OS have you tried? RHEL5.4 and up come with Virtio drivers so using virtio devices RHEL 5.4+guests will provide good preformance
I'm interested in trying it for RHEL 6 and CentOS 6,
Indeed you should see performance boost on RHEL6
but until then I'm personally relying on VMWare ESX for institution virtualization,
Then you should compare to RHEV and not to RHEL + virt-manager (RHEV also has Virtio drivers for windows guests)
and Virtualbox because it's a much more usable configuration interface tool and uses "Right-Ctrl" to release the mouse from the virtualized console instead of "Ctrl-Alt".
With RHEV you'll have SPICE, that does not need both as after installation of the guest tools it does not grab the mouse.
VMWare could learn a lot from Sun's and now Oracle's efforts with that tool.
I'm going to chime in here, First off I want to thank Simon for pitching in and trying to help out.....The problem I have is that while I would love to run RHEV, at the moment having to have a windows server to install it on is a bit much for me....in fact it kind of runs opposite of what I am trying to do and that is to not have to do any windows management at all....now of course all of the bigger Enterprise Installations will have windows server at their disposal but not always the smaller guys.....So I am waiting for the RHEV port to linux which I know is under way but can't get here soon enough....if you have any insight as to when that might happen that would be Great....
:)
On Thu, Jan 6, 2011 at 7:17 AM, Simon Grinberg simon@redhat.com wrote:
With RHEV you'll have SPICE, that does not need both as after installation of the guest tools it does not grab the mouse.
VMWare could learn a lot from Sun's and now Oracle's efforts with that tool.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
----- Original Message -----
From: "Tom Bishop" bishoptf@gmail.com To: "CentOS mailing list" centos@centos.org Sent: Thursday, January 6, 2011 3:25:22 PM Subject: Re: [CentOS] [OT] RHEVM List
I'm going to chime in here, First off I want to thank Simon for pitching in and trying to help out.....The problem I have is that while I would love to run RHEV, at the moment having to have a windows server to install it on is a bit much for me....in fact it kind of runs opposite of what I am trying to do and that is to not have to do any windows management at all....now of course all of the bigger Enterprise Installations will have windows server at their disposal but not always the smaller guys.....So I am waiting for the RHEV port to linux which I know is under way but can't get here soon enough....if you have any insight as to when that might happen that would be Great....
:)
Well the only thing I can assure is that this project is being driven on full steam.
RHEV Manager is a huge project so the porting to Linux is being done in two leaps. The upcoming leap is the migration of the codebase from .Net to Java / IIS to Jboss http://lpeer.blogspot.com/2010/04/switching-from-c-to-java.html But it's still on windows :( (With REST API interface though, so you'll be able to manage RHEV from Linux environment). I can't at the moment provide an exact date to full Linux version but it may still make it to 2011.
n Thu, Jan 6, 2011 at 7:17 AM, Simon Grinberg < simon@redhat.com > wrote:
With RHEV you'll have SPICE, that does not need both as after installation of the guest tools it does not grab the mouse.
VMWare could learn a lot from Sun's and now Oracle's efforts with that tool.
_______________________________________________ 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
2011/1/6 Tom Bishop bishoptf@gmail.com:
I'm going to chime in here, First off I want to thank Simon for pitching in and trying to help out.....The problem I have is that while I would love to run RHEV, at the moment having to have a windows server to install it on is a bit much for me....in fact it kind of runs opposite of what I am trying to do and that is to not have to do any windows management at all....now of course all of the bigger Enterprise Installations will have windows server at their disposal but not always the smaller guys.....So I am waiting for the RHEV port to linux which I know is under way but can't get here soon
ESX(i) also requires windows server + management client and Citrix XenServer also requires windows management client.
VirtManager + RHEL 5/6 does not require use of windows client.
-- Eero
On Thu, Jan 06, 2011 at 08:43:02PM +0300, Eero Volotinen wrote:
ESX(i) also requires windows server + management client and Citrix XenServer also requires windows management client.
Quick correction (unless I'm misundertanding what you wrote here.)
Esx(i) doesn't require a Windows server, only a Windows machine to run the VIC or whatever they call the newer version of the client.
(Much of the time, the client can be dispensed with by either using vm-command and also some *limited* administration from a web brower.)
Note that there's a neverending thread on vmware forums for a Linux client, and I believe it was finally promised in the Sept 2009--but I could be really wrong with that date...
So, any decade now, I'm expecting it to be available.
On 1/6/2011 11:51 AM, Scott Robbins wrote:
ESX(i) also requires windows server + management client and Citrix XenServer also requires windows management client.
Quick correction (unless I'm misundertanding what you wrote here.)
Esx(i) doesn't require a Windows server, only a Windows machine to run the VIC or whatever they call the newer version of the client.
(Much of the time, the client can be dispensed with by either using vm-command and also some *limited* administration from a web brower.)
You really only need the windows client when you are making changes. Once a guest system is up and network-connected you can access it directly like you would a remote physical machine (X, freenx, vnc, ssh, remote desktop, etc.).
On Thursday, January 06, 2011 12:51:39 pm Scott Robbins wrote:
Esx(i) doesn't require a Windows server, only a Windows machine to run the VIC or whatever they call the newer version of the client.
vCenter Server, required for vMotion, DRS, HA, and a number of other features, requires a Windows server. A fairly beefy server at that.
On Thu, Jan 6, 2011 at 12:43 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
ESX(i) also requires windows server + management client and Citrix XenServer also requires windows management client.
VirtManager + RHEL 5/6 does not require use of windows client.
virt-manager is too stupid to be permitted to live outside of an intensive care unit. It completely mishandles configuration options that are easily available from the command line, such as the use of mutliple disk drives at image setup time, and has very poor handling of randomized NIC configurations, and it behaves extremely poorly over remote X connections. It also has no clue and little capability to properly handle pair-bonded connections for high reliability upstream connectivity.
RHEV may address its lacks, but lord, it's not good.
On Thu, 6 Jan 2011, Nico Kadel-Garcia wrote:
On Thu, Jan 6, 2011 at 12:43 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
VirtManager + RHEL 5/6 does not require use of windows client.
virt-manager is too stupid to be permitted to live outside of an intensive care unit. It completely mishandles configuration options that are easily available from the command line, such as the use of mutliple disk drives at image setup time, and has very poor handling of randomized NIC configurations, and it behaves extremely poorly over remote X connections. It also has no clue and little capability to properly handle pair-bonded connections for high reliability upstream connectivity.
I'm also waiting (not holding my breath) for clear documentation from upstream of which settings are stored in which files. Or even documentation that is internally consistent with itself.
say /etc/xen or /etc/libvirt/* or /var/lib/libvirt/*??
Has that been cleaned up and documented? ---------------------------------------------------------------------- Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
On Thu, Jan 6, 2011 at 9:16 PM, Jim Wildman jim@rossberry.com wrote:
On Thu, 6 Jan 2011, Nico Kadel-Garcia wrote:
On Thu, Jan 6, 2011 at 12:43 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
VirtManager + RHEL 5/6 does not require use of windows client.
virt-manager is too stupid to be permitted to live outside of an intensive care unit. It completely mishandles configuration options that are easily available from the command line, such as the use of mutliple disk drives at image setup time, and has very poor handling of randomized NIC configurations, and it behaves extremely poorly over remote X connections. It also has no clue and little capability to properly handle pair-bonded connections for high reliability upstream connectivity.
I'm also waiting (not holding my breath) for clear documentation from upstream of which settings are stored in which files. Or even documentation that is internally consistent with itself.
say /etc/xen or /etc/libvirt/* or /var/lib/libvirt/*??
Has that been cleaned up and documented?
I was testing it with KVM, for comparison to VMWare, and didn't get as far as that. The network configuration, multiple disk at install time, and dog-slow performance of KVM prevented further exploration. KVM was being heavily advertised by RedHat so I wanted a look, and was completely underwhelmed. The requisite "bridged" network ports have to be set manually on the server, since the built-in network configuration tools have no clue how to do it. This means network pair-bonding has to be done in the guest domain, and it turned out that PXE didn't work at all in the guests.
It was completely useless: hopefully RHEL 6 and CentOS 6 get it right.
Greetings,
On 1/7/11, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Jan 6, 2011 at 9:16 PM, Jim Wildman jim@rossberry.com wrote:
On Thu, 6 Jan 2011, Nico Kadel-Garcia wrote:
On Thu, Jan 6, 2011 at 12:43 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
It was completely useless: hopefully RHEL 6 and CentOS 6 get it right.
As the OP, I wish to report that I was able to create at least one vm using RHEV. I followed the guidelines given by Simon and had a openfiler available on an esx today.
I am yet to make the iso domain available to install OS in the guest.
RHEV and RHEV-M rocks so far.
And Oh I am working with one of RH partners and they do have legitimate access to support. I recently took up the assignment and there were some registration stepe etc to be completed with RHN and the such which are scheduled later. for registering the call.
Though the idea I proposed about the public mailing list is still valid.
If only the entry barrier were not there, we individuals can otherwise help pass some worthy (or unworthy) comments on the products.
Thanks for all those responded.
Regards,
Rajagopal
----- Original Message -----
From: "Rajagopal Swaminathan" raju.rajsand@gmail.com To: "CentOS mailing list" centos@centos.org Sent: Friday, January 7, 2011 6:35:00 PM Subject: Re: [CentOS] [OT] RHEVM List Greetings,
On 1/7/11, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Jan 6, 2011 at 9:16 PM, Jim Wildman jim@rossberry.com wrote:
On Thu, 6 Jan 2011, Nico Kadel-Garcia wrote:
On Thu, Jan 6, 2011 at 12:43 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
It was completely useless: hopefully RHEL 6 and CentOS 6 get it right.
As the OP, I wish to report that I was able to create at least one vm using RHEV. I followed the guidelines given by Simon and had a openfiler available on an esx today.
I am yet to make the iso domain available to install OS in the guest.
RHEV and RHEV-M rocks so far.
Glad to here that. I'm sure you'd also be happy with KVM+virtio+TGT over Centos P.S with this combination you can actually have TGT running on the host meaning max IO performance while RHEM-Manager installed within a VM running on the same host :)
And Oh I am working with one of RH partners and they do have legitimate access to support. I recently took up the assignment and there were some registration stepe etc to be completed with RHN and the such which are scheduled later. for registering the call.
Though the idea I proposed about the public mailing list is still valid.
It's valid indeed. When RHEV will open for public evaluation there will be one. In the mean while you have Red Hat's support for your disposal.
Regards, Simon.
If only the entry barrier were not there, we individuals can otherwise help pass some worthy (or unworthy) comments on the products.
Thanks for all those responded.
Regards,
Rajagopal _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 01/07/2011 05:02 AM, Nico Kadel-Garcia wrote:
I was testing it with KVM, for comparison to VMWare, and didn't get as far as that. The network configuration, multiple disk at install time, and dog-slow performance of KVM prevented further exploration. KVM was being heavily advertised by RedHat so I wanted a look, and was completely underwhelmed. The requisite "bridged" network ports have to be set manually on the server, since the built-in network configuration tools have no clue how to do it. This means network pair-bonding has to be done in the guest domain, and it turned out that PXE didn't work at all in the guests.
It was completely useless: hopefully RHEL 6 and CentOS 6 get it right.
I'm successfully running KVM on top of Ubuntu 10.04LTS with CentOS5.5 guests with virtio ethernet drivers. I've got my physical ethernet ports bonded (three pairs of two) and bridged to the guests such that they don't even know any magic is happening. The configuration is completely non-obvious (and way under documented) but not very complex to implement. The only performance issues I have encountered so far are linked to the abysmal disk write performance of the qcow2 image file format. It can be partially ameliorated by turning on writeback for the disk images (or by using raw format instead of qcow2). I've got 17 running guests on one machine (8 cores, 32GB RAM, 2+ TB of battery backed RAIDed disk) and it is working like a champ. The only major complaint I have is that by default 10.04LTS doesn't cleanly shutdown the VMs on a reboot or shutdown - instead just effectively 'pulling the plug' on them. RH apparently does the same thing in 5.x: kills guests rather than shutting them down on reboot/shutdown. :O
I had to do some surgery on the init system to make it do a clean shutdown on guests (and hid 'shutdown' and 'reboot' behind some scripts that do a parallel vm shutdown before actually calling the real 'shutdown' or 'reboot' just to be really sure).
On 1/7/2011 7:02 AM, Nico Kadel-Garcia wrote:
I was testing it with KVM, for comparison to VMWare, and didn't get as far as that. The network configuration, multiple disk at install time, and dog-slow performance of KVM prevented further exploration. KVM was being heavily advertised by RedHat so I wanted a look, and was completely underwhelmed. The requisite "bridged" network ports have to be set manually on the server, since the built-in network configuration tools have no clue how to do it. This means network pair-bonding has to be done in the guest domain, and it turned out that PXE didn't work at all in the guests.
I haven't tried that, but wouldn't you bridge the bond device instead of bonding bridged nics?
On Fri, Jan 7, 2011 at 1:02 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 1/7/2011 7:02 AM, Nico Kadel-Garcia wrote:
I was testing it with KVM, for comparison to VMWare, and didn't get as far as that. The network configuration, multiple disk at install time, and dog-slow performance of KVM prevented further exploration. KVM was being heavily advertised by RedHat so I wanted a look, and was completely underwhelmed. The requisite "bridged" network ports have to be set manually on the server, since the built-in network configuration tools have no clue how to do it. This means network pair-bonding has to be done in the guest domain, and it turned out that PXE didn't work at all in the guests.
I haven't tried that, but wouldn't you bridge the bond device instead of bonding bridged nics?
That would make sense, but it didn't work at all. I assume this is because the features are simply not simultaneously supportable.
Neither VMWare, Xen, nor VirtualBox require the "bridged" network ports, so it was a major configuration failing in KVM.
On Fri, Jan 7, 2011 at 9:37 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Fri, Jan 7, 2011 at 1:02 PM, Les Mikesell lesmikesell@gmail.com wrote:
On 1/7/2011 7:02 AM, Nico Kadel-Garcia wrote:
I was testing it with KVM, for comparison to VMWare, and didn't get as far as that. The network configuration, multiple disk at install time, and dog-slow performance of KVM prevented further exploration. KVM was being heavily advertised by RedHat so I wanted a look, and was completely underwhelmed. The requisite "bridged" network ports have to be set manually on the server, since the built-in network configuration tools have no clue how to do it. This means network pair-bonding has to be done in the guest domain, and it turned out that PXE didn't work at all in the guests.
I haven't tried that, but wouldn't you bridge the bond device instead of bonding bridged nics?
That would make sense, but it didn't work at all. I assume this is because the features are simply not simultaneously supportable.
Neither VMWare, Xen, nor VirtualBox require the "bridged" network ports, so it was a major configuration failing in KVM.
I found its X interface so unstable as to be unusable on most X servers, whether CygWin, Xceed, VNC, or Xorg on a similar OS release laptop I was working with. What X server are you using?
On Friday, January 07, 2011 09:37:15 pm Nico Kadel-Garcia wrote:
Neither VMWare, Xen, nor VirtualBox require the "bridged" network ports, so it was a major configuration failing in KVM.
Very minor nit: VMware does the bridging in the background for ESX (vSwitches are bridges). ESX >4.0 can have a Cisco virtual Nexus 1000 instead of the default bridging.... which is cool. But it's still bridging, just something that the VI client helps you with.
Likewise, the default VMware Server/Workstation/Player setup is with bridged networking; VMware Fusion on Mac OS X likewise. But, as you noted, you currently seem to have to do this manually with KVM/QEMU.
On January 7, 2011 06:37:15 pm Nico Kadel-Garcia wrote:
I haven't tried that, but wouldn't you bridge the bond device instead of bonding bridged nics?
That would make sense, but it didn't work at all. I assume this is because the features are simply not simultaneously supportable.
Works fine here.
On Sun, Jan 9, 2011 at 4:51 PM, Alan Hodgson ahodgson@simkin.ca wrote:
On January 7, 2011 06:37:15 pm Nico Kadel-Garcia wrote:
I haven't tried that, but wouldn't you bridge the bond device instead of bonding bridged nics?
That would make sense, but it didn't work at all. I assume this is because the features are simply not simultaneously supportable.
Works fine here.
Can you pass along a copy of your configuration, especially /etc/sysconfig/network-scripts/ and relevant /etc/ settings for a working KVM domain and network? I'd like to compare.
On Fri, 2011-01-07 at 12:02 -0600, Les Mikesell wrote:
On 1/7/2011 7:02 AM, Nico Kadel-Garcia wrote:
I was testing it with KVM, for comparison to VMWare, and didn't get as far as that. The network configuration, multiple disk at install time, and dog-slow performance of KVM prevented further exploration. KVM was being heavily advertised by RedHat so I wanted a look, and was completely underwhelmed. The requisite "bridged" network ports have to be set manually on the server, since the built-in network configuration tools have no clue how to do it. This means network pair-bonding has to be done in the guest domain, and it turned out that PXE didn't work at all in the guests.
I haven't tried that, but wouldn't you bridge the bond device instead of bonding bridged nics?
That's what I do on our various CentOS 5 and RHEL 5 based KVM clusters (I use CentOS/RHEL Cluster Suite for the storage and KVM clustering bits).
Regards,
Ranbir
On Fri, Jan 7, 2011 at 1:49 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, Jan 6, 2011 at 12:43 PM, Eero Volotinen eero.volotinen@iki.fi wrote:
ESX(i) also requires windows server + management client and Citrix XenServer also requires windows management client.
VirtManager + RHEL 5/6 does not require use of windows client.
virt-manager is too stupid to be permitted to live outside of an intensive care unit. It completely mishandles configuration options that are easily available from the command line, such as the use of mutliple disk drives at image setup time, and has very poor handling of randomized NIC configurations, and it behaves extremely poorly over remote X connections. It also has no clue and little capability to properly handle pair-bonded connections for high reliability upstream connectivity.
For basic management and a bit more virt-manager does the job. And for me it works perfectly well over ssh.