For supported guest operating systems, VMWare supplies VMWare Tools, which allow one to do cut-and paste, time synchronization, and other operations between a guest system and its host system. Minix, unfortunately, is not yet a supported OS for VMWare. However, Ken Kato <email@example.com> developed a set of VMware Command Line Tools for DOS and Windows 9x/NT, and Markus Gyger ported these to Linux and Solaris. Kenichi Takahagi then ported these to Minix. For more information see the page on VMWare tools for Minix.
The tools are simple but useful, and worked right away. I'm using the ability to transfer text between the Minix screen and the clipboard of a Windows host system while writing the first draft of this document. It's limited (without a way to select text with a mouse you can only capture a full screen on the Minix side, and without a hot key for pasting you can only paste into standard output from the command line), but it's still useful.
Vmw is a simple command line user program for Minix. Not part of the tools per se is a patch, also provided by Takahagi, for the Minix console and keyboard drivers. This enables the F4 key to be used to copy the Minix console to the host clipboard. For my work this is very useful -- for teaching and for debugging Minix problems I often want to be able to capture Minix output, even output of the bootup screen or the various other F-key debugging displays. I will show an example of this use in the next section.
Here are a few more notes on this screen capture tool:
I experimented with Minix on VMWare back in early 2003. At that time I determined that Minix worked as a VMWare guest on a Windows 2000 host, but without an easy way to transfer data between the guest and the host it was not an adequate environment for my work, much of which involves writing about Minix. The port of the VMWare Command Line Tools is one part of a solution. Even more useful for my purposes, Takahagi also has provided Minix drivers for the AMD Lance ethernet card emulated by VMWare.
The Lance ethernet driver was easy to compile into a new Minix kernel once I had transferred the files to the Minix guest on a floppy disk. The package contains an alternate implementation of PCI support in the files pci.h.neweth pci.c.neweth, and their purpose wasn't really clear to me. In e-mail Kenichi explained to me that these were written by Kazuya Kodama to provide minimal PCI support for Minix 2.0.2, but are not needed for Minix 2.0.4 which contains Philip Homburg's PCI support files. So I did not use these.
Soon I had a Minix kernel that supported the Lance ethernet card. Here's an example of the use of Takahagi's F4 screen capture to show the screen after booting Minix on VMWare:
Minix 2.0.4 Copyright 2001 Prentice-Hall, Inc. Executing in 32-bit protected mode at-d0: VMware Virtual IDE Hard Drive Memory size = 31239K MINIX = 1399K RAM disk = 0K Available = 29840K Tue Apr 19 11:22:34 PDT 2005 /dev/c0d0p0s2 is read-write mounted on /usr at-d1: VMware Virtual IDE Hard Drive /dev/c0d1p0 is read-write mounted on /usr2 Multiuser startup in progress. eth_card#0: AMD Lance/PCI (1022/2000) at 0.16.0 eth_card#0: using I/O address 0x1060, IRQ 9 eth_card#0: PCnet/PCI-II 79C970A at 1060:9 Starting daemons: update cron nonamed talkd shell login telnet ftp. . Minix 2.0.4 on VMWare with vmw and networking! Minix Release 2 Version 0.4 walnut-vm.woodhull.com login:
Getting Minix working with the VMWare-emulated Lance ethernet adapter was the easy part. After that I spent some frustrating hours trying to get Minix to connect to the network. When I first booted the new kernel it could only ping or connect to itself. From the VMWare on-line documentation and all the information I could find by searching on the net it appeared that VMWare ought to automatically detect and pass packets through the ethernet adapter used by my Windows 2000 host system.
Eventually I discovered that when VMWare is installed it adds an option in the Windows networking configuration, but does not enable it. You need to go to the Windows Network and Dialup Connections control panel and select the Properties of your ethernet card. You will then see that in addition to the familiar Client for Microsoft Networks, File and Printer Sharing, and Internet Protocol (TCP/IP) options already selected, there is now an unchecked VMWare Bridge Protocol option. Once I checked this (and rebooted Windows) the VMWare Virtual Network Editor showed that a bridge existed between VMnet0 and my Intel 21041 ethernet card, and I was able to connect between my Minix guest system and other systems.
By default VMWare wanted to use dhcp to assign an IP address to my guest system. I decided to disable this and use ifconfig(8) and add_route(8) commands in /etc/rc.net. I had two reasons for deciding to do it this way. First, when I tried using dhcp I periodically received annoying messages from dhcpd on the Minix console. I'm sure I could have added a dhcp.conf file or by some other means configured Minix for dhcp, but it seemed easier just to hard-configure my system. The second reason for not using dhcp was that I could not find a way to make the VMWare dhcp service hand out fixed IPs. It seems to provide only dynamic IPs, and I wanted to fix the IP for my Minix guest system.
Once I had my Minix guest system properly working through the bridged ethernet I had no problems. I have used telnet to and from the guest Minix system and have transferred moderately large files by ftp without apparent problems. Also, I have not tested the other networking modes available, Host-only and NAT. I should emphasize that the problems I encountered were mostly because the VMWare documentation did not point out that changes to the Windows configuration were needed. If you have read this, now you know what I didn't know. Also, all of these experiments were done with VMWare Workstation 4.0.5. Perhaps the documentation will be better with version 4.5.2 -- it's a free update from the version I have, and I downloaded it but haven't installed it yet. I will update this article when I have had experience with a newer version of VMWare. It's an expensive program, however, and I don't expect I will move up to VMWare 5.0 very soon.
One other oddity caused me some head-scratching. In the default Minix /etc/rc script a call to the /etc/profile script, which sets the TZ (timezone) environment variable, follows a call to readclock(1), which synchronizes Minix with the CMOS clock. TZ determines how time will be displayed to the user. If you don't set TZ at all it will be GMT by default, and Minix assumes that the hardware clock tells GMT. The readclock man page points out that if the hardware clock keeps your local time, you should change the order of the calls in /etc/rc so the call to /etc/profile comes before the call to readclock. In other words, TZ should indicate the same timezone as the hardware clock is set to before the readclock call. After the readclock call TZ can be changed again to indicate the timezone you want to display.
With my Minix guest running on VMWare on a Windows 2000 system I could not make the time come out right, whether I set TZ to my timezone before or after the readclock call. Finally I recalled that a new Windows installation always starts out configured for the US Pacific timezone, since that is where Microsoft is located. What worked for me was to add a line to /etc/rc setting TZ='PST8PDT,M4.1.0/2,M10.5.0/2' before the call to readclock, and then call /etc/profile (which on my systems sets the zone to US Eastern Time) after the call to readclock.
Why this should work this way is not clear to me. I thought initially it was because Microsoft is based in the state of Washington. (I tend to blame Microsoft first for anything wierd on a Windows system). But eventually I concluded that this was a choice made by VMWare, which is based in California. I have run Minix in native mode on other systems on which I primarily use Windows 2000, and on those systems the clock when initially read by Minix shows the time as set in Windows -- which is always US Eastern Time on systems I control. This is definitely the case on the system on which I have been testing VMWare. However, it appears that regardless of the timezone the host Windows system is using, VMWare presents an emulated CMOS clock to a guest OS that is adjusted to the local date and time in California.
I am grateful to Mendel Rosenblum of VMWare who arranged for VMWare to provide a licensed copy of the VMWare Workstation program for experimentation with Minix as a guest OS.
On the Minix Hints/FAQ page there is a section on Hints on Minix 2.0 for emulated and virtual platforms with links to a number of other articles about Minix and VMWare, as well as links to articles about Bochs, Virtual PC, and QEMU, all of which are potentially useful as platforms for running Minix.
|[HOME]||[HINTS/FAQ]||[MINIX DOWNLOADS]||[CONTRIB SOFTWARE]|