Event No Compression With Compression
(Cold) Resume 125 (0.2) 73 (4.3)
Warm Suspend 114 (5.1) 158 (1.4)
Cold Suspend 146 (19.6) 158 (0.9)
This table shows the average time, in seconds, of sus-
pend and resume operations under cold and warm
file cache conditions. All experiments were repeated
three times, and the observed standard deviations are
shown in parentheses.
Figure 3. Suspend/Resume Times in testvm
ern laptops.
We hypothesize that users perceive resume latency more
acutely than suspend latency because the suspend operation
may overlap other user activity. For example, the user can
depart the work site immediately after suspending a VM
and allow the operation to complete while travelling to the
airport. Of course, attempts to resume the machine from an-
other site will block until the suspend operation completes.
By introducing simple file compression, we are able to
take advantage of this asymmetry between user percep-
tion of suspend and resume times. We introduced addi-
tional steps in the suspend and resume scripts to compress
file chunks during copyout and to decompress them dur-
ing copyin. Compression was done using gzip with the
--fast command-line option, achieving an average com-
pression ratio of about 49%. The third column of Figure 3
reports the effect of compression on performance. Resume
time is reduced by nearly 40% to about 73 seconds, while
warm suspend time is increased by about 38% and cold sus-
pend time by 8%. Although the resume time of slightly over
a minute may be acceptable in many scenarios we believe
we can further reduce it as discussed in Section 4.
3.4 Shortcomings of Test System
While constructing our prototype, we observed three us-
ability shortcomings. All of these arise from minor limita-
tions in the current version of VMware Workstation. They
do not pose significant obstacles to ISR, nor are they diffi-
cult to eliminate.
The first shortcoming stems from an imperfect abstrac-
tion of the host platform. In our first set of trials, we had
configured both Client 1 and Client 2 (running on identical
hardware including the monitors) with the same X display
settings. However, we noticed that when the testvm was
suspended on Client 1, it would fail to resume on Client
2. The error message would indicate that the screen resolu-
tion on Client 2 did not match that of testvm at suspend.
The only difference between the two machines was that
Client 1 was connected to its monitor through a KVM (key-
board/video/mouse) switch, while Client 2 was connected
directly to its monitor. Removing the KVM eliminated the
problem. Since the problem arises only on suspend/resume
and not on power-down/power-up, we infer that display in-
formation is saved in testvm.vmss but not in the other
files.
The second shortcoming relates to file location. We no-
ticed that a machine suspended on Client 1 could not be re-
sumed in a different directory on Client 2. Again, we only
encountered this limitation when testvm was suspended, not
when it was powered-down. This leads us to believe that
testvm.vmss embeds absolute pathnames of the other
VM state files. Our workaround was to ensure that copyin
and copyout use identical directory names on the resume
and suspend machines.
The third shortcoming is an omission. To our knowl-
edge, the only way to suspend a running VM is through a
mouse click in its control window. A mechanism for remote
triggering of suspend would be valuable. For example, sup-
pose a user forgets to suspend his VM before leaving work.
On reaching home, he would like to be able to migrate that
VM. At present, the only option is to ask someone back at
work to manually click on the suspend button. A means of
accomplishing this remotely (for example, through a “sus-
pend and exit” signal) would be helpful. Of course, there are
important security issues that would have to be addressed in
implementing such a mechanism.
4 Improvements and Future Work
4.1 Improved Security
By the very nature of ISR, the VM state will often be
transferred over insecure channels. In such an environment,
properly protecting the contents of the VM state files is an
important consideration because volatile state may contain
highly sensitive information such as passwords in the clear.
To address this problem, we plan to encrypt data on copy-
out and decrypt it on copyin. This means that no VM state
is ever stored in the clear in the distributed file system. Ex-
plicit encryption/decryption allows the security of ISR to be
decoupled from that of the underlying distributed file sys-
tem.
Another important dimension to security is the need for
mutual validation of a user and the host system at resume
time. This is clearly a problem that must be addressed be-
fore large-scale deployment of ISR using anonymous hard-
ware is advisable. In this area, we hope to leverage the work
of others, such as the TCPA [18].
4
Proceedings of the Fourth IEEE Workshop on Mobile Computing Systems and Applications (WMCSA’02)
0-7695-1647-5/02 $17.00 © 2002 IEEE
Resume Templates 1210 Document(s)
