Mailing List Archive

On Wed, Jun 28, 2006 at 09:47:10PM +0100, Daniel P. Berrange wrote:

> Currently XenD/XenStore doesn't provide a real UUID for Domain-0 - its
> always fixed at 00000000-0000-0000-0000-000000000000. If the new API is
> to allow management of multiple hosts having all their Dom-0's with a
> null UUID is going to complicate things somewhat for users of the API.

Yes, that's a good point. The reason we did that initially was to ensure that
your domain 0 UUID didn't change across a reboot (there was a reason we needed
that, but I can't remember what it was right now).

I think that we could arrange for domain 0 to get a real but fixed UUID.

> Is it intended to expose the real UUID of the host being managed. Most
> machines I've encountered have a UUID embedded in the SMBIOS which would
> be the obvious thing to use for Domain-0
>
> $ lshal | grep smbios.system.uuid
> smbios.system.uuid = 'EF861801-45B9-11CB-88E3-AFBFE5370493' (string)

Well, the host itself needs a UUID too -- wouldn't the SMBIOS UUID be more
appropriate for the host, rather than domain 0?

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Thu, Jun 29, 2006 at 09:11:25PM +0100, Ewan Mellor wrote:
> On Wed, Jun 28, 2006 at 09:47:10PM +0100, Daniel P. Berrange wrote:
>
> > Currently XenD/XenStore doesn't provide a real UUID for Domain-0 - its
> > always fixed at 00000000-0000-0000-0000-000000000000. If the new API is
> > to allow management of multiple hosts having all their Dom-0's with a
> > null UUID is going to complicate things somewhat for users of the API.
>
> Yes, that's a good point. The reason we did that initially was to ensure that
> your domain 0 UUID didn't change across a reboot (there was a reason we needed
> that, but I can't remember what it was right now).
>
> I think that we could arrange for domain 0 to get a real but fixed UUID.
>
> > Is it intended to expose the real UUID of the host being managed. Most
> > machines I've encountered have a UUID embedded in the SMBIOS which would
> > be the obvious thing to use for Domain-0
> >
> > $ lshal | grep smbios.system.uuid
> > smbios.system.uuid = 'EF861801-45B9-11CB-88E3-AFBFE5370493' (string)
>
> Well, the host itself needs a UUID too -- wouldn't the SMBIOS UUID be more
> appropriate for the host, rather than domain 0?

Well if the fully virt guests are going to have their have UUID exposed
via SMBIOS, and bare metal OS already uses SMBIOS, then Domain-0 should
be consistent, hence SMBIOS too (yes I'm conveniently ignoring paravirt,
which has no SMBIOS at this time) Why would we need different UUID for
the host, vs Domain-0 OS ? My concern existing userspace tools requiring
a UUID for the host/OS currently use SMBIOS, so its desirable to have
then 'just work' in virtualized env without changes.

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Thu, Jun 29, 2006 at 09:32:19PM +0100, Daniel P. Berrange wrote:

> On Thu, Jun 29, 2006 at 09:11:25PM +0100, Ewan Mellor wrote:
> > On Wed, Jun 28, 2006 at 09:47:10PM +0100, Daniel P. Berrange wrote:
> >
> > > Currently XenD/XenStore doesn't provide a real UUID for Domain-0 - its
> > > always fixed at 00000000-0000-0000-0000-000000000000. If the new API is
> > > to allow management of multiple hosts having all their Dom-0's with a
> > > null UUID is going to complicate things somewhat for users of the API.
> >
> > Yes, that's a good point. The reason we did that initially was to ensure that
> > your domain 0 UUID didn't change across a reboot (there was a reason we needed
> > that, but I can't remember what it was right now).
> >
> > I think that we could arrange for domain 0 to get a real but fixed UUID.
> >
> > > Is it intended to expose the real UUID of the host being managed. Most
> > > machines I've encountered have a UUID embedded in the SMBIOS which would
> > > be the obvious thing to use for Domain-0
> > >
> > > $ lshal | grep smbios.system.uuid
> > > smbios.system.uuid = 'EF861801-45B9-11CB-88E3-AFBFE5370493' (string)
> >
> > Well, the host itself needs a UUID too -- wouldn't the SMBIOS UUID be more
> > appropriate for the host, rather than domain 0?
>
> Well if the fully virt guests are going to have their have UUID exposed
> via SMBIOS, and bare metal OS already uses SMBIOS, then Domain-0 should
> be consistent, hence SMBIOS too (yes I'm conveniently ignoring paravirt,
> which has no SMBIOS at this time) Why would we need different UUID for
> the host, vs Domain-0 OS ? My concern existing userspace tools requiring
> a UUID for the host/OS currently use SMBIOS, so its desirable to have
> then 'just work' in virtualized env without changes.

I think that the host and domain 0 are significantly different things, and
certainly should have different UUIDs. It would be ever so confusing if there
was an instance of Vm and an instance of Host with the same UUID.

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Thu, 2006-06-29 at 21:49 +0100, Ewan Mellor wrote:
> On Thu, Jun 29, 2006 at 09:32:19PM +0100, Daniel P. Berrange wrote:
>
> > On Thu, Jun 29, 2006 at 09:11:25PM +0100, Ewan Mellor wrote:
> > > On Wed, Jun 28, 2006 at 09:47:10PM +0100, Daniel P. Berrange wrote:
> > >
> > > > Currently XenD/XenStore doesn't provide a real UUID for Domain-0 - its
> > > > always fixed at 00000000-0000-0000-0000-000000000000. If the new API is
> > > > to allow management of multiple hosts having all their Dom-0's with a
> > > > null UUID is going to complicate things somewhat for users of the API.
> > >
> > > Yes, that's a good point. The reason we did that initially was to ensure that
> > > your domain 0 UUID didn't change across a reboot (there was a reason we needed
> > > that, but I can't remember what it was right now).
> > >
> > > I think that we could arrange for domain 0 to get a real but fixed UUID.
> > >
> > > > Is it intended to expose the real UUID of the host being managed. Most
> > > > machines I've encountered have a UUID embedded in the SMBIOS which would
> > > > be the obvious thing to use for Domain-0
> > > >
> > > > $ lshal | grep smbios.system.uuid
> > > > smbios.system.uuid = 'EF861801-45B9-11CB-88E3-AFBFE5370493' (string)
> > >
> > > Well, the host itself needs a UUID too -- wouldn't the SMBIOS UUID be more
> > > appropriate for the host, rather than domain 0?
> >
> > Well if the fully virt guests are going to have their have UUID exposed
> > via SMBIOS, and bare metal OS already uses SMBIOS, then Domain-0 should
> > be consistent, hence SMBIOS too (yes I'm conveniently ignoring paravirt,
> > which has no SMBIOS at this time) Why would we need different UUID for
> > the host, vs Domain-0 OS ? My concern existing userspace tools requiring
> > a UUID for the host/OS currently use SMBIOS, so its desirable to have
> > then 'just work' in virtualized env without changes.

My patches for HVM domU's are progressing again finally. Trying to send
out by tomorrow evening.

>
> I think that the host and domain 0 are significantly different things, and
> certainly should have different UUIDs. It would be ever so confusing if there
> was an instance of Vm and an instance of Host with the same UUID.

Hrm, this is interesting. Redundant control partitions would present a
real problem if the hardware UUID was used to identify each of them.

It's easy to generate UUID's -- storing a uuid for each control
partition in xenstore or a file would probably work fine, as long as
out-of-band tools can figure out which host maps to each control
partition's uuid. This is problematic without more agent-like code,
unless xend helps with the correlation.

Andrew

>
> Ewan.
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api


_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api