Dana Internship '08 Summer Research - Recently Updated Pages

Updates

sbanerj1 — Tue, 01 Jul 2008 01:16:14 CDT

There is no abstract available for this page revision.

Manually configured P2P network connection established

sbanerj1 — Thu, 05 Jun 2008 03:44:55 CDT

Taking off from where we last left off, the physical hosts Scofield and Montgomery were connected point-to-point and were communicating with the network settings that were auto-configured by the Avahi-daemon. Today we manually configured the network settings ourselves and were able to ssh

The IP addresses selected were 200.0.1.1 for Scofield and 200.0.1.2 for Montgomery. The addresses were selected such so as to not conflict with private addresses of the form 192.x.x.x. When we first tried the traceroute and tcptraceroute programs to see if we could talk from one machine to another, we received timed out messages, and other times the output was taking an abnormally large time. After restarting both machines we tried the same procedures, while simultaenously having tcpdump capture packets on from the eth0 interface as we tried the traceroute, tcptraceroute, and ssh programs from Scofield to Montgomery.

Everything worked as expected, however the programs took significant time to display information communicated across the p2p connection. However what was puzzling was that when check the transfer rate of copying a file from Montgomery to Scofield, a high transfer rate was achieved. The following is an excerpt of the tcpdump program running on Montgomery while Scofield was talking to it across the p2p connection from one physical host to the other.

16:13:55.496499 arp who-has 147.129.1.2 tell montgomery.local
16:13:56.496494 arp who-has 147.129.1.2 tell montgomery.local
16:13:57.496494 arp who-has 147.129.1.2 tell montgomery.local
16:14:00.496492 arp who-has 147.129.94.4 tell montgomery.local
16:14:01.496494 arp who-has 147.129.94.4 tell montgomery.local
16:14:02.496494 arp who-has 147.129.94.4 tell montgomery.local
16:14:03.496509 arp who-has 216.54.204.186 tell montgomery.local
16:14:04.496493 arp who-has 216.54.204.186 tell montgomery.local
16:14:05.496494 arp who-has 216.54.204.186 tell montgomery.local
16:14:09.496492 arp who-has 147.129.1.2 tell montgomery.local
16:14:10.496493 arp who-has 147.129.1.2 tell montgomery.local
16:14:11.496493 arp who-has 147.129.1.2 tell montgomery.local
16:14:14.496492 arp who-has 147.129.94.4 tell montgomery.local
16:14:15.496493 arp who-has 147.129.94.4 tell montgomery.local
16:14:16.496493 arp who-has 147.129.94.4 tell montgomery.local
16:14:17.496511 arp who-has 216.54.204.186 tell montgomery.local
16:14:18.496493 arp who-has 216.54.204.186 tell montgomery.local
16:14:19.496493 arp who-has 216.54.204.186 tell montgomery.local
16:14:22.159259 IP scofield.local.44524 > montgomery.local.ssh: S 864220585:864220585(0) win 5840
<mss 1460,sackOK,timestamp 41858 0,nop,wscale 6>
16:14:22.159290 IP montgomery.local.ssh > scofield.local.44524: S 731914807:731914807(0) ack 8642
20586 win 5792 <mss 1460,sackOK,timestamp 95086 41858,nop,wscale 6>
16:14:22.159447 IP scofield.local.44524 > montgomery.local.ssh: . ack 1 win 92 <nop,nop,timestamp
41858 95086>
16:14:22.165936 IP montgomery.local.ssh > scofield.local.44524: P 1:41(40) ack 1 win 91 <nop,nop,
timestamp 95088 41858>
16:14:22.166035 IP scofield.local.44524 > montgomery.local.ssh: . ack 41 win 92 <nop,nop,timestam
p 41859 95088>
16:14:22.166136 IP scofield.local.44524 > montgomery.local.ssh: P 1:41(40) ack 41 win 92 <nop,nop
,timestamp 41859 95088>
16:14:22.166149 IP montgomery.local.ssh > scofield.local.44524: . ack 41 win 91 <nop,nop,timestam
p 95088 41859>

Looking at the above excerpt of output, we realized that even though we had manually configured the p2p connection, the local ithaca DNS servers were being queried to verify the authenticity of the other connection. We checked the /etc/resolve.conf file and saw that 3 redundant DNS servers were listed there to be queried. Removing those entries did the trick. We were thereafter able to efficiently communicate across the p2p connection without any significant lags or problems.

The following output is from Montgomery which logs into Scofield via ssh and then executes traceroute and tcptraceroute programs:

reichsfuhrer@montgomery:~$ ssh 200.0.1.1
reichsfuhrer@200.0.1.1's password:
Linux scofield 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
Last login: Wed Jun 4 17:02:33 2008 from montgomery.local
reichsfuhrer@scofield:~$ echo Sco to Wes
Sco to Wes
reichsfuhrer@scofield:~$ traceroute 200.0.1.1
traceroute to 200.0.1.1 (200.0.1.1), 30 hops max, 40 byte packets
1 scofield.local (200.0.1.1) 0.054 ms 0.012 ms 0.012 ms
reichsfuhrer@scofield:~$ traceroute 200.0.1.2
traceroute to 200.0.1.2 (200.0.1.2), 30 hops max, 40 byte packets
1 montgomery.local (200.0.1.2) 0.240 ms 0.210 ms 0.198 ms
reichsfuhrer@scofield:~$ tcptraceroute 200.0.1.1
Selected device lo, address 200.0.1.1, port 53994 for outgoing packets
Tracing the path to 200.0.1.1 on TCP port 80 (www), 30 hops max
1 scofield.local (200.0.1.1) [closed] 0.048 ms 0.026 ms 0.018 ms
reichsfuhrer@scofield:~$ tcptraceroute 200.0.1.2
Selected device eth0, address 200.0.1.1, port 35946 for outgoing packets
Tracing the path to 200.0.1.2 on TCP port 80 (www), 30 hops max
1 montgomery.local (200.0.1.2) [closed] 0.151 ms 0.135 ms 0.117 ms
reichsfuhrer@scofield:~$ logout
Connection to 200.0.1.1 closed.
reichsfuhrer@montgomery:~$

and this is the respective tcpdump running on Scofield:

reichsfuhrer@scofield:~$ sudo tcpdump -i eth0
[sudo] password for reichsfuhrer:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:02:23.878276 arp who-has scofield.local tell montgomery.local
17:02:24.125336 arp reply scofield.local is-at 00:13:72:77:d7:5f (oui Unknown)
17:02:23.878351 IP montgomery.local.34145 > scofield.local.ssh: S 2837644429:2837644429(0) win 58
40 <mss 1460,sackOK,timestamp 813328 0,nop,wscale 6>
17:02:23.878374 IP scofield.local.ssh > montgomery.local.34145: S 2975479000:2975479000(0) ack 28
37644430 win 5792 <mss 1460,sackOK,timestamp 760064 813328,nop,wscale 6>
17:02:23.878490 IP montgomery.local.34145 > scofield.local.ssh: . ack 1 win 92 <nop,nop,timestamp
813329 760064>
17:02:23.929136 IP scofield.local.ssh > montgomery.local.34145: P 1:41(40) ack 1 win 91 <nop,nop,
timestamp 760077 813329>
17:02:23.929280 IP montgomery.local.34145 > scofield.local.ssh: . ack 41 win 92 <nop,nop,timestam
p 813342 760077>
17:02:23.929385 IP montgomery.local.34145 > scofield.local.ssh: P 1:41(40) ack 41 win 92 <nop,nop
,timestamp 813342 760077>
17:02:23.929396 IP scofield.local.ssh > montgomery.local.34145: . ack 41 win 91 <nop,nop,timestam
p 760077 813342>
17:02:23.929608 IP montgomery.local.34145 > scofield.local.ssh: P 41:833(792) ack 41 win 92 <nop,
nop,timestamp 813342 760077>
17:02:23.929613 IP scofield.local.ssh > montgomery.local.34145: . ack 833 win 116 <nop,nop,timest
amp 760077 813342>

NOTE: Notice the difference at the beginning between this tcpdump and the previous one

Point-to-Point Communication Established between a pair of Isolated Physical Hosts

sbanerj1 — Tue, 03 Jun 2008 19:20:32 CDT

First off, the physical hosts Scofield and Montgomery both had the openssh-server daemon installed on them.
Both machines were disconnected from the LAN, and a point-to-point physical connection was established between the two physical machines by means of an appropriate Ethernet cable.
Since both physical hosts had the avahi daemon running on them, there was no need of configuring the network manually, as both machines were able to auto-detect each other because of the avahi daemon installed on them.

The following excerpt shows the P2P communication that was established between scofield and montgomery:

reichsfuhrer@montgomery:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:72:74:f5:e6
inet6 addr: fe80::213:72ff:fe74:f5e6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:954428 errors:13 dropped:0 overruns:0 frame:0
TX packets:115798 errors:0 dropped:0 overruns:0 carrier:0
collisions:20996 txqueuelen:1000
RX bytes:342560170 (326.6 MB) TX bytes:9598802 (9.1 MB)
Interrupt:16

eth0:avahi Link encap:Ethernet HWaddr 00:13:72:74:f5:e6
inet addr:169.254.10.166 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:16

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2294 errors:0 dropped:0 overruns:0 frame:0
TX packets:2294 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:118572 (115.7 KB) TX bytes:118572 (115.7 KB)

vmnet8 Link encap:Ethernet HWaddr 00:50:56:c0:00:08
inet addr:192.168.53.1 Bcast:192.168.53.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:486 errors:0 dropped:0 overruns:0 frame:0
TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

reichsfuhrer@montgomery:~$ ssh 169.254.7.148

The authenticity of host '169.254.7.148 (169.254.7.148)' can't be established.
RSA key fingerprint is c5:e0:9f:dc:03:7f:49:d0:e9:e5:39:1a:b4:81:ee:7f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '169.254.7.148' (RSA) to the list of known hosts.
reichsfuhrer@169.254.7.148's password:
Linux scofield 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
Last login: Tue Jun 3 14:48:02 2008

reichsfuhrer@scofield:~$ echo logged into scofield from montgomery via openSSH-server
logged into scofield from montgomery via openSSH-server

reichsfuhrer@scofield:~$ traceroute 169.254.10.166
traceroute to 169.254.10.166 (169.254.10.166), 30 hops max, 40 byte packets
1 montgomery.local (169.254.10.166) 0.220 ms 0.196 ms 0.184 ms

reichsfuhrer@scofield:~$ traceroute scofield
traceroute to scofield (127.0.1.1), 30 hops max, 40 byte packets
1 scofield (127.0.1.1) 0.041 ms 0.012 ms 0.008 ms

reichsfuhrer@scofield:~$ logout
Connection to 169.254.7.148 closed.
The next logical step after this is to manually configure the networking in the physical hosts, and assign static IP addresses to them. After establishing communication between them, we can make the physical hosts act as routers (NOTE: the Multi-Threaded Routing toolkit has already been installed on the machines), and establish communication between the VMs that are running on Scofield & Montgomery, across the P2P connection.

For more information on Avahi, visit the Avahi Project.

... and some fresh medicated beats, angular blips and transcendental guitar noise.

sbanerj1 — Thu, 29 May 2008 04:18:13 CDT

Some videos to freak out to when enmeshed within the Matrix:

Keith Jarrett electric keyboard solo, possibly on a moderately good dose of LSD-25, playing with the Miles Davis' Bitches Brew... watch out for the afro.

Keith Carlock (drum solo) - got hooked onto this guy by chance. He distills the spirit of John Bonham through a jazz perspective, and grooves hard enough to charm a boa python (Ali this one's for you helping me installing Ubuntu).

and for a lil' more Sco' he's joined here by Medeski, Martin and Wood in a soulful and surreal interpretation of the Beatles' classic Julia - listen to Sco's guitar sound there...
and from the same show, the opening jam on Little Walter Rides Again, try stopping this monster groove!

and before I get carried away any further, here's John McLaughlin giving us a glimpse at divinity, solo on Mahavishnu's Meeting of the Spirits; accompanied here by Paco de Lucia and Larry Coryell as a part of the guitar trio.

VMware Workstation 6: Virtual Machines up and Running

sbanerj1 — Thu, 29 May 2008 02:09:36 CDT

Finally getting acquainted with the ins and outs of operating VMware Workstation 6. The user documentation from VMware has proved very helpful in getting a new user (like me) comfortable with operating the software. The only drawback experienced so far has been the fact that VMware is hungry on system resources and barely runs on a physical host with memory less than 1GB (as opposed to my 512 MB main memory laptop, where VMware Workstation ran extremely slowly).

Setting up the Virtual Machines (VM) was a breeze (albeit a time consuming process). In W308, two VMs were created on the physical host computer Scofield running VMware Workstation 6 on Ubuntu 8.04:

For purposes of experimental control, the first VM named Schutzstaffel was created using the Custom configuration, and the second VM Totenkopfverbände was created using the Typical configuration options.
Schtuzstaffel was configured to have 384 MB of main memory, and an 8 GB virtual hard disk, with the entire hard disk space created for the machine right from the start (VMware claims that this increases the overall performance of the VM).
Totenkopfverbände was configured starting with 512 MB of main memory and an 8GB virtual hard disk but the virtual disk space has not been allocated for the machine in its entirety, it will grow according to the machine's storage requirements (up until it reaches its maximum capacity of 8 GB).
Both machines were configured to work with NAT network configuration as opposed to Bridged networking or Host-only network configuration.
Both machines had Ubuntu 8.04 installed in them as the Guest Operating System as well as VMware Tools.
Within the NAT networking scheme, the VMs utilized a Virtual Network Adapter (which was supported by the prior installation of VMware Tools).

There after using the ping and traceroute programs, communication was established between the two local virtual machines Schutzstaffel and Totenkopfverbände. The following the output of the operations:

reichsfuhrer@Schutzstaffel:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:9b:87:1f
inet addr:192.168.241.128 Bcast:192.168.241.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe9b:871f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15083 errors:0 dropped:0 overruns:0 frame:0
TX packets:4925 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:22470778 (21.4 MB) TX bytes:276447 (269.9 KB)
Interrupt:16 Base address:0x2000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:702 errors:0 dropped:0 overruns:0 frame:0
TX packets:702 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:36124 (35.2 KB) TX bytes:36124 (35.2 KB)

reichsfuhrer@Schutzstaffel:~$ traceroute 192.168.241.129
traceroute to 192.168.241.129 (192.168.241.129), 30 hops max, 40 byte packets
1 totenkopfverbande.local (192.168.241.129) 7.222 ms 7.312 ms 7.281 ms
reichsfuhrer@Schutzstaffel:~$ ping 192.168.241.129
PING 192.168.241.129 (192.168.241.129) 56(84) bytes of data.
64 bytes from 192.168.241.129: icmp_seq=1 ttl=64 time=0.418 ms
64 bytes from 192.168.241.129: icmp_seq=2 ttl=64 time=0.423 ms
64 bytes from 192.168.241.129: icmp_seq=3 ttl=64 time=0.269 ms
64 bytes from 192.168.241.129: icmp_seq=4 ttl=64 time=0.305 ms
64 bytes from 192.168.241.129: icmp_seq=5 ttl=64 time=0.382 ms

[1]+ Stopped ping 192.168.241.129
reichsfuhrer@Schutzstaffel:~$

Ubuntu 8.04 Hardy Installation: Lessons Learned

sbanerj1 — Sat, 24 May 2008 15:55:13 CDT

Perhaps one of the most puzzling and frustrating issues that was encountered during the course of our work, was with installing the latest version of Ubuntu 8.04 "Hardy Heron". What was most troubling was determining the exact source of the problem, and contextualizing it within a logical framework.

The error occurred during installation of Ubuntu 8.04 LTS (desktop version) form the liveCD. After partitioning the hard drive to accommodate Ubuntu 8.04 and starting the installation, the installer would crash at different points during installation occasionally throwing out the error message "Errorno5: input/output error" - it would go on to say that it couldn't write files to a particular sector of the hard disk, and subsequently asks to see if the CD is dirty.

When the installer froze, looking at the command line interface screen which runs under the Gnome GUI interface (by pressing Alt+F8) that shows the scripts executing as the installer copies files to the system necessary for setting up Ubuntu; the error message "SQUASHFS error" and two other associated error messages would flood the screen (as if caught in an infinite loop of some sort).

This problem replicated itself each time we tried installing Ubuntu 8.04 on my laptop (which had Windows XP previously installed) or on some of Dell desktop computers (in the research lab) which also had ONLY Windows XP pre-installed on them. Unfortunately at this point I cannot make the generalization that this problem occurs only on systems which have Windows XP pre-installed on them, since one of the lab machines which did have only Windows XP pre-installed, ran the installation program off the liveCD perfectly without any hangups.

However, some of the other lab machines and my laptop weren't lucky, and no matter how many times we re-partitioned and tried installing Ubuntu 8.04, it would crash each time. Subsequently trying to install Ubuntu 7.10 "Gutsy Gibbon" also failed on those machines; with the exact same error messages!

At one point we conjectured, that the problem might be with the liveCD. This was concluded after reading (on the Ubuntu forums) on the how this problem has plagued the Ubuntu user community at large since 8.04 has been released. Alternatives were to burn the .iso image file at the slowest possible speed - this also failed (and has failed for other users too).

As of now there is no concrete clear-cut method to avoid this problem if it should occur. We have tried reasonging the numerous possibilities, and it could be anything from a bug within the installer that manifests because of certain discrepancies with how Windows XP deals with the hard drive, to overheating of the CD drive causing the installer to crash. There's no definite answer to the problem, and it continues to plague the community at large.

At one point I completely removed Windows XP from my system (using the partitioner within the liveCD in manual mode) and even then Ubuntu 8.04 and 7.10 failed to install. I was temporarily stuck for a day when my computer would start up, display the manufacturer logo and then display a blank screen saying "MBR (master boot record) error / Missing OS".

Finally the problem was resolved by installing Ubuntu 7.04 "Fesity Fawn" (which also failed twice with the same errors during installation!) and then upgrading online to Gutsy first, and then to Hardy (8.04).

As fair warning, be prepared to deal with these issues when installing Ubuntu 8.04, however, if you stick through it, it's totally worth it; the coolest and most hip OS around, Ubuntu 8.04 LTS is in da house!

PS: I would direct new users and old who are facing this problem to look it up in the Ubuntu Forums.

Progress Report as of 05/19/08

sbanerj1 — Mon, 19 May 2008 17:12:19 CDT

Installed Ubuntu 8.04 LTS on two machines (W308 and W309)
Updated bug patches and security fixes
Installed the following packages:

mc
nmap
build-essential
emacs22
tcptraceroute
traceroute

Installed VMware Player:

VMware didn't have a direct patch for the new version of Ubuntu; had to download the tar file from the VMware website and then installed the player manually usuing the Perl scripts in the /usr/bin directory.
Downloaded the most recent patches for VMware Player but haven't executed them since that would require configuring the VMWare Player.

NOTE: For tomorrow, we should start by configuring the VMware Player and creating the virtual machines. Also, I had some trouble using the "sudo apt-get" command and installing the Sun Java on either machines - that needs to be checked out tomorrow too.

Approaches to Virtualization and their Pros & Cons

sbanerj1 — Thu, 15 May 2008 14:34:58 CDT

This is primarily based off of the Gasper/Langevin/Armitage/Rideout publication titled March of the [Virtual] Machines. The paper explores two different methods of virtualization, and outlines their pros and cons with respect to issues such as cost, overhead, remote access, and scalability. The following addresses some of the main issues that paper focuses on, and as is relevant to our own research.

The authors first place their focus on the needs from a virtual system (within the context of their use within say a networking course), and use it as a basis for comparison between Virtual Machines and Virtual Operating Systems. The authors distinguish between the former style of hardware enabled virtualization (as is exhibited by Xen, VMware) and the latter virtualization which is provided for by theUser Mode Linux (UML) package.

In case of UML, instead of creating standalone virtual machines, UML creates aVirtual Operating System that runs on top of the the Linux kernel as another process!
This is better suited for educational purposes, and COW (Copy on Write) technology will allow the different "virtual machines" to boot of a shared disk image.

The authors remind us that students should be able to create/destroy/administer multiple VMs (within the specific context of networking and security experimentation). They outline two means of approaching this issue:

Using the VMware suite
Using theMy Linux Network(MLN) package combined with usage of UML:

This requires the input of a network description file, which specifies the UML system and switches, network addresses, system size, etc.
MLN uses this input file and feeds it to a script which then executes in order to create virtual networks.

Issues with Remotely Accessible Virtualization:

Requires students to carry around virtual hard disk images OR download gigs of image data from a centralized server [Does this mean that the centralized server is the physical host in this case?]
Must run the VM constantly on a physical host to let students use pre-assigned VMs [I'm a little unsure as to the relationship between virtual machines and physical hosts within the context of remote access.]
Limit number of connections to the Virtual Machine server [So does this mean that the virtualization is completely software based?]

NOTE: SOFTICE remotely accesses VMs by using open protocols (X11, ssh).

Scalable Virtual Hosting: This can be achieved by means of Networked Attached Storage (NAS) which addresses the issue of centralized data storage. However there's still the issue of overloading because of hosting multiple VMs on a single Linux server. This leads to a paradoxical problem as is outlined below,

A bigger server may be acquired to host multiple VMs for one course
This scheme leads to separate physical servers required for different courses incorporating virtualization technology.
However, when the course is not scheduled or the enrollment is low, the physical host server is underused or sits idle

This problem is paradoxical because it was to escape the limitations (financial, space, etc) of acquiring external extra hardware which called for the advent of virtualization technology.

Clustering allows for the solution to the above problem. By combining Blade Servers with NAS (this is an example of high end clustering), the VMs are abstracted further from the specifics of storage and computational resources. This is highly scalable because of the following reasons:

As computational demand increases, individualblades (disks) can be easily added to the server.
The system administrator's workload doesn't increase proportional to the addition of extra blades.

The authors implemented clustering by using the Warewulf Clustering Toolkit and the Linux server package (this is an example of low end clustering). The student obtains a static IP address when connecting to the main server which then connects to a virtual cluster which appears to the student as a single machine. As the workload increases, more nodes are added to the cluster to increase its computational power. This is what constitutes load-balancing.
[What is the exact nature of an individual node? Is the master server physical and the node cluster virtual?]

Virtual Appliance : It is a disk image that can be deployed [via external mean?] inside a network(ed) virtual machine to facilitate the dissemination of complex software tasks. The authors implemented this using a Linux based CentOS VMware virtual image. This allows for the virtual image to be deployed on any machine running the VMware server. The virtual image bridges the 2 network interfaces on the physical host - one to the hosting network, and the other to a private switch.

[SOFTICE virtual appliance will then provision with a cluster node image any PXE boot enables PC powered on while connected to the private switch]

Use of virtual appliances as above provides an inexpensive clustering solution to the issues of scalability. Installing and maintenance necessary to manage the master node is encapsulated within the virtual appliance - the system administrator only manages the virtual appliance and the image.

Select Publications on Virtualization

sbanerj1 — Sun, 27 Apr 2008 23:55:14 CDT

I was going through the list of authors of academic publications on virtualization that you e-mailed me earlier today - I found some online resources, and have decided to compile a list of publications for further study. Feel free to add to this list as appropriate.

These are three publications where the paper abstract really caught my eye; I intend to read them in detail as soon as possible.

Dana Internship '08 Summer Research Home

sbanerj1 — Sun, 27 Apr 2008 23:29:04 CDT

This could be a starting point for getting focused on the project at hand. I'm going to start posting relevant information regarding our goals and methods. For starters I'm going to outline the immediate ideas that I have regarding some of the experimental approaches that we could take. As I read through different academic papers, we can both as per our meetings and discussions, keep streamlining our goals until we have a working set of ideas to begin with; which are hopefully also going to be regarding hitherto unexplored issues.

PS: I also think it'd be a good idea if every once in a while, there were some inspirational clips of jazz musicians put up to have our project encompass higher spiritual goals.

Some suggestions for the nature of the experiments

sbanerj1 — Sun, 27 Apr 2008 23:24:56 CDT

Regarding the topology of a network of virtual machines:

We know that we can organize the VM's within different subnets and in combination with how the machines are connected to each other, we effectively control the topology of the network. Given this, one particular control factor could be, by actively changing the topology of the network and observing the flow of traffic. It'd be interesting to try and find if any particular kind of topology facilitates greater efficiency in packet traffic flows, i.e. would a certain kind of network topology make the forwarding of packets easier? One particular way of approaching this experiment might be to expose the network to a controlled flooding with Link State Packets.
From an algorithmic viewpoint, it might also be interesting to compare different methods of producing a Minimum Spanning Tree (by Dijkstra's, Prim's, etc.) and see how they react to an evolving network topology.

Looking at the working of TCP:

By controlling the exchange of packets and systematically introducing the phenomenon of packet loss; perhaps we can do a comparative analysis of Go-Back-N versus Selective Repeat. Would there be a difference? If so, can we extrapolate something about the nature of these protocols and their efficiency?
It would also be interesting to set up the VMs and have them interact in such a way so that we can perhaps come up with some new control variables or stricter bounds upon the estimation of Round Trip Times.

Security Issues: It would be interesting to have the VMs behave as routers and explore ways in which we can fool the routers into forwarding datagrams incorrectly or drop them; and subsequently how could such situations be rectified?
Routing Issues:If we have our VMs simulate routers, we can perhaps explore how datagrams are managed within the switching fabric of the router.