*: Whenever a user reports a problem or a bug, there's a standard bunch of questions we have: what are your log files, configuration, condor_q -analze, etc.  The VDT has a nice script which automatically discovers a bunch of stuff about a system, and generates a report the user can mail in with their bug report.  We should do something similar for Condor, and ask the VDT people if we can integrate our script into their, or if we can share parts of their script.
 
 *: Remove code related to CVS and the defunct git repositories (CONDOR_EXT, CONDOR_TEST_LRG, CONDOR_TEST_CNFDTL) from Condor's NMI build scripts.
+
+*: Seamless network migration for virtual machines.{linebreak}
+_: If a virtual machine is using networking, and it gets checkpointed and migrated, networking can go disconnected. Likewise, allowing in-bound connections is a tricky problem with virtual machines. This is an early stage design proposal I have. It consists of two aspects, a homing daemon, and tap interfaces on execute hosts.{linebreak}
+-homing daemon basically is a condor job which runs as NAT. These condor jobs can execute only on select hosts (as set up by the pool admin), maybe marked by a specific attribute.(problem : what if the homing daemon is checkpointed and migrated ? oops!){linebreak}
+- on the execute host for virtual machines, the nic of the virtual machine should be connected to a tap interface on the host. The starter sets up a tunnel connecting this tap interface and the homing daemon.{linebreak}
+- when a virtual machine job is matched, the negotiator fires a homing daemon job (unless one's already running), and passes the configs to the starter / adds it in the classad.{linebreak}
+- load balancing can be done by starting more homing daemons when more vm jobs are encountered.{linebreak}
+- a dhcp server could also be run as a part of the homing daemon. MAC addresses could be made a part of the vmuniverse job. Thus if a vm job checkpoints and migrates, when it comes up again, it will get the same ip.{linebreak}
+- the homing daemon could just run as a switch. And vmuniverse jobs can specify a vlan. In this case, homing daemons can be used to achieve intranetworking for vm universe jobs.{linebreak}