RE: save/restore image format

RE: save/restore image format

[Dong, Eddie]

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

Re: save/restore image format

[John Levon]

On Tue, Sep 26, 2006 at 10:50:28PM +0800, Dong, Eddie wrote:

> > 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.

Certainly.

> 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.

I'm not sure I understand. Machine migration will happen over a secure
transport as part of the Xen API changes, or so the plan is. Local dom0
save files can surely be managed via permissions.

regards
john

Re: save/restore image format

[Anthony Liguori]

Dong, Eddie wrote:
> Another curious question for save/restore in my opnion is that should we
> encrypt the saved image or not?

The qcow v2 format has the ability to save memory images (actually, 
multiple snapshots).  Plus, qcow supports encryption.  May be something 
to consider.

Regards,

Anthony Liguori

>  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@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>   

RE: save/restore image format

[Nakajima, Jun]

Zhai, Edwin wrote:
> ian/keir,
> 
> this is a proposal for save/restore image format with more
> information(version, host/gust info...).
> 
> any comments?
> 
> thanks,
> edwin

This is just what we have today when we extended it to support HVM
guests. We would like to kick off discussion on what's the right one
(including ELF-based?) by sorting out the requirements and options. 

Jun
---
Intel Open Source Technology Center

save/restore image format

[Zhai, Edwin]

[-- Attachment #1: Type: text/plain, Size: 145 bytes --]

ian/keir,

this is a proposal for save/restore image format with more 
information(version, host/gust info...).

any comments?

thanks,
edwin




[-- Attachment #2: save_restore_img_format.pdf --]
[-- Type: application/pdf, Size: 112329 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: save/restore image format

[John Levon]

On Tue, Sep 26, 2006 at 11:17:57AM +0800, Zhai, Edwin wrote:

> ian/keir,
> 
> this is a proposal for save/restore image format with more 
> information(version, host/gust info...).

The extra information in the header seems /much/ improved. I'm not sure
why cpu freq is there? This is a dynamic value!

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.

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.

What I'd like to see is something very ELF-like: there's a simple
header, followed by a list of sections. For saved files and core files
they would have the section offset values filled in. For migration, we'd
have a special sentinel value (or a different image type) indicating
that the contents are streamed and the offsets are unknown.

So we'd have a section for guest config, a section for cpu-id and the
like, etc. You could represent, say, the number and size of entries in
the vcpu config section just like ELF does, in the section table, thus
the section would have just the vcpu context.

Your document doesn't have the p2m frame list section, or the
"extended-info" structure that's rather unceromoniously plonked in for
extended-cr3 guests. It also misses the unwritten pages array and the
shared info page. Unless you're suggesting that we have a completely
different format for HVM guests. I hope not!

Approaching this in an ELF-like manner naturally gets us a clear image
format that's easily extensible and understandable, and it'd be great if
we could do this now.

regards
john