Proposed approach
and
issues:
The following list
summarizes the tasks to be done and reason for doing.
- A study needs be done on how many pages of the initial iteration are
that of the application and that of the OS. We could pre-deploy only
the OS part so this study would help to roughly estimate the amount of
savings.
To get an idea on common pages between
OS images, two VMs can be booted up and page-wise walkthrough should be
done to find differing pages. As an extension, an application can be
run on the VM and again the differing pages should be identified to get
much better idea..
- The structure of the xen OS image file needs to be studied
As already discussed, we can pre-deploy
only OS and not application pages. But even with OS, we cannot deploy
whole of the OS part because of the shared libraries. So we need to
probably exclude the shared libraries while pre-deploying. OS image
would also include current register contents and other vital
information. We would need a thorough understanding of the image file
to properly setup the VM at the receiving end.
- Linux memory management needs to be studied to learn how to traverse
the main memory and read list of loaded shared libraries in the memory.
(This needs to be done from within the Xen VMM)
- After the above discussed information are available the plan is to
pre-deploy (or even boot a VM at target node, rip the common parts of
OS image and store it to a file) OS parts. When actual migration is to
be done, the already available information (OS parts) and the newly
available application pages need to be weaved together to form an
active image file. When the transfer is complete, this image file
should be ready to be booted up.
- For sensitivity study, the benchmarks need to be instrumented with
interleaved sleeps and coordinated migrate commands during sleep to
make sure we observe a less overhead (working set) during the migration
command when the processes sleep.