ian/keir, this is a proposal for save/restore image format with more information(version, host/gust info...). any comments? thanks, edwin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Zhai, Edwin wrote:> ian/keir, > > this is a proposal for save/restore image format with more > information(version, host/gust info...). > > any comments? > > thanks, > edwinThis 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel