Mittwoch Nov 07, 2012

What's up with LDoms: Part 5 - A few Words about Consoles

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
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
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
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
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.

Mittwoch Mrz 31, 2010

Sun Presenter Console with OpenSolaris

The Sun Presenter Console for OpenOffice and StarOffice has been around for a while. However, you need dual-screen support to use it. That wasn't the case with my laptop (Radeon Mobility X1600 graphics) until lately. This changed with build 117 of OpenSolaris. I'd like to thank my collegue Andris Perkons for pointing this out to me :-)

To use this extension, here's what you need:
  • Sun Presenter Console
  • Xinerama Support fuer Xorg
    • Create a file using "Xorg -configure"
    • Copy this to /etc/X11/xorg.conf
    • In 'Section "Screen"', 'SubSection "Display"':
      and for all color depths, add "Virtual 3600 1200"
    • restart your Xserver

Now you can cycle through different modes of Xinerama using SHIFT-F5. For presenting, use the unmirrored dual-screen mode. It's important to note that OpenOffice currently can't cope with different resolutions on both screens. To avoid having to clean up my desktop after every resolution change, I use a dedicated presentation-account for this reason. Since I don't like the ambiguity of Shift-F5, I use two little scripts to turn the beamer on and off:

Beamer On:

screensaver-command -exit
xrandr -s 1024x768
xrandr --output VGA-0 --mode 1024x768 --right-of LVDS
res=`xrandr|grep \\\*|tail -1|awk '{print $1}'`
zenity --info --text="Beamer now on\\nResolution $res \\nScreensaver off"

Beamer off:

xrandr --output VGA-0 --off

This assumes a beamer resolution of 1024x768, which should be ok most of the time.

And now: Happy presenting!


Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« April 2014