That is...is there a mechanism provided to do this? As an afterthought, this also applies to non-global zones, although one can stick something in the oem-banner eeprom variable that is identically visible on all the zones, which is not the case on LDOMs. However, that's not a supported mechanism. Having something that was would be better. Ideal if the same mechanism (on what might or might not be a zone, LDOM, or virtualized instance running under for example Xvm (xen) or VirtualBox) could be used for a guest of any of those sorts to determine its current host for informational purposes only - and for no other purpose, if one wishes to leave migration of guests unaffected! If such a mechanism existed, I imagine that a null string response could be construed as running directly on hardware. If a situation were to exist where both LDOMs and zones within a guest LDOM were in effect (or some other hypothetical nested virtualization), it should only be report its parent. Come to think of it, this facility could even be applicable to dynamic domains, although less important there, since AFAIK there's no mechanism for moving them from one frame to another.
In a support situation, we may have monitoring software (perhaps BigBrother or Hobbit, or something more; but those are extensible and more or less open). Even if a monitored system is down, the monitoring history can still be seen. If a client could report where it was running, and had problems, that would simplify investigating whether the host was having problems, how to obtain console access (dynamic if guests get moved around), etc. If there were a standard mechanism that worked with multiple virtualization situations, it would also be helpful in that it could make it possible for the monitoring software to look up the details of providing remote console access. I really think this would help to make virtualization more manageable, particularly if it applied equally to all the different techniques. -- This message posted from opensolaris.org _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
