VIO device renaming by LDom Manager
By Eric S-Oracle on Aug 21, 2007
The LDom Manager allows you to specify a name for each VIO client & server instance you configure. Currently (i.e. in LDoms 1.0 and the upcoming 1.0.1 releases), this information is not stored as part of the machine description (MD) for the associated guest domain. Instead, the device name to instance mapping is stored in the LDom Manager's private constraints database, which is itself persisted as a simple XML file in the control domain's filesystem.
There are cases where the information in the constraints database doesn't match that of the running system, and in those cases, the LDom Manager, on startup, will apply a canonical name to any VIO device(s) for which no name mapping is available. The two main reasons this can happen are:
- Loss of the constraints database file (as a result of an OS upgrade, for example)
- Reverting the system to a configuration stored on the SP containing a different set of VIO devices than the currently running Config.
When the LDom Manager first starts, if it can't find a mapping for a given VIO device in its constraints database, it applies a canonical name using the following heuristics:
For VIO clients: <type><instance #>, where <type> is either "vnet" or "vdisk", and the instance # is incremented for each additional device of type <type> encountered
For VIO servers: <domain-name>-<type><instance #>, where type is "vds", "vsw", or "vcc"
The Ldom Manager's renaming of VIO devices never affects the actual binding of VIO devices to instances in the OS, nor the binding of VIO clients to servers; everything continues to operate normally. The impact is in how the LDom Manager references VIO devices for display and reconfiguration by the user.
There is, however, one more serious problem to note: if a VIO device is configured using a name that matches a potential canonical name, and the LDom Manager subsequently attempts to use that same canonical name on another VIO device, it'll cause the LDom Manager to abort on startup, and eventually enter maintenance mode. This failure can be identified by this message appearing in the LDom Manager's log file:
Assertion failed: 0L != clientp->published_name, file vio_classes.c, line 2471
To work around this, so the LDom Manager can start, its constraints database (stored in /var/opt/SUNWldm/ldom-db.xml) must be hand-edited to rename the offending VIO device to one that doesn't collide with the canonical name namespace. There is a bug open in our bug tracking system for this problem; it's CR #6571091.
We plan to address these issues in an upcoming release (after the 1.0.1 release), by eliminating the need for the LDom Manager to rename VIO devices altogether.