Back again to look at a detail of LDom configuration that is often forgotten - the virtual console server.
Remember, LDoms are SPARC systems. As such, each guest will have it's own OBP running. And to connect to that OBP, the administrator will need a console connection. Since it's OBP, and not some x86 BIOS, this console will be very serial in nature ;-) It's really very much like in the good old days, where we had a terminal concentrator where all those serial cables ended up in. Just like with other components in LDoms, the virtualized solution looks very similar.
Every LDom guest requires exactly one console connection. Envision this similar to the RS-232 port on older SPARC systems. The LDom framework provides one or more console services that provide access to these connections. This would be the virtual equivalent of a network terminal server (NTS), where all those serial cables are plugged in. In the physical world, we'd have a list somewhere, that would tell us which TCP-Port of the NTS was connected to which server. "ldm list" does just that:
root@sun # ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active -n-cv- UART 16 7680M 0.4% 27d 8h 22m
jupiter bound ------ 5002 20 8G
mars active -n---- 5000 2 8G 0.5% 55d 14h 10m
venus active -n---- 5001 2 8G 0.5% 56d 40m
pluto inactive ------ 4 4G
The column marked "CONS" tells us, where to reach the console of each domain. In the case of the primary domain, this is actually a (more) physical connection - it's the console connection of the physical system, which is either reachable via the ILOM of that system, or directly via the serial console port on the chassis. All the other guests are reachable through the console service which we created during the inital setup of the system. Note that pluto does not have a port assigned. This is because pluto is not yet bound. (Binding can be viewed very much as the assembly of computer parts - CPU, Memory, disks, network adapters and a serial console cable are all put together when binding the domain.) Unless we set the port number explicitly, LDoms Manager will do this on a first come, first serve basis. For just a few domains, this is fine. For larger deployments, it might be a good idea to assign these port numbers manually using the "ldm set-vcons" command. However, there is even better magic associated with virtual consoles.
You can group several domains into one console group, reachable through one TCP port of the console service. This can be useful when several groups of administrators are to be given access to different domains, or for other grouping reasons. Here's an example:
root@sun # ldm set-vcons group=planets service=console jupiter
root@sun # ldm set-vcons group=planets service=console pluto
root@sun # ldm bind jupiter
root@sun # ldm bind pluto
root@sun # ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active -n-cv- UART 16 7680M 6.1% 27d 8h 24m
jupiter bound ------ 5002 200 8G
mars active -n---- 5000 2 8G 0.6% 55d 14h 12m
pluto bound ------ 5002 4 4G
venus active -n---- 5001 2 8G 0.5% 56d 42m
root@sun # telnet localhost 5002
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
sun-vnts-planets: h, l, c{id}, n{name}, q:l
DOMAIN ID DOMAIN NAME DOMAIN STATE
2 jupiter online
3 pluto online
sun-vnts-planets: h, l, c{id}, n{name}, q:npluto
Connecting to console "pluto" in group "planets" ....
Press ~? for control options ..
What I did here was add the two domains pluto and jupiter to a new console group called "planets" on the service "console" running in the primary domain. Simply using a group name will create such a group, if it doesn't already exist. By default, each domain has its own group, using the domain name as the group name. The group will be available on port 5002, chosen by LDoms Manager because I didn't specify it. If I connect to that console group, I will now first be prompted to choose the domain I want to connect to from a little menu.
Finally, here's an example how to assign port numbers explicitly:
root@sun # ldm set-vcons port=5044 group=pluto service=console pluto
root@sun # ldm bind pluto
root@sun # ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active -n-cv- UART 16 7680M 3.8% 27d 8h 54m
jupiter active -t---- 5002 200 8G 0.5% 30m
mars active -n---- 5000 2 8G 0.6% 55d 14h 43m
pluto bound ------ 5044 4 4G
venus active -n---- 5001 2 8G 0.4% 56d 1h 13m
With this, pluto would always be reachable on port 5044 in its own exclusive console group, no matter in which order other domains are bound.
Now, you might be wondering why we always have to mention the console service name, "console" in all the examples here. The simple answer is because there could be more than one such console service. For all "normal" use, a single console service is absolutely sufficient. But the system is flexible enough to allow more than that single one, should you need them. In fact, you could even configure such a console service on a domain other than the primary (or control domain), which would make that domain a real console server. I actually have a customer who does just that - they want to separate console access from the control domain functionality. But this is definately a rather sophisticated setup.
Something I don't want to go into in this post is access control. vntsd, which is the daemon providing all these console services, is fully RBAC-aware, and you can configure authorizations for individual users to connect to console groups or individual domain's consoles. If you can't wait until I get around to security, check out the man page of vntsd.
Further reading:
The Admin Guide is rather reserved on this subject. I do recommend to check out the Reference Manual.
The manpage for vntsd will discuss all the control sequences as well as the grouping and authorizations mentioned here.
