RE: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues)

[Alex Williamson <alex.williamson@xxxxxx>]

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.

   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.

> >   BTW, why does my Madison processor system (that can obviously only
> >run PV domains) have so many error messages in xend.log and
> >xen-debug.log about not being able to get nvram data from the GFW?  Why
> >is manipulating nvram even being attempted on a PV guest?  Thanks,
> 
> [Zhang, Xing Z] 
> Could you attach me these logs?

[2007-06-13 22:58:55 2862] ERROR (__init__:1072) XendDomainInfo.destroy: 
xc.domain_destroy failed.
Traceback (most recent call last):
  File "//usr/lib/python/xen/xend/XendDomainInfo.py", line 1704, in 
destroyDomain
    xc.domain_destroy(self.domid)
Error: (1, 'Internal error', 'Cannot get nvram data from GFW!\n (3 = No such 
process)')

Thanks,

        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


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