Chronophage.net Blog

Elastic Sky X. That’s what ESX stands for. Crazy, right?

Well, more playing means more caveats

First, something I forgot to mention yesterday. To get ESX working in Ubuntu, Workstation needs to be able to put the vmnet interfaces into promiscuous mode. That requires allowing the user or group that you use to start Workstation to have read/write permissions over the vmnet devices in /dev. A simple chmod will do the trick.

Now, back to our story…

I decided to try to add some additional network paths to hopefully improve I/O. In the last post, I mentioned the VM within a VM was *painfully* slow. Well, change *painfully* to *detrimentally*. The whole environment was prone to timeouts, something that vSphere doesn’t always seem recover from gracefully.

This is understandable. Enterprise software expects an enterprise environment. Something that day hackers should appreciate. (see the perpetual “Linux Vs BSD debate” ) Dinking around is going to generate problems that one would not see in a production environment. It’s a pet peeve of mine when people review software, give it inadequate resources, and complain about the end results.

That being said, I had problems.

Adding a second nic to the ESX VMs required 2 restarts per host. Arbitrarily. The first host’s second NIC did not work via DHCP (again, not something I would rely on in production) and had to be manually configured. The second host dropped all of its routing information, and again, needed to be set up manually. I attempted a restart on both, just to see what would happen. The first host again had to be set up manually. The second came back fine or so I thought…

After playing the restart shuffle, I had both NICs in place. I decided to try creating a distributed switch. Creating a distributed switch is a three part process, that requires two views. First you create the switch in the Networking view, assigning an uplink NIC to it. Then you configure the ports. Then, back in “Hosts and Clusters” you have to add the port type (VMkernel, Service Console or VM Network) After setting it up, the distributed switch propagates to all of the hosts that you’ve assigned to it. It’s more or less a way to have a consistently configured network across multiple hosts. Very slick, but very expensive. I have a feeling that this methodology will be come more standard amongst VMware‘s competitors, and will be rolled into the product at large, or at least lesser license levels. Still, networking, as my boss is prone to say, is like plumbing. If it is done correctly, there’s no need to redo it.

Unfortunately, my second ESX host failed to take the Distributed Switch configuration due to it timing out. This caused the host’s network information to become broken. How broken? Well, I poked around for a bit, and decided it was faster, and easier to install a new ESX VM. If I have time, I’ll look at the host and figure out what’s wrong, as learning to troubleshoot vSphere is a secondary goal of mine for this project. However, for now, this new ESX VM gave me an opportunity to play with the second big “Enterprise Plus” feature. Host Profiles.

Host Profiles allow you to create templates based off of existing hosts. You can then store the Profile, update it, and apply it to other hosts. After bringing the new ESX server online, I created a profile from my original ESX host. I then put the new one into Maintenance mode, attached the profile, and applied it.

After a quick summary of what changes it was going to make, It started the application process. I don’t know how it ended, as it was midnight this morning, and It was well past time to hit the hay. I assume things went well

It was interesting to see in a few lines, all that I’ve done to configure my lab machines, and it will be nice not having to do it again. Although configuring ESX is hardly an arduous chore, (well, it’s slightly painful with my lab’s limited resources) I can see how configuring more than a handful at a time would be obnoxious. Host Profiles aren’t exactly necessary as, like networking, you’re not going to constantly provision new servers. If you’re in an environment that does, you’re probably a large company that can afford the licensing fees, and the cost/benefit factor is in your favor. Still, it would be nice if you could simply copy the config from one server to another in lesser editions of vSphere, without storing the profiles or being able to update them. That would be a good compromise, and I think will become standard with VM infrastructures across the board. Red Hat does something similar with it’s OS centric Satellite/Spacewalk servers, which handle both initial configuration and update management. It’s not nearly as slick, as you do need to “script” installations.

Well, that’s day two of the “fully functioning” lab. We’ll see if the Host Profile worked on the new ESX VM

• Share
• Tweet
• "&title=""">