Accessing VMware Server 2 using VMware vSphere client

Though vmware does not support accessing vmware server using VI client, it does work with some limitations. I like vmware server, so i don't have dedicate the server ESXi, this lets you the server for other tasks. Unfortunately the vmware server will run out of support, and it is unlikely that vmware would spend resources to try to make the vmware server GUI any better. Here is how to access to vmware server using vSphere client

Note: You will not able to edit settings of a VM from VI client, you would able to view the VM, do poweron/off operations and view the guest Console.

1. Download VMware vSphere client from vmware site. The version of the software that was tried out is VMware-viclient-all-4-1.0-258902

2. Install the vSphere client on a windows machine

3. Run the vSphere client, and specify IP as full http URL that is used to access vmware server web console like, https://10.209.106.15:8333 and username and password for vmware server access

4. You should see a installer prompt to install compatible client support clients, run the installer, which will restart the vSphere client

5. After vSphere client restarts, enter the vmware server name again and accept the security warning

 6. You should now be able to see the vmware server host in vSphere client. You can do poweron/off operations on any of the virtual machines, but you might not be able to edit settings of the virtual machines. VMware should complain about incompatible version. You will able to see the guest console by going to the 'Console' tab. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008180 provides vmware comment on this issue

Ethereal cooked capture

Cooked capture when capture is done over '-i any' device.

http://www.ethereal.com/lists/ethereal-users/200412/msg00314.html

On Linux, packet capturing is done by opening a socket. In systems with a 2.2 or later kernel, the socket is a PF_PACKET socket, either of type SOCK_RAW or SOCK_DGRAM.

A SOCK_RAW socket supplies the packet data including what the driver specified, when constructing the socket buffer (skbuff) holding the packet, to be the packet's link-layer header; a SOCK_DGRAM packet supplies only data above what was specified by the driver to be the link-layer header.

For the purposes of libpcap, which is the library used by programs such as tcpdump, Ethereal/Tethereal, snort, etc. to capture network traffic, a SOCK_RAW socket is usually the appropriate type of socket on which to capture, and is what's used.

Unfortunately, the purported link-layer header might be missing (as is the case for some PPP interfaces), or might contain random unpredictable amounts of data (as is the case for at least some interfaces using ISDN), or might not contain enough data to determine the type of the packet (as is the case with at least some ATM interfaces), so capturing with a SOCK_RAW socket doesn't always work well.

For interfaces of those types - and for interfaces of a type that libpcap currently doesn't have code to support - libpcap uses a SOCK_DGRAM socket, and constructs a fake link-layer header from the address supplied by a "recvfrom()" on that socket.

A "Linux cooked capture" is one done with libpcap using a SOCK_DGRAM socket.

Remote desktop shortcut for shadow/console session

The microsoft KB article suggests a way to connect to the console session http://support.microsoft.com/kb/278845. So even if you are disconnected or you want to connect to the active physical desktop session, then you can do so by specifying '/console' option to mstsc. Unfortunately there is no check box or any other way from mstsc GUI to specify to connect to a console session. A simple workaround is to change/create a shortcut for mstsc by adding '/console' as arguments to mstsc.exe in the 'Target' field.

Differential gear