xen-ia64-devel
Re: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues)
On Thu, Jun 14, 2007 at 06:48:49AM -0600, Alex Williamson wrote:
> On Thu, 2007-06-14 at 13:04 +0800, Zhang, Xing Z wrote:
> > >
> > > What if you have multiple vbds exported to the domain? Exporting a
> > >CD is an obvious case where you'll have to parse the disk list to guess
> > >a unique path. What if you boot multiple guests from the same
> > >read-only, live image (like a knoppix copied to disk)? This seems more
> > >troublesome than naming the nvram file using the domain name. What
> > >collisions do you foresee with domain names? Seems like the ideal
> > >scenario would be to save the nvram on the EFI partition
> > >(/efi/xen/nvram). Maybe the libfsimage functionality used by pygrub
> > >would make this possible.
> > [Zhang, Xing Z]
> > Yes, image path makes things trouble. Thanks for your mention. The
> > collision only encountered when you use a same configure file to boot
> > different images(I am afraid people will do that in developing period).
> > EFI partition(/efi/xen/nvram)? I am not sure what you mean. Is it dom0's
> > partition?
>
> No, I was thinking we might store the nvram in the EFI partition of
> the HVM guest. pygrub already has some support for finding an
> elilo.conf in the guest EFI partition, parsing it and pulling out the
> kernel and initrd for PV guests. I'm wondering if a similar method
> could be used to read and write the NVRAM image into the guest's EFI
> partition.
Humm, this seems slightly over-kill for me.
A simpler approach would be to create a dedicated partition for the NVRAM
image.
> I'm not sure my read-only image scenario makes any sense, and this
> approach would suffer the same issue with one nvram store per EFI
> partition. I don't know if that's an unreasonable limitation or not.
> The thing I like about storing the nvram in the guest image is that it's
> self contained. The guest image could be copied to another system and
> the nvram would be there with it. I also don't know if libfsimage has
> support to create and later write /etc/xen/nvram file as it's typically
> only used to read out of the boot partition.
>
> I can see now why you wanted to store the nvram based on disk image
> path, it's a similar idea to storing the nvram in the guest EFI
> partition. If the nvram is stored in the dom0 fs, using domain name
> seems like the easiest approach, but I still like the idea of having the
> nvram stored in the guest image.
I don't really like the idea of saving NVRAM on the disk. Real machines
don't do that so why should we do that.
If you really want to save NVRAM, an EFI tool can do the work.
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-ia64-devel] New tree issues (domU restart and domVTi bootissues), (continued)
- RE: [Xen-ia64-devel] New tree issues (domU restart and domVTi bootissues), Alex Williamson
- RE: [Xen-ia64-devel] New tree issues (domU restart and domVTibootissues), Zhang, Xing Z
- RE: [Xen-ia64-devel] New tree issues (domU restart and domVTibootissues), Alex Williamson
- RE: [Xen-ia64-devel] New tree issues (domU restart anddomVTibootissues), Zhang, Xing Z
- RE: [Xen-ia64-devel] New tree issues (domU restart anddomVTibootissues), Alex Williamson
- RE: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues), Zhang, Xing Z
- RE: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues), Alex Williamson
- RE: [Xen-ia64-devel] New tree issues (domUrestartanddomVTibootissues), Zhang, Xing Z
- RE: [Xen-ia64-devel] New tree issues (domUrestartanddomVTibootissues), Alex Williamson
- RE: [Xen-ia64-devel] New tree issues(domUrestartanddomVTibootissues), Zhang, Xing Z
- Re: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues),
Tristan Gingold <=
- RE: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues), Zhang, Xing Z
- Re: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues), Tristan Gingold
|
|
|