hmmm, beginning to think that the biggest problem that I've had with vmware is that I couldn't find a logo for the post ... spent a good 5 minutes looking for one!
I've been asked at work to setup a number of new vmware machines on a virtualised server in a completely different location (not easily geographically reached). This would be OK under normal circumstances, but the machine has already been setup and I have spent so bloody long trying to get this working, that I thought that I would document a small amount of it so that I wouldn't forget how painful this has been.

The first problem that I encountered was that the documentation passed on by the previous sysadmin listed the server as been @ 10.1.0.2, but I actually found the esx server at 10.1.0.3, which was only found by nmap scanning the port range around it. One of the things that threw me off was the fact that the 10.1.0.2 showed up on the nmap scan as responding on an unusual port, I now think that this is/could be an Intel Lights Out Management system (need to confirm this).
I initially assumed that 10.0.0.2 must be the Virtual Center Management server for vmware (as my boss had said that there was an easy way to clone the virtual machines) ... you know what they say about assumptions ... whoever had set this system up had decided that it wasn't worth installing a Virtual Center to admin the esx server (which is fair enough, as you need to licence it). I installed the Virtual Infrastructure Client on a vmware box on my linux workstation (that is a confusing mouthful), pointed it at the esx server (10.1.0.3) and voila as they say, the virtual machines that our company has magically appeared! Two major things jumped out at me about 4 hours later:

1. There didn't appear to be an easy way to create a clone of a machine (although there did appear to be some preconfigured images there
2. & the console to view the different servers didn't work

In my usual way, I decided to tackle things ass about. After some judicious googling, I found that the way to create images for the esx server without a virtual center is with a tool called vmkfstools ( http://www.vmware.com/community/message.jspa?messageID=575065). There was only one question - where the hell do I run this mythical command? I spent a fair amount of time in the Virtual Infrastructure Client just poking around, seeing if I could make stuff run from there until I was pretty sure that I'd wasted enough time. On a whim, I decided to go over the nmap logs again, and to my suprise I noticed that the esx server was running a http & https server along with a ssh server - this must be it. I tried ssh'ing directly into it using the only account that I had (the root account), but the guy who'd set this up had been cagey and done what I would have - disabled the root account. I then tried accessing stuff via the web browser, but found that there was slightly less functionality in that than the Virtual Infrastructure Client and the remote console _still_ didn't work!
The next day, I logged back into the Virtual Infrastructure Client and noticed the Users and Groups tab under the root host - I added an account to this, gave it shell access and I was in! I immediately tried the vmkfstools command, but found that it was not there, and I spent a couple of hours investigating the server. In the end, I found the tools under

The vmware images were relatively easy to find in

And I created my first clone of an image like this:

The console notified me that it was cloning and after a while it came back.

I then logged in to the Virtual Infrastructure Client and looked for the new image, just to realise that the esx server didn't know about it. It was a simple thing to create a new image, and to point it at the new image which had been created. Unfortunately, I then hit another snag. I could power the thing on but I had no way of knowing whether or not anything was happening. I tried a number of things such as hitting my head against the wall, stabbing myself repeatedly in the hand and trying to the use the Virtual Infrastructure Client/Web client, they were all as effective as one another!

I decided that because the esx server is sitting on what is effectively a cut down linux box, the logs might tell me something and surely enough they did. The log that I found interesting was (suprisingly enough) the secure log:

Every time I tried to connect the remote console to the server, I got this repeated set of failures but what struck me was that it was trying to listen on port 903, which didn't have anything listening on it. After some googling, I found the following site ( http://www.vmware.com/community/thread.jspa?threadID=46632 ), in which one of the developers (kitcolbert) notes:

Here's one thing you could try:
- ssh to your ESX box
- add the following to /etc/vmware/config:

vmauthd.server.alwaysProxy=TRUE

- try reconnecting

Hopefully that should allow you to work around the problem.

he goes on to say

Sorry, I should have been more upfront about this: the remote console not working is definitely a bug! The workaround I gave above is exactly that: a workaround. We didn't document it because we didn't think anyone would need it. Unfortunately that's not the case. Be assured that we are investigating this issue.

One question: do you (or anyone else on this thread) have any NAT'ing going on between the remote console and the ESX machine? There is a known (and understood) issue for that. However, if you simply have two subnets connected by a router, then that would be a new issue. Is there anything interesting or fancy about the routing? The reason I ask is that I believe we have people here in-house connecting the remote console across subnets to the ESX server. Thanks.

After I added this, I tried to reconnect and it worked!!! esx logs now say:

To the best of my knowledge, this is a problem when you're trying to connect across different subnets.

<Unrelated Update>
I had troubles adding an extra disk to the esx server, it wouldn't let me create a disk greater than the default one set (in my case it was 3Gb). It turns out that it's a bug that can apparently be gotten around by rebooting the physical server ( here ), but as that gives me the willies, I went the approach mentioned in that document and did a:

and then attached it as a new disk.
</Unrelated Update>

<Unrelated Update #2>
Just a quick explanation of the network devices in vmware:

So it looks like it's assigned in /etc/vmware/locations
</Unrelated Update #2>

Popularity: 100% [?]

Everybody's a critic (3 votes, average: 4.67 out of 5)

 Loading ...