I find out that I often need more than one CPU server in my Plan9 environment, but being restricted to using it under VMware I have to create several copies of the original Plan9 vmware image, which takes too much space... So I created an extremely small (10MB it total) VMware image containing bootable 9pccpu and 9pcdisk kernels.
With this image it is possible to fire off as many cpu servers or terminals as one desires, provided that there is at least one vmware session running the original plan9 vmware image, and configured as a auth/cpu/kfs server -- all one has to do is copy the (small) vmware image into a new directory and run 'other.cfg' (if using linux' vmware).
It is also possible to use this vmware image as a terminal to remote plan9 networks, just in case you hate drawterm :)
You will also need to create an Auth/Cpu/Kfs server within a vmware image. The instructions to do so are located in the Plan9 wiki pages.
Once you have created all of the above simply download the vmware image from here (unix) or from here (windows).
UNIX: if your vmware is set-up correctly you will be able to just untar the image and run 'cpu-term/other.cfg' which will immediately start the vmware session. If not, then set up the image the same way you did the full Plan9 vmware image (the operating system type is Other, the disk image is other.vmdk).
Windows: just create a new vmware configuration identical to the one you already created for Plan 9 in vmware. The operating system type is Other, the disk image is other.vmdk
Once you have started vmware and have connected to the cpu/auth/kfs server you may modify Plan9.ini to suit your needs -- for example, removing the prompts for mouse/vgasize once you know what fits your machine best. For example, here are the default options for my term section:
You may with to change the default behaviour to booting terminals only, or compile and install custom kernels to suit your needs. Note: The size of the 9fat partition is purposely kept at a minimum ot 10 MB. You will be restricted with respect to the number of kernels you can keep there.
When you know your auth and file servers you can add them to the [common] or [cpu] section of plan9.ini:
fs=192.168.233.128 auth=192.168.233.128Note that I have a cpu/auth/kfs server all in one, hence the auth server is the same as the file server in this case.
The only thing that causes any problems with this setup is the nvram partition that stores the cpu server login information. If you ever enter incorrect values and are unable to login to the remote server simply boot the term kernel and do a echo blablabla > /dev/sdC0/nvram. The kernel will prompt you for bootes' login information on the next reboot.
There is some trickery involved with setting the authdom and secstore password entries in nvram -- make sure they match the ones on the other end of the connection (the ones that are correct for the authentication server.
If you have a non-vmware server you're connecting to it may be desireable
to switch to a different network model with you images, otherwise you will
not be able to connect to them and execute cpu commands remotely. One
solution that I have seen successfull is to configure them with host-only
networking and then use iptables to redirect ports 17013 and 567 on the
external NIC to the internal vmware ip addresses.
Example (external is fbsd.cpsc.ucalgary.ca, the cpu server is booted at 192.168.1.2):
iptables -t nat -A PREROUTING -p tcp -i eth0 -d 220.127.116.11 --dport 567 -j DNAT --to-destination 192.168.1.2 iptables -t nat -A PREROUTING -p tcp -i eth0 -d 18.104.22.168 --dport 17013 -j DNAT --to-destination 192.168.1.2The first one redirects port 567, the second -- port 17013.