published: Wednesday, December 10 2008
http://www.virtual-strategy.com/Eric-Siebert-s-Top-10/Top-10-PowerShell-scripts-that-VMware-administrators-should-use.html
I believe the Next Generation Computing is Software Defined Infrastructure on top of the robust physical infrastructure. You can ask me anything about enterprise infrastructure (virtualization, compute, storage, network) and we can discuss it deeply on this blog. Don't hesitate to contact me.
Default IP | 192.168.1.20 |
---|---|
Default name | ubnt |
Default password | ubnt |
Install vncserver (as root): apt-get install vncserver
Choose your desired window size and color depth, then, as an ordinary user, open a terminal and type:vncserver -geometry 1024x768 -depth 24
orvncserver -geometry 1024x768 -depth 24 -pixelformat rgb565
This will prompt you to create a password:
You will require a password to access your desktops.
Password:
Verify
The server will start and tell you where to access it:
New 'X' desktop is foobar:1
Starting applications specified in /etc/X11/Xsession
Log file is /home/jorey/.vnc/foobar:1.log
Open the VNC viewer on your remote machine, enter the hostname:screen and password (use a hostname or IP that your client machine understands), and your Linux desktop will open in a window! Network speed and processor power will affect performance, but it's amazing how many apps will run fine under VNC. You might not be able to play Frozen Bubble, but you can use productivity applications without any trouble.
To kill the server enter a command similar to this, using the appropriate settings:vncserver -kill :1
The reason for killing the session is that you may need to edit the default configuration file that vncserver
creates for you, for example to get the vncserver to run the K desktop environment instead of twm
, you may want to edit the $HOME/.vnc/xstartup
file to replace the line:
twm &
with this line is you use KDE:
startkde &
and with this line if you use GNOME:
gnome-session &
before launching the vncserver again using:
vncserver :1 -geometry 1024x768 -depth 16 -pixelformat rgb565
ssh
session on the machine where you will be running the vncviewer, to request that ssh
listen on a particular port on your local machine, and forward communication on that port down the secure connection to a port on the machine running the vncserver.
For example:
ssh -L x:localhost:y vncserver_machine
means "Start an SSH connection to the vncserver_machine
, and also listen on port x
on my machine, and forward any connections there to port y
on the vncserver_machine
."
Now, the VNC protocol normally uses port 59xx
, where xx
is the display number of the server. So a VNC server on a Windows machine, which normally uses display number 0
, will listen on port 5900
. The first VNC server on linux will probably use display number 1
, and subsequent servers would use 2
, 3
, etc. and so the vncservers on linux will be listening on ports 5901
, 5902
and so forth. By forwarding these ports to a remote machine running vncserver
, you can make the remote VNC server appear to be a server running on your local machine. So, imagine you had a VNC server running as display :1
on vncserver_machine
, and you wanted a secure connection to it from your local machine. You could start the ssh
session using:
ssh -CL 5902:localhost:5901 vncserver_machine
After that, starting up the vncviewer
as follows on your local machine: vncviewer -encodings "copyrect hextile" localhost:2 would actually connect to display :1
on the vncserver_machine
.
Note that the above OpenSSH command-line is deliberately meant to accept incoming connections only from the local machine. This means that to use the ssh
connection that we have just set up, we must connect to it from the same machine, using the special name localhost
, rather than using the local machine's own unique name.
Paolo Conti wrote how to hack VMware tools to work on linux kernels 2.6.18
[CITATION FROM http://www.atlink.it/~conti/2007/12/19/vmware-uts_release/]The error is something like this: The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match your running kernel (version 2.6.18.2-34-default). Even if the module were to compile successfully, it would not load into the running kernel.
With this bug you cannot sync the time with your hosting server, automate shutdown tasks, etc… This problem exist because the kernel source code structure is changed in recent kernels (I guess > 2.6.18). The VMWare tools installation script is looking for the string “#define UTS_RELEASE $kernel_number” into /usr/src/kernels/$(uname -r)*/include/linux/version.h but the UTS_RELEASE variable is now into the file utsrelease.h.
To fix this, you can patch the VMWare tools installation script or just add the content of utsrelease.h to version.h. I suppose the second solution is the fastest one
To do this:
cd /usr/src/kernels/$(uname -r)*/include/linux
cat utsrelease.h >> version.h
Happy virtualization folks!