*: Currently, the architecture of the submit machine is taken as the architecture of the required VM Universe jobs. However, if I create a 32 bit vm on a 64 bit machine, then, that VM can as well run on a 32 bit machine with vmware. Yet, the architecture requirement prevents such matches. This needs to be fixed.{linebreak}(vmathew)
*: I see a lot of D_ALWAYS used in the vm universe code. Evaluate and change these to something appropriate.. Maybe create a debugging mode for vm universe ?? (vmathew)
+
+*: support for mobility: {linebreak}
+this is an alternate idea for seamless network migration that I've written down above. Basically, how I deploy a new VM condor node to turn around, join the pool become a worker node is by using NAT and CCB. If the virtual machine is checkpointed and migrated, both the host machine IP address and the guest machine IP address (assigned by vmware with NAT) changes thereby changing the identity of the host. Likewise, it has also been observed that vmwarae assigns a different ip address for nat, when the DHCP lease expires for the guest. This too causes the identity of the machine to change from Condor's perspective. {linebreak} Hence, we need a mechanism by which host machines can be uniquely identified on Condor. Maybe, the CM generates a unique host identifier for each host and signs it cryptographically, thereby making a sufficiently persistent host identification for the purposes of VM migration. (vmathew)
