[5941] in Release_7.7_team
Re: [Vmware-release] running Athena virtual machine from off-campus
daemon@ATHENA.MIT.EDU (Alex T Prengel)
Tue Mar 18 16:05:34 2008
Message-Id: <200803182004.m2IK4oHf027714@dit.mit.edu>
To: vmware-release@MIT.EDU
cc: alexp@MIT.EDU, gettes@MIT.EDU, release-team@MIT.EDU, jdreed@MIT.EDU,
blang@MIT.EDU, ops@MIT.EDU
Date: Tue, 18 Mar 2008 16:04:49 -0400
From: Alex T Prengel <alexp@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
Hi everyone,
I've been running a VMWare virtual Athena machine from off campus
behind a NAT box for a while now and have had a mostly good
experience. I think this is quite promising as a means of providing
Athena access to non-UNIX users, provided that we can iron out the
kinks. I'm thinking of students or faculty with Windows machines and
Macs who don't want to dual-boot and install Linux or Linux-Athena or
use dialups but who do need to access Athena.
My testing environment- Verizon FIOS, using Verizon's standard
Actiontec router as configured by them- most testing done on a Windows
Vista host, using the free VMWare player to run the VM.
What I did: I copied an Athena VM kindly provided by BillC, changed
the root passwd using /etc/athena/passwd in single user mode,
requested a static IP address for it, set ADDR to it in
/etc/athena/rc.conf, then registered for a DHCP address for it using
the method recommended for users already having a fixed IP address.
I then edited /etc/athena/rc.conf again, setting /etc/athena/rc.conf ADDR
to dhcp (thanks to Bill again for telling me this works). I left HOST
set to the host name I was given when I got the fixed IP address.
When I installed this VM on my home system it came up fine, the VM was
quite responsive and used a minimal fraction of the CPU when
running. Things work. I noted as we found before that if I suspend and
resume it more than about 5-6 hours later, I lose AFS and network but
these come back when restarted. Interestingly, when I leave the VM
running but logged out this doesn't seem to happen. AFS generally
seemed to work fine, though occasionally I seem to lose tickets/tokens
unexpectedly, before they're supposed to time out. Rerunning kinit
and aklog fixes that but I'm not sure what causes it- maybe some of
the tinkering I've been doing a lot of.
It's definitely necessary to run the time synchronization utility within
VMWare tools- otherwise time runs much to slowly in the VM and
anything related to Kerberos dies due to time being too far out of sync.
I seemed to be fine after turning time sync on.
I wanted to see if I could get a VPN working in the VM so I installed
vpnc into it, which I had used before (from vpnc-0.3.3-1.2.el4.rf.i386.rpm).
This is Cisco-VPN compatible, and has the advantage of not needing a
kernel module. The rpm doesn't seen to fully configure itself so I had to
do a bit of this by hand, and also had to edit a configuration file to
get around a minor bug when using it on RHEL4.
Once I did that and started it, I could run things like Matlab and other
MIT-limited software. As a bonus the "from" command worked, which didn't
before because of kerb4 dependencies presumably. zephyr worked on one
attempt but not later, but I didn't invetigate further. jdreed tells
me I may need to restart zhm after starting the VPN so I'll experiment
with that some more.
There was a problem with updating- the VM repeatedly tried to autoupdate
but couldn't get past 9.4.43. Poking through the log showed there was a
conflict between the VMwarePlayer rpm introduced into the release and
the VMwareTools rpm installed in the virtual machine. I presume removing
either will fix this but I haven't tried that yet. I don't know if there's
a simple way to get around this as we'll want the VMwareTools rpm in the VM.
Is there a way to update an Athena release without a particular rpm
(VMwarePlayer) or some other simple way to avaid the conflict?
I didn't try this on a Mac because I don't have access to an Intel Mac at
the moment. Mike Gettes has tried that and has run into some problems (with
excessive CPU load and time sync, among other things).
In thinking about how to productize this, the main issue I see is how
to generate IP and MAC addresses for users in an orderly way (as Greg
Hudson has already noted). The full VM compresses into about a 1.4 gig
zip file, which is within reason for a download, and which also lets
it fit on a 2 gig flash drive. Uncompressed, it's about 4.5 gig which
isn't bad even for laptops, given hard drive sizes these
days. Updating the VM is another issue- if users maintain them more
than just temporarily, allowing the VM to autoupdate should be
feasible when we solve the rpm confict issue.
Note to the team and others- I'm not advocating that we make
distribution of Athena virtual machines within scope of phase 1 of the
project- but for me this is one of the more interesting potential uses
of VMWare on Athena, besides making the player available there as it
already is.
Alex
