| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] save/restore image format
As Edwin is on vacation now, so I will follow up :-)
John Levon wrote:
> On Tue, Sep 26, 2006 at 11:17:57AM +0800, Zhai, Edwin wrote:
>
> The extra information in the header seems /much/ improved. I'm not
> sure why cpu freq is there? This is a dynamic value!
The guest frequency across migration or save/restore should not be
changed though the host platform may have different frequency. This is
for Xen to identify time virtualization policy if we support migration
among different frequency platform.
>
> cpu id data must be in a separate 'section' since it likely doesn't
> make sense for other processor types, or at least, they'll have a
> different format.
Sure.
>
> I still believe we should use more or less the same format for core
> files too; in that respect we need a header field for the /type/ of
> image. This could also identify HVM images, etc.
>
Using ELF like format or not is defintely an arguable topics, but it is
not addressed in this doc yet. If we want to move to ELF, the whole
format will be changed both for para VM and HVM, but hopefully through
this discussion we can first identify the items we need to put in the
image file.
Another curious question for save/restore in my opnion is that should we
encrypt the saved image or not? Given an usage model where people share
physical computers, say an University Lab, but everybody own an virtual
machine that is saved on network but can be restore and executed at any
physical box. In this case, encryption to the image file is a must.
Even for live migration, probably encryption is a must in future. With
data file encrypted, probably the existing tools like objdump can no
longer work the save image file even we use ELF.
thx,eddie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home