VMware has become aware of an issue with the vSphere Web Client 5.0 failing to load with the error: RSL Error # of 29 Error 2046 Note: The RSL Error (# out of 29) number may fail at different values. Note: This issue only impacts only the usability of the vSphere Web Client 5.0 This […] http://bit.ly/1IwyhNW
New Post has been published on Gronau IT Consulting / vPierre
New Post has been published on http://vpierre.it/wp/vmware-esxi-5-x-ssh-warning/
VMware ESXi 5.x SSH Warning
Da es immer wieder vorkommt, dass man vom Kunden auf die automatisierten Warnungen im vSphere Client angesprochen wird, hier einmal die Lösung zum beheben des Warnungsstatusses für eingeschaltete SSH Serverports auf dem ESXi 5.x:
Hinweis:
Generell sollte man die Warnungen und Alarme, insbesondere auf den Hosts nicht einfach arglos, wegklicken oder übergehen. In diesem speziellen Fall kann der Bediener die Warnung aber nicht selbständig “wegklicken”, ohne die KOnfiguration des Hosts zu ändern. Wird der gelbe Warnhinweis neben dem Hostsymbol ignoriert, könnte es durchaus passieren, das man andere Warnungen bezüglich RAM, CPU oder nicht redundanten Pfaden zur SAN NICHT mehr sieht oder beachtet.
Die SSH Konsole ist sehr hilfreich für alle, die lieber auf die Shell – als die PowerShell – setzen oder eben manchmal etwas genauer hinschauen wollen.
Zunächst muss man den
SSH Server Dienst starten und anschließend in der Firewall auch die Zugriffe auf Port 22TCP – inbound erlauben
. Das erreicht man über den Menüpunkt:
ESXi Server | Konfiguration | (Software) Sicherheitsprofil
Im Anschluss muss man jetzt den Nag-Screen verhindern. Das geht ebenfalls über die GUI des vSphere Clients am einfachsten:
ESXi Server | Konfiguration | (Software) Erweiterte Einstellungen
User.Vars | User.Vars.SuppressShellWarning = 1
Die Warnungen verschwinden sofort vom ESXi Server Symbol. Die Einstellung ist persistent.
You know whenever VMware forces you to use the CLI tools you are in for a rough patch. Today was certainly no exception to the rule. I had updated the vCenter server and some of our hosts in the Production cluster at work to vSphere 5. VUM said that the rest of the hosts were incompatible. Why you ask? Because the hosts had OEM software modules that were not supported with ESXi 5. Simple enough, I think, I'll just remove those software modules.
Well, guess what? You can't remove the software modules. There is no esxcli or PowerCLI command to do it. There is no function from within the VI Client either. You can see the software modules, but right-click to your heart's content. It will not avail you. The closest command I could find involved the vicfg-advcfg command. Be warned though, here there be dragons. I may shoot from the hip on occasion, but I was not feeling enough of a cowboy to disable the OEM CIM service to see what would happen. I have this vision of the blade server exploding and raining shrapnel across the datacenter.
The offending module was a Dell OEM ESXi VIB that probably came from a custom ESXi 4.1 installer supplied by Dell. You might question why some hosts had this custom version, and not others? Well, there is no good explanation. As far as I can tell, we moved several hosts from Dev to Prod a while back and my associate used a Dell installer to get the OpenManage VIB. Unfortunately, we did not use this image in Dev, so it never came up when I was testing the upgrade. What does VMware suggest? That you should build your own custom installer using their PowerCLI Update Manager suite and then add your own VIBs to the image.
Dell has their OpenManage VIBs on their site. Just don't use their search tools, b/c that will only find the ESXi 4.1 compatible VIB. Another search FAIL for Dell, it's a good thing that Google indexes their site better than they do. I found the VIB, installed the PowerCLI Update Manager, and read through their cryptic documentation. After 30 minutes, I had read between the lines and actually managed to build a custom ISO including the Dell VIB. I added it to VUM, attached the baseline, ran a scan and ... Incompatible.
What. The. Fuck.
Before you ask, yes I did tick the little box in VUM that removes third-party software that is incompatible. The upgrade still failed. So it looks like although Dell updated their VIB, it does not upgrade the older version. Dell FAIL number two for the day.
I finally broke down and installed ESXi 5 manually using the ISO from VMware. There is a Force Migrate option that apparently is much more forceful than VUM in this regard. It tells you so several times (lots of big red warnings and hitting special accept buttons). After convincing the installer that I did, in fact, want to force the migration, all proceeded normally. This is good news, in that I do not have to do a clean install of ESXi on each server. Still, it is a manual process and I have to repeat it six more times. It would have been much nicer to use VUM. I suppose if I had a datacenter with 100 hosts in it, I would find a scripted way to do this.
Now I have to wait until the next maintenance window to complete the upgrades, unless I can get special dispensation to do the upgrades at night. But since it is a manual process, I don't really want to do that. Maybe in the morning before anyone else comes in. I'm up at 5:30 every morning anyways.
vSphere Storage Appliance lowers entry point for smaller customers
I’m preparing for the first day of VMworld 2011 and one of the sessions i’m most interested in for tomorrow discusses the newly announced vSphere Storage Appliance.
Given the ever increasing compute density of modern x86 servers, many of our clients fit into a scaled down architecture where two to three powerful hosts will provide them with more resource than they can reasonably expect to consume. For these clients the largest hurdle to enterprise grade virtualization is the requirement for a powerful and sometimes costly shared storage array.
The vSphere Storage Appliance is designed to provide high-availability storage to exactly this type of small-scale architecture. The storage appliance provides storage to virtual machines not from a shares storage array connected to vSphere hosts, but from disks installed locally within each host in the cluster.
Key Benefits
Five-Click Simplicity
High-Availability with no shared storage hardware required
World-Class datacenter capabilities for small environments
The VSA supports up to three hosts in a cluster and currently has some limitations including the inability to change the disk allocation and layout after initial setup, an issue which VMware states will be addressed in a future update.
If this product plays out as I expect within our designs, it will only serve to lower the entry point for our smaller clients and further remove any barriers that may be left for them to move towards virtualizing their environments.
Greg Ferro writing on his Blog Ethereal Mind says that even with the update to vSphere 5 VMware still does not provide “proper networking” in their virtualization hypervisor and grades the upgrade a D- on networking capabilities.
Colour me dubious but a 300% price hike in vSphere licensing for this ? They are definitely taking the mickey. Even with the backdown that delays the price hike to a couple of years in the future (when everyone has forgotten about it), we still don’t have proper networking in VMware.
I think the problem here is just one of perspective, VMware provides powerful easy to use networking features that server admins demand. VMware is primarily selling their products to the server admin camp within enterprise environments. They need to make sure that these groups can implement vSphere with as little fuss as possible and that includes imposing minimal impact on the upstream physical network.
The features added with vSphere 5 in regards to networking will be greatly appreciated and are starting to move the included networking functionality towards providing a more comprehensive solution to their customers. Both NetFlow and port mirroring support are welcome capabilities in my book.
For those network engineers that are looking for more complete network capabilities in VMware vSphere, they have built a pluggable architecture that lets vendors provide their own virtual switching infrastructure and provide an experience and feature set more familiar to network admins. The Cisco Nexus 1000v is the solution for those customers right now, hopefully more vendors will provide their own solutions in the future.
This positioning allows VMware to provide easy to use, easy to implement networking features to the vast majority of their customers and provides a extensive highly capable solution to those that are looking for more.
How is this a D-? I’m not saying there is no room for improvement, but I would give it at least a solid B at the moment.