Introduction to the Preconfigured Qemu Grid tools

Understanding the current forms in which the qemu preinstalled images are distributed requires understanding how the 'pieces' of Plan 9 fit together. To summarize, a standard modern Plan 9 system is built from a Venti server providing archival data storage, a Fossil server providing a termporary write buffer to the Venti and serving the data via 9p as a filesystem, a CPU server to run applications, and a terminal to provide a graphical display and control of the i/o devices. These pieces are independent, and can be setup as a single, all-in-one system, or each can be provided by a separate machine. A medium-to-large Plan 9 installation may have multiple machines performing each of these roles, with the user terminal making use of some resources from each.

The qemu gridtools allow the user to easily and quickly create a local grid of these plan 9 services, either on a single machine 'distributed' amongst VMs, or using multiple physical machines in various roles. We will step through the simple default setups created by the gridlord utility in the gridtoolsplus version. The user unpacks the distribution, cd's into the gridtoolsplus folder, sets up port redirections as superuser using tools/iptablescript, and then starts gridlord. What happens next:

• The user selects option '1' to start the local Venti server. The primary content of the distribution is the data files for a venti server. The gridtoolsplus version includes the plan9port binaries for venti and vac, so it starts serving the data from the files located in the ventidata subdirectory. The p9p venti is now serving read and write requests on port 17034. (Note the default config listens 'openly' so users with systems directly exposed to the internet may wish to change the listener in venti.conf to listen on local loopback only, tcp!127.0.0.1!17034)

• In this example, the user will activate the full multi-machine config by skipping option 2 for a combined file/cpu/auth machine and using options 3 and 4 to separate those functions between two different VMs. The user presses '3' to start the file server. Note that the disk image for the fossil1 file server is initially stored in the venti server and so gridlord will download the image from the local venti if a copy does not currently exist. This is done by unvaccing the .vac file for the virtual machine stored in the vmvacs subfolder. Once the copy is retrieved (or directly if the machine already exists on disk) gridlord launches it using the tools/qemufossilauth qemu launcher script. The qemu launcher command is executed in an xterm created to control the VM. The fossil1 file server starts and is configured to boot up serving fossil and auth. The fossil1 file server is backed by the same p9p venti it was extracted from.

• After the boot process of the fossil1 server has completed and it is sitting peacefully at its hostowner console prompt, the user selects option '4' to start a cpu server. Again, the gridlord script checks to see if the cpu1 vm already exists on disk, and fetches a copy of it from the venti if not. It launches cpu1 with another controlling xterm. Cpu1 is started with the poorly named tools/qemunofossilauth script, which is configured to run service listeners for the base cpu services and also authenticated telnet, ftp, and a demonstration web page on port 8080. CPU1 is also configured to tcp root boot from the local fossil1 file server. Cpu1 connects to fossil1, boots up, and then also sits at the hostowner prompt.

• The user now presses 'g' to start a Drawterm connected to localhost as user 'gridna'. A drawterm window pops up and the user enters password 'gridpass'. Drawterm takes on the role of terminal, providing graphical display and i/o for the user. The user is now logged into a 'normal' Plan 9 environment with the added bonus of the ability to work freely in with files in both the host operating system and the VMs, due to drawterm's integration of the host filesystem at /mnt/term. Here's a picture of the structure of the environment that has been created:

So this represents an example of building a 'distributed system' on a single box. The same architecture could be used with each component running on a separate machine. One machine run the venti and be dialed by the fossil on a different machine at boot, which in turn will be dialed at bootup by the cpu server on a separate machine, which in term can be connected to remotely via drawterm from any location. Furthermore, additional nodes can be added in, such as more file servers and cpu servers. Any number of cpu servers can in theory boot from a single file server, any number of file servers can connect to a given venti, and the user may make use of all of the resources in the configuration they wish from their terminal.

Creating customized systems between machines and with additional nodes of requires some reconfiguration - for instance, a fossil file server needs to know the IP address with which to dial the venti server. The gridtools include in /usr/bootes/bin/rc a confighelper tool to assist with customizing grid nodes.

The above description was based on the prescripted actions of the gridlord tool provided for linux and made use a linux-hosted plan9port Venti. The same distributed architecture can be created on Windows machines, or Linux/other UNIX related OSes not using Plan 9 port. It should be noted that the 'full' architecture shown above is not required for the use of Plan 9 or the 9gridchan qemu tools. It is entirely possible to use the standalone version of the image as a single all in one machine with local fileserver - and if you wish, you can even dispense with drawterm and use the virtual machine via its own graphic interface.

To implement the full distributed architecture without plan9port venti, it is necessary to shift the role of Venti server to a qemu VM. There is no difference in the ultimate environment created for the user, but currently this configuration needs to be created by the user by launching the VMs in turn with the appropriate port redirections. The preconfigured machines assume they are all being run on the same physical machine and communicate with 127.0.0.1 (not configured as loopback!). If you wish to separate them to different physical machines, the capacity to specifiy venti server address and name at boot may be convenient in helping reconfiguration.