En este articulo intento explicar, para los que son nuevos en esto, algunos conceptos y términos que he aprendido poco a poco, leyendo en los foros, y preguntando a los gurus de Android y Dext, y que espero puedan aclararos las cosas. No soy un experto en el tema. Expongo aqui cosas tal y como las entiendo, intentando poner referencias cuando las tengo. No soy responsable de lo que hagais con vuestro telefono.

Motorola Dext

Primero, antes de flashear, rootear y trastear con el telefono, algunos consejos:

• Flashear el telefono, instalar Roms y demas conlleva un riesgo de cargarse el teléfono.
  Por info, en ese caso, tu teléfono se convierte en lo que llaman en ingles un “brick” (ladrillo). Es algo que ninguno esperamos que nos pase jamas.
• Para evitar briquear su teléfono, recomiendo leer, leer mucho los foros, preguntar siempre que tienes duda, pues la gente siempre intenta ayudar.
• Antes de seguir un tutorial en un foro: leer todos los comentarios que pone la gente (pueden ser muchas paginas) y una vez convencido, seguir cuidadosamente las instrucciones que pone el autor.

Hacer backup:

• Backup de aplicaciones, datos y configuraciones (APN,…): Recomiendo instalar desde el Market la aplicacion Titanium Backup (free) . Si hacemos un wipe, nos permitira restaurar todo despues.
• Una vez hayamos instalado una custom recovery (ver mas adelante), hacer un backup “nandroid”: es un backup de todas las particiones (ver mas adelante) del telefono.

Particiones del telefono:

El telefono tiene varias particiones (hablo del telefono, no la SD que es otra cosa).

C:\> adb shell cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00300000 00020000 "boot"
mtd1: 08ac0000 00020000 "system"
mtd2: 0df80000 00020000 "userdata"
mtd3: 00040000 00020000 "misc"
mtd4: 00500000 00020000 "recovery"
mtd5: 06000000 00020000 "cache"
mtd6: 00080000 00020000 "splash"

• boot: el kernel, del que bota en modo normal
• system: el sistema operativo Android (y aplicaciones de sistema) que se monta (en solo lectura) en modo normal
• userdata: se monta (en lectura/escritura) en modo normal, van ahi las configuraciones de las aplicaciones y los datos nuestros
• recovery: es el mini-sistema que se bota cuando arrancas en modo recovery (power+camara).

El telefono tambien tiene un bootloader (SPL) y una radio.

Modos de arranque del Dext:

Se puede arrancar el Dext de varias maneras, segun lo que necesitemos:

• Modo normal: al arrancar el telefono pulsando el boton power
• Modo recovery: pulsando el boton power + camara, despues cuando aparezca la opcion, plusar volumen down
• Modo usb bootloader int: pulsando el boton power + menu (tecla de los 4 cuadritos), para flashear desde RSD Lite.

Requisitos para conectarse al telefono:

Drivers de Motorola, RSD Lite y ADB, todo instalado y  funcionando. Esta guia en M3 tiene links y explica la instalacion de los programas. Leerla bien y seguirla atentamente.

SHX y Custom Recovery:

Los SHX son ficheros que se flashean en el telefono con el programa RSD Lite de Motorola desde el PC. Por ahi se pueden encontrar archivos SHX (grandes, >100-150 MB) que incluyen en general una Custom Recovery y tambien te flashean un sistema entero (algunos incluyen incluso la radio, bootloader,… los llaman firmwares). No recomiendo flashear estos, al menos al principio.

Tambien existen SHX mas pequeños (8-15MB) que solo incluyen una custom recovery. En mi opinion es mejor inicialmente flashear una custom recovery solo. Es lo que hice yo: flashee la Amon_RA 1.5.2 (descargar aqui Boot + Amon_RA Recovery SHX) que esta en el tutorial de TheDudes en M3 (aqui viene mas info de las opciones que tiene esta recovery).

Una vez flasheada con RSD Lite, sigues con tu telefono funcionando igual, porque no se ha tocado ni el sistema (system) ni tus datos/app (data). Solo la recovery.

Para quien este un poco familiarizado con el mundo linux/unix, la recovery del telefono es algo como un segundo sistema mas pequeño (que permite hacer tareas de mantenimiento sobre las demas particiones. Botar de recovery seria un poco como botar de un liceCD en un PC.

Como ejemplo de cosas que se pueden hacer desde una custom recovery (tambien depende de la recovery que flasheemos, claro):

• hacer un backup full del telefono (todas las particiones, con nandroid),
• restaurar un backup (no he probado),
• aplicar un update.zip (otra ROM) sobre system,
• hacer un wipe de la data y/o de la cache…

Custom Recovery Amon_RA

La stock Recovery de Motorola (stock = que viene por defecto), no se si permite hacer muchas cosas. Al arrancar con ella sale un icono de un triangulo de atencion y no hay mas opcion en la pantalla. Sin embargo, por ahi encontre algunas opciones:

• alt-w: wipe (restore factory settings)
• alt-l: verbose boot? (no estoy muy seguro)
• alt-s: instalar el fichero update.zip en la raiz de la SDcard (pero no se si cualquier update.zip vale o solo los que esten firmados por Motorola)

Con la custom recovery flasheada en el telefono, ya podriamos rootearlo sin instalar ninguna rom de otro operador (es decir que seguimos con nuestra Rom original, solo que le añadimos el root). Bastaria con botar en modo recovery, hacer un adb remount (para remontar el /system en read-write) y hacer un push del binario su e instalar Superuser.apk (lo que hace el bat en este zip).

adb push bin/su /system/bin
adb shell chmod 4755 /system/bin/su
adb uninstall koushikdutta.superuser
adb install bin/Superuser.apk

De hecho, si no alteramos el system (stock), tras botar de nuevo el telefono en modo normal, y rebotarlo de nuevo se flasheara de nuevo la stock recovery (al apagarse, el sistema original incluye en la particion /system la imagen de la recovery stock y la aplica antes de apagarse). Es bastante interesante! Si nos interesa guardar la custom recovery que hemos instalado (y que no se borre en el siguiente reinicio), podemos mover la /system/recovery.img a /system/recovery.img.stock, asi si queremos restaurarla podremos hacerlo mas tarde (devolviendole su nombre original).

Roms y update.zip:

Ademas de los SHX ,existen ficheros update.zip que son ROMs que se flashean desde una custom recovery. Mas tarde pondre un pequeño articulo sobre las Roms que existen ahora para el Dext. Hay que copiar el .zip en la raiz de la tarjeta SD, botar en modo recovery, seleccionar el zip y despues apply update.zip. Eso (segun el update.zip) formatea system, cache y descomprime el zip y copia cada fichero donde toca. El update.zip no toca la recovery (que yo sepa).

Metodo TheDudes:

Yo segui el metodo de TheDudes: el tutorial asusta al principio porque son muchos pasos (y mas de 50 paginas de comentarios), pero en realidad es muy sencillo (pero hay que seguirlo bien, si acaso leerlo 2 o 3 veces!). Resumiendo (no pongo aqui todos los pasos):

• Flashee la custom recovery Amon_RA 1.5.2 (flasheando el SHX correspondiente con RSD Lite por USB),
• Hice un backup Nandroid,
• Luego instale la ROM rooteada de “The Dudes CliqCake v0.4.1. T-Mobile US, Blur Version 1.1.31″, aplicando el update.zip correspondiente, copiado en la SD, directamente desde la custom recovery.

Respecto a las configuraciones y aplicaciones, en mi caso no perdi nada! Al botar pude ver que se habia mantenido el fondo de pantalla, mis aplicaciones instaladas, incluso los accesos directos en el escritorio. por supuesto tambien las configuraciones de cada aplicacion y mis datos, tampoco se perdieron. Asi que bien (en realidad es asi porque en el procedimiento no se hace “wipe” del telefono, lo dice al principio “This should not wipe your phone.”. En su momento no lo entendi, pero ahora se que eso significa que no pierdes tus datos/config.

Lo que si cambia o se pierde (pero no es grave):

• tonos, creo que ya no esta el tono de movistar
• algunas aplicaciones de sistema (ya no esta mstore (de movistar), shazam). En mi caso Shazam me gusta, así que la reinstale del market
• las imágenes del boot customizado, tendras las de t-mobile (y no el M (moco) de movistar) ;-), o bien un custom boot hecho por el modder.

Casi todo eso se puede volver atras en realidad, siendo root ya puedes volver a colocar las aplicaciones/tono/bootscreen originales… pero no entro en eso ahora.

¿Que aportan las Roms rooteadas?

Una cosa interesante de flashear esas Roms rooteadas, ademas de tener el root, es que, en españa, Movistar ha dejado la version de Motoblur 1.1.7 (algunos vienen incluso con la 1.1.5!), mientras que Motorola subio a la version 1.1.31 en USA (T-Mobile). Tambien salio una version 1.3.18 hace poco, que incluye una nueva radio y nuevo bootloader (ojo con esta version).

La version 1.1.31 añade mejoras:

• Update to Motoblur version 1.1.31, with some particularly interesting improvement in battery management amongst other things.
• Creo que tambien habilita el bloqueo de telefono por codigo grafico (al menos no conseguia habilitarlo con la rom de Movistar)
• En la galeria de photos, se puede pasar de una a otra pasando el dedo (touch-slidding), creo que con la Rom de Movistar no se podia.

Por info, abrí yo un thread en el foro de soporte de motorola sobre el tema de la actualizacion de 1.1.7 a 1.1.31 en España.

Las versiones basadas en 1.3.18 aportan de nuevo mejoras en el ahorro de bateria (si que se nota, la bateria aguanta mucho mas!)

Miedos y dudas:

• Un miedo que tenia era que al flashear con una rom de T-mobile el Dext quedara “lockeado” para T-Mobile y no funcionara con Movistar; no es asi, el telefono sigue funcionando bien con Movistar (y también sigue lockeado con Movistar)

• Otro miedo era el tema del 3G (tarifa de datos): en mi caso no perdi ni siquiera la configuracion del APN, tras instalar la nueva ROM seguia el telefono configurado con el APN de movistar y sigue funcionando bien el 3G. De todas formas habia hecho un backup con “APN Backup & Restore” (esta en el Market). OJO, con las Rom 1.3.xx y la nueva radio no funciona el 3G en Mexico y Brasil.

Pues nada, espero haber contestado a vuestras preguntas. Cualquier duda me decis. Si os interesa seguirme, estoy en twitter, @adumont. Podeis consultar tambien esta pagina donde he colgado links y demas informacion de interes sobre el Dext. Empeze a escribir este articulo hace tiempo, asi que ahora ya he instalado otra Rom, la Handler 1.3.1 de HandlerExploit.

ShareThis / Compartelo

• Versión del sistema: En un Dext esto nos dice la versión de Motoblur, en el mio tengo: Blur_Version.1.3.18.MB200.T-Mobile.en.US
• Version del firmware: en el mio aparece Handler 1.3.1-quickpatch, es la Rom que tengo instalada
• Version de banda base: es la versión de Radio que tiene tu teléfono.
  El mio tiene la 76XXC-63805025-SDCBALUM, que viene con la actualización 1.3.xx.
  La radio original del Dext/Cliq es la 76XXC-63805012-SDCBALUM (Motoblur 1.1.xx).

Se llega a esta pantalla desplegando el menu de aplicaciones, y luego:

1. Config.
2. Acerca del teléfono

Update 2010-03-09: Tambien se puede ver la version de la radio con:

C:\>adb shell
#  getprop gsm.version.baseband
76XXC-63805025-SDCBALUM
# getprop | busybox grep build
[ro.build.id]: [CUPCAKE]
[ro.build.display.id]: [CUPCAKE.1.3.18]
[ro.build.version.incremental]: [1.3.18]
[ro.build.version.sdk]: [3]
[ro.build.version.release]: [Handler 1.3.1-quickpatch]
[ro.build.date]: [Fri Feb  5 16:14:59 CST 2010]
[ro.build.date.utc]: [1265408099]
[ro.build.type]: [user]
[ro.build.user]: [build01]
[ro.build.host]: [il93lnxebld13]
[ro.build.tags]: [ota-rel-keys,release-keys]
[ro.build.product]: [morrison]
[ro.build.description]: [morrison-user 1.5 CUPCAKE 1.3.18 ota-rel-keys,release-keys]
[ro.build.fingerprint]: [blur/morrison/morrison/morrison:1.5/CUPCAKE/091111:user/ota-rel-keys,release-keys]
[ro.build.version.full]: [Blur_Version.1.3.18.MB200.T-Mobile.en.US]
[ro.build.config.version]: [GAS_NA_MORRISONTMB01NA_P036]
[ro.build.config.date]: [Fri Feb 05 15:57:39 -0600 2010]

ShareThis / Compartelo

Por defecto, cuando el teléfono se pone en modo suspensión (standby), el wifi se corta, y entonces vuelve a tirar del 3G.

Con esta opción puedes hacer que si estas conectado a una red Wifi, no se corte aunque la pantalla se apague.

Para llegar al menú de opciones avanzadas, hay que seguir estos pasos:

1. Ajustes
2. Conex. Inalámbricas
3. Configuración de Wi-Fi
4. Pulsar la tecla [Menú]
5. Avanzado
6. Política de suspensión de Wi-Fi

Ahí aparecerán 3 opciones:

• Cuando la pantalla se apague (pode defecto)
• Nunca si está conectado
• Nunca

ShareThis / Compartelo

Bit.ly API key

A popular site to generate short URLs suitable for Twitter is Bit.ly. Once you register for a free account, you get an API key that you’ll be able to use to call bit.ly from another application.

In my case I create a Zoho Creator Deluge Script function to generate a shot URL from any given URL passed as an argument. The code is pretty easy, and self explanatory:

• First set two variables, with my API key and bit.ly user name,
• Then submit the encoded URL to get shorten
• Then, using some XPATH magic, we extract the short URL from the response!

string shortenURL(string URL)
{
   Bitly_API_Key = "R_HereGoesYourAPIkey";
   Bitly_Login = "MyLogin";
   Bitly_Resp = getUrl("http://api.bit.ly/shorten?version=2.0.1&longUrl=" + encodeUrl(input.URL) + "&login=" + Bitly_Login + "&apiKey=" + Bitly_API_Key + "&format=xml");
   shortURL = Bitly_Resp.executeXPath("/bitly/results/nodeKeyVal/shortUrl/text()");
   return shortURL;
}

ShareThis / Compartelo

Escribi esta chuleta hace casi 2 años cuando monte un cluster SC3.2 con resource group Oracle corriendo en 2 zonas no-globales, para un entorno productivo en una Telco. Lo publico esperando que resulte interesante. No entra demasiado en los detalles tecnicos, sino que es mas conceptual.

Ejemplo: 2 proyectos cada uno con su cluster, sin consolidar:

• Proyecto A, 2 maquinas, pa01 y pa02, con Sun Cluster, con un grupo de recursos A-rg :

       +-------+ pa01     +-------+ pa02
       | A-rg  |          |   .   |
       +-------+          +-------+

• Proyecto B, 2 maquinas, pb01 y pb02, con Sun Cluster, con dos grupos de recursos B1-rg y B2-rg:

       +-------+ pb01     +-------+ pb02
       | B1-rg |          |   .   |
       |   .   |          | B2-rg |
       +-------+          +-------+

Consolidamos asi:

• 2 maquinas fisicas, m1 y m2, con Sun Cluster,
  • pa01 y pb01: zonas no globales de m1
  • pa02 y pb02: zonas no globales de m2

           m1                     m2
   +------------------+   +------------------+
   |                  |   |                  |
   |   +-------+ pa01 |   |   +-------+ pa02 |
   |   | A-rg  |      |   |   |   .   |      |
   |   +-------+      |   |   +-------+      |
   |                  |   |                  |
   |   +-------+ pb01 |   |   +-------+ pb02 |
   |   | B1-rg |      |   |   |   .   |      |
   |   |   .   |      |   |   | B2-rg |      |
   |   +-------+      |   |   +-------+      |
   |                  |   |                  |
   |Solaris 10 - SC3.2|   |Solaris 10 - SC3.2|
   +------------------+   +------------------+

Podemos aplicar management de recurso a las zonas –> containers.

Para montar esto, primero hay que montar las 2 maquinas, como si fueran a ser un cluster de 2 maquinas normales, instalar SC3.2.

Despues creamos las zonas.

Hay que entender que no se trata de 2 clusters de 2 nodos, sino de un cluster de 2 nodos, con 4 zonas.

A la hora de crear los usuarios, fs y demas, crearlos en las zonas, no en las maquinas fisicas.

Para el montaje de los FS locales de cada zona (/var, /opt/oracle,…) , ver Zones/fs.txt.

A la hora de crear los RGs, con clsetup, añadiremos las zonas donde corran, no los nodos, es decir:

   A-rg : NodeList = m1:pa01, m2:pa02

   B1-rg: NodeList = m1:pb01, m2:pb02
   B2-rg: NodeList = m2:pb02, m1:pb01

Los FS de los RGs se deben de montar en la zona global, en un path que no sea bajo el zonepath de ninguna zona.

Por ejemplo:

El A-rg necesita los FS:

   /A/scripts
   /A/BD/C1
   /A/BD/C2
   /A/BD/C3
   /A/BD/a00
   /A/BD/i00
   /A/BD/r00
   /A/BD/s00
   /A/BD/s01
   /A/BD/s02
   /A/BD/t00

Hay que poner los FS de los RGs en el /etc/vfstab de los dos nodos m1 y m2 (en la zona global), ya que SC3.2 los montara primero en la zona global antes que en la zona no-global.

Por ejemplo:

   m1:/etc/vfstab
   ...
   # A-rg
   /dev/vx/dsk/A-dg/lvscripts /dev/vx/rdsk/A-dg/lvscripts /A/scripts vxfs 2 no log
   /dev/vx/dsk/A-dg/lvbdc1    /dev/vx/rdsk/A-dg/lvbdc1    /A/BD/C1   vxfs 2 no log
   /dev/vx/dsk/A-dg/lvbdc2    /dev/vx/rdsk/A-dg/lvbdc2    /A/BD/C2   vxfs 2 no log
   ...

En las zonas donde vaya a correr el RG en cuestion, se deben de crear unicamente los correspondientes puntos de montage:

   /A/scripts
   /A/BD/C1
   /A/BD/C2
   /A/BD/C3
   /A/BD/a00
   ...

En particular, no es necesario poner nada en el vfstab de las zonas no globales.

ShareThis / Compartelo

• Handling multiple VMs

The idea was the svc be able to handle multiple VM, one my svc instance:

vbox:vm1 –> svc for starting/stopping vm1,

vbox:vm2 –> svc for starting/stopping vm2,

An interested reader, Leo, gave the svc a try and felt into some problem when trying it with multiple VM: Only the svc instance of the VM that started first would stay running, while the other instances started after it would fall into maintenance. In the svc log file appeared:

[ Jul 23 03:38:39 Method "start" exited with status 0. ]
[ Jul 23 03:38:39 Stopping because all processes in service exited. ]
[ Jul 23 03:38:39 Executing stop method ("/export/vm/svc/method/vbox stop"). ]

The stangest thing is that although the svc instances were in maintenance mode, the corresponding VMs were actually running fine.

Here is an example, with 2 vbox instances: both vm1 and vm2 are running fine, but:

leo@os:~$ svcs -pv vbox
STATE          NSTATE        STIME    CTID   FMRI
online         -             13:51:42     99 svc:/site/xvm/vbox:vm1
               13:51:41      710 VBoxXPCOMIPCD
               13:51:41      713 VBoxSVC
               13:51:42      715 VBoxHeadless
               13:51:47      727 VBoxHeadless
maintenance    -             13:51:48      - svc:/site/xvm/vbox:vm2

So svc vbox:vm1 is online, while vbox:vm2 felt into maintenance. Notice that vbox:vm1 has 2 VBoxHeadless processes in its contract, while vbox:vm2 has no processes!

Actually, doing some tests together, we get to the point that the problem was with how Virtualbox works:

Upon starting the vbox:vm2 svc instance (at 13:51:47), there is already a VM running (vm1 started at 13:51:42). When the svc starts, VBoxManage startvm is actually “talking” to an already running Virtualbox process (either VBoxXPCOMIPCD or VBoxXVC, I suspect the first one, COMIPCD = Communication IPC Deamon?) and telling him to start the second VM. This “already running VB process” is the one that will fork (inside the contract of vbox:vm1, in this case ctid 99) and launch the VM, while the VBoxManage started by second svc will end. In this case, the VM is running from outside the contract of the svc, and when both the method (vbox) and the svcs itself return, the contract has no processes and then SMF detects the “failure” and try to restart it.

To help understand this, remember that the first version of my manifest was defining a contract model service, which means (see man page of svc.startd(1m)):

     A contract model service fails if any of the following  con-
     ditions occur:

         o    all processes in the service exit

         o    any processes in the service produce a core dump

         o    a process outside the service sends a service  pro-
              cess  a fatal signal (for example, an administrator
              terminates a service process with  the  pkill  com-
              mand)

The solution to the problem is changing the “startd/duration” property from “contract” (the default) to “transient”, as explain in the man page of svc.startd(1m):

     Additionally, svc.startd managed  services  can  define  the
     optional  properties  listed  below  in  the startd property
     group.

     startd/duration

         The duration property defines the  service's  model.  It
         can  be  set  to  transient,  child also known as "wait"
         model services, or contract (the default).
[...]
     Defining a service as transient means that  svc.startd  does
     not  track  processes  for that service. Thus, the potential
     faults  described  for  contract  model  services  are   not
     considered failures for transient services. A transient ser-
     vice only enters the maintenance state if one of the  method
     failure conditions occurs.

This is done by adding the following lines to the manifest, inside the <service> section and importing it again using svccfg(1M):

   <property_group name='startd' type='framework'>
      <propval name='duration' type='astring' value='transient' />
   </property_group>

Though many services are using the transient model, I confess that I was quite exited by the way SMF was able to handle process failures and restart the svc using the contract model, and having to change to the transient model is rather disappointing. However it’s a restriction due to how Virtualbox creates its own processes.

• Service dependencies

Following the advice by Renaud Manus in this smf-discuss thread, I’ve added a dependency on milestone/multi-user-server,

• Property value checking

Following another advice by Renaud Manus in the same smf-discuss thread, I’ve implemented some validity checking on the value of the “vm/stop_method” property. I do it inside the method, because I’m not (yet) familiar with the use of the Value Constraints from the new Template Extensions feature.

• VM State checking

I’ve also implemented some checking on the state of the VM, so I only start it if it’s not already started, or stop it only if it’s running. It’s probably not the most exaustive checks that can be done, but it helps.

DOWNLOAD here the new versions of both files and feel free to use them under the MIT Licence:

• The Virtualbox SVC manifest for one instance (here named debian). Download, copy and edit one manifest per instance (VM)  as explained in this previous post.
• The Virtualbox SVC method (vbox).

If you are not confortable with modifying the files, please read first to my previous post to know what to modify.

Thanks go to: reader Leo and Renaud Manus from smf-discuss list at Opensolaris.org for there help, time and interest.

Updated: MIT Licence.

ShareThis / Compartelo

To create a new SMF Service you need two things:

• a service manifest: it’s a XML file which describes the service, and how SMF has to handle it: its dependencies (if any), its start and stop methods, its properties (if any), its working context (working directory, user…)
• the method(s) file(s) script(s): that is the actual start/stop/refresh scripts (shell scripts for example).

Let’s fist start with the definition of the service, that is the SMF manifest file:

• I name the service “site/xvm/vbox”:

<service
name='site/xvm/vbox'
type='service'
version='1.1'>

• I define two dependencies (I could set more of course):
  • Network working (svc:/milestone/network:default)
  • Filesystem mounted (svc:/system/filesystem/local:default)

<dependency name='network' grouping='require_all' restart_on='none' type='service'>
   <service_fmri value='svc:/milestone/network:default' />
</dependency>

<dependency name='filesystem-local' grouping='require_all' restart_on='none' type='service'>
   <service_fmri value='svc:/system/filesystem/local:default' />
</dependency>

• the declaration of the methods:

<exec_method
   type='method'
   name='start'
   exec='/export/home/adumont/svc/method/vbox start'
   timeout_seconds='60'
/>

<exec_method
   type='method'
   name='stop'
   exec='/export/home/adumont/svc/method/vbox stop'
timeout_seconds='60'
/>

You will probably need to change the path to the method from /export/home/adumont/svc to whatever path suit your instalation the most. Don’t forget to change it in the manifest, so the exec_method point to the an existing method script.

• the definition of a service instance (in my case I create a service instance for every VM I want to handle with this service):

<instance name='debian' enabled='false'>
... 
</instance>

• within the instance definition I define the working context:
  • working directory
  • processes credentials

   <method_context working_directory='/export/home/adumont/svc/var'>
      <method_credential user='adumont' group='staff' />
   </method_context>

• and the instance properties: I set an instance property called vm/stop_method, which I’ll use from the stop method to know I the method should stop the VM (see later in this post):

   <property_group  name='vm' type='application'>
      <!-- stop_method is used to set how SMF will stop the VM:
      Possible values are: acpipowerbutton, savestate, acpisleepbutton, poweroff -->
      <propval name='stop_method' type='astring' value='savestate' />
   </property_group>

Here is the full xml manifest file (/export/home/adumont/svc/manifest/vbox-debian.xml):

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='vbox'>

<service
name='site/xvm/vbox'
type='service'
version='1.1'>

<!--   Wait for network interfaces to be initialized. -->
<dependency
name='network'
grouping='require_all'
restart_on='none'
type='service'>

<service_fmri value='svc:/milestone/network:default' />

</dependency>

<!--    Wait for all local filesystems to be mounted.    -->
<dependency
name='filesystem-local'
grouping='require_all'
restart_on='none'
type='service'>

<service_fmri value='svc:/system/filesystem/local:default' />

</dependency>

<exec_method
type='method'
name='start'
exec='/export/home/adumont/svc/method/vbox start'
timeout_seconds='60'
/>

<exec_method
type='method'
name='stop'
exec='/export/home/adumont/svc/method/vbox stop'
timeout_seconds='60'
/>

<instance name='debian' enabled='false'>

   <method_context working_directory='/export/home/adumont/svc/var'>
   <method_credential user='adumont' group='staff' />
   </method_context>

   <property_group  name='vm' type='application'>
   <!-- stop_method is used to set how SMF will stop the VM:
   Possible values are: acpipowerbutton, savestate, acpisleepbutton, poweroff -->
      <propval name='stop_method' type='astring' value='savestate' />
   </property_group>

</instance>

<stability value='Evolving' />

<template>
<common_name>
<loctext xml:lang='C'>Sun xVM Virtualbox</loctext>
</common_name>
<documentation>
<manpage title='Sun xVM Virtualbox' section='1' />
</documentation>
</template>

</service>

</service_bundle>

Now let’s see the method (/export/home/adumont/svc/method/vbox). The method defined in the manifest will be invoked upon service start and stop events (and also refresh, although I haven’t set any, so the “:true” method will be called. In my case I have written a single shell script that accept both start and stop arguments and will respond accordingly. The script is quite easy to understand, and is quite similar to old-style init startup scripts (you can have a look at many example of method scripts in /lib/svc/method/).

Let see in detail the script:

• I first source the smf_include.sh file; this files is sourced by almost all the methods and define some usefull SMF variables and status constants that can be used within the method:

. /lib/svc/share/smf_include.sh

• then, I check if the script is called from under the SMF framework or not:

# SMF_FMRI is the name of the target service. This allows multiple instances
# to use the same script.

if [ -z $SMF_FMRI ]; then
   echo "SMF framework variables are not initialized."
   exit $SMF_EXIT_ERR
fi

• I then define a small function useful later to get the value of the vm/stop_method property of the instance:

getproparg() {
   val=`svcprop -p $1 $SMF_FMRI`
   [ -n "$val" ] && echo $val
}

• later come the start and stop functions. Within the stop funtion, I first retrieve the value of the vm/stop_method property. If not found, I use a default value (“savestate”). Using this variable, I’ll be able to choose how the service stops the VM.

start_vm() {
   /usr/bin/VBoxManage startvm $1 --type vrdp
}

stop_vm() {
   # STOP_METHOD=acpipowerbutton|savestate
   STOP_METHOD="$( getproparg vm/stop_method )"

   [ -z "$STOP_METHOD" ] && STOP_METHOD="savestate"

   /usr/bin/VBoxManage controlvm $1 $STOP_METHOD
}

• As the same method can be used to manage multiple instances (virtual machine) of the same vbox service, I have to retrive the name of the instance from the FMRI of the service:

INSTANCE=$( echo $SMF_FMRI | cut -d: -f3 )

• finally I run the function that corresponds to the argument passed from the SMF framework upon calling the method (start/stop) and exit using an SMF friendly exit status (previously defined in smf_include.sh):

case $1 in
   start)
      start_vm $INSTANCE
      ;;
   stop)
      VM_STATE=$( vm_state $INSTANCE )

      if [ "x$VM_STATE" = "xrunning" ]
      then
         stop_vm $INSTANCE
      else
         echo "INFO: VM $INSTANCE in state $VM_STATE, I won't stop it."
      fi
      ;;
esac

if [ $? -ne 0 ]; then
   echo "ERROR: VM $INSTANCE failed to start/stop."
   exit $SMF_EXIT_ERR_FATAL
fi

exit $SMF_EXIT_OK

Here is the full method script (/export/home/adumont/svc/method/vbox, chmod 755):

#!/sbin/sh
#

. /lib/svc/share/smf_include.sh

# SMF_FMRI is the name of the target service. This allows multiple instances
# to use the same script.

if [ -z $SMF_FMRI ]; then
   echo "SMF framework variables are not initialized."
   exit $SMF_EXIT_ERR
fi

getproparg() {
   val=`svcprop -p $1 $SMF_FMRI`
   [ -n "$val" ] && echo $val
}

start_vm() {
   /usr/bin/VBoxManage startvm $1 --type vrdp
}

stop_vm() {
   # STOP_METHOD=acpipowerbutton|savestate
   STOP_METHOD="$( getproparg vm/stop_method )"

   [ -z "$STOP_METHOD" ] && STOP_METHOD="savestate"

   /usr/bin/VBoxManage controlvm $1 $STOP_METHOD
}

vm_state() {
   /usr/bin/VBoxManage showvminfo $1 --details --machinereadable |
      grep VMState\= | tr -s '"' ' ' | cut -d " " -f2

   if [ $? -ne 0 ]; then
      echo >&2 "ERROR: Failed to get VMState for VM $1"
      exit $SMF_EXIT_ERR_FATAL
   fi
}

INSTANCE=$( echo $SMF_FMRI | cut -d: -f3 )

case $1 in
   start)
      start_vm $INSTANCE
      ;;
   stop)
      VM_STATE=$( vm_state $INSTANCE )

      if [ "x$VM_STATE" = "xrunning" ]
      then
         stop_vm $INSTANCE
      else
         echo "INFO: VM $INSTANCE in state $VM_STATE, I won't stop it."
      fi
      ;;
esac

if [ $? -ne 0 ]; then
   echo "ERROR: VM $INSTANCE failed to start/stop."
   exit $SMF_EXIT_ERR_FATAL
fi

exit $SMF_EXIT_OK

Now that we’ve seen how to write the manifest and method files, let’s register our new SMF service, using first svccfg validate, and then svccfg import:

$ svccfg validate vbox-debian.xml
$ svccfg import vbox-debian.xml
$ svcs svc:/site/xvm/vbox:debian
STATE          STIME    FMRI
disabled       17:42:23 svc:/site/xvm/vbox:debian

The service has been created and is actually disabled. Let’s enable it:

$ svcadm -v enable -ts vbox:debian
svc:/site/xvm/vbox:debian temporarily enabled.

We can see the corresponding processes using ps:

$ ps -ef | grep VB
adumont 28515 28513   2 17:46:09 ?           0:03 /opt/VirtualBox/amd64/VBoxHeadless --comment debian --startvm 8b8505c3-87d5-49a
adumont 28513     1   0 17:46:08 ?           0:00 /opt/VirtualBox/amd64/VBoxSVC --automate
adumont 28510     1   0 17:46:08 ?           0:00 /opt/VirtualBox/amd64/VBoxXPCOMIPCD

Now let’s try to stop the VM:

$ svcadm -v disable -ts vbox:debian
$ ps -ef | grep VB
[no output]

it works! Let’s start it again, and now check the state again, using various command:

$ svcs -l vbox
fmri         svc:/site/xvm/vbox:debian
name         Sun xVM Virtualbox
enabled      true
state        online
next_state   none
state_time   Thu Jul 16 17:49:35 2009
logfile      /var/svc/log/site-xvm-vbox:debian.log
restarter    svc:/system/svc/restarter:default
contract_id  2159
dependency   require_all/none svc:/milestone/network:default (online)
dependency   require_all/none svc:/system/filesystem/local:default (online)

$ svcs -vx vbox
svc:/site/xvm/vbox:debian (Sun xVM Virtualbox)
State: online since Thu Jul 16 17:49:35 2009
See: man -M /usr/share/man -s 1 Sun xVM Virtualbox
See: /var/svc/log/site-xvm-vbox:debian.log
Impact: None.

Using the following command we can get the processes associated with the service:

$ svcs -p vbox
STATE          STIME    FMRI
online         17:49:35 svc:/site/xvm/vbox:debian
17:49:35    28568 VBoxXPCOMIPCD
17:49:35    28571 VBoxSVC
17:49:35    28573 VBoxHeadless

When starting a service, SMF start the associated processes in a “contract” (a group of processes). This is specially useful to handle service conditions like process failure and signals (core, kill,…). The contract information (ctid) can be seen using ctstat:

$ svcs -v vbox:debian
STATE          NSTATE        STIME      CTID   FMRI
online         -             17:49:35   2154   svc:/site/xvm/vbox:debian

$ ctstat -i 2154 -v
CTID    ZONEID  TYPE    STATE   HOLDER  EVENTS  QTIME   NTIME
2154    0       process owned   7       0       -       -
cookie:                0x20
informative event set: none
critical event set:    core signal hwerr empty
fatal event set:       none
parameter set:         inherit regent
member processes:      28568 28571 28573 
inherited contracts:   none
service fmri:          svc:/site/xvm/vbox:debian
service fmri ctid:     2154
creator:               svc.startd
aux:                   start

Now, let’s restart the VM:

$ svcadm -v restart vbox:debian
Action restart set for svc:/site/xvm/vbox:debian.

and see the corresponding log entries:

$ cat /var/svc/log/site-xvm-vbox:debian.log
...
[ Jul 16 18:05:44 Stopping because service restarting. ]
[ Jul 16 18:05:44 Executing stop method ("/export/home/adumont/svc/method/vbox stop"). ]
VirtualBox Command Line Management Interface Version 3.0.0
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[ Jul 16 18:05:46 Method "stop" exited with status 0. ]
[ Jul 16 18:05:52 Executing start method ("/export/home/adumont/svc/method/vbox start"). ]
VirtualBox Command Line Management Interface Version 3.0.0
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Waiting for the remote session to open...
Remote session has been successfully opened.
[ Jul 16 18:05:53 Method "start" exited with status 0. ]

Finally, the way the SMF service will stop the VM can be changed by modifying the instance property vm/stop_method:

For example, if you want to orderly shutdown your VM upon service stop, you can set the property to acpipowerbutton:

$ svccfg -s vbox:debian setprop vm/stop_method=acpipowerbutton
$ svccfg -s vbox:debian refresh

if on the contrary you prefer to have the machine state frozen and saved to disk (by Virtualbox, not by the VM guest OS) use savestate:

$ svccfg -s vbox:debian setprop vm/stop_method=savestate
$ svccfg -s vbox:debian refresh

References:

• OpenSolaris Service Management Facility Guide
• A presentation on SMF by Sebastian Kirsh, including contracts,
• Another presentation on SMF by Bob Netherton

site/xvm/vbox

ShareThis / Compartelo

activeTechPros is a destination for IT professionals to benchmark their salary and know their tech worth in different job markets. activeTechPros’ IT salary benchmark wizard is driven by aggregated information provided by IT professionals from around the world. With the IT salary benchmark wizard, finding out whether you are paid your tech worth is made simple.

Me parecio interesante ya que tiene bastantes usuarios de España ya registrados .

Get started by creating your profile and get to know your tech worth: IT professionals: Compare IT jobs average salary & get pay scale report.

ShareThis / Compartelo

My uTorrent arquitecture

The physical server is an eMachine low-cost PC turned into a small home server, running Opensolaris 2009.06.

I have then a Debian Linux virtual machine running on Sun xVM Virtualbox in the Opensolaris host.

Inside the Debian VM, I then run uTorrent (native windows binary file) under WINE.

Regarding the storage, the Opensolaris host shares a ZFS filesystem to the Debian VM using “Virtualbox Shared Folders”: the folder is like exported from the host and mounted in the VM with the help of Virtualbox Guest Additions for Linux.

Why such an instalation?

• I migrated my home server to Opensolaris, but — at that time at least — Wine for Opensolaris was not “ready” to be able to run uTorrent (I had a socket problem). I’ve not tried again, maybe it is solved now.
• Before the migration my uTorrent server was a physical Debian Linux server, so once the Linux Virtualbox VM was setup, I have only had to replicate the same setup, which was quite easy.
• I like a lot uTorrent, ZFS, Virtualbox and Opensolaris, so it was good mix of all of them ;-).

ShareThis / Compartelo

• Solaris Sysadmin: a Community of Knowledge for Solaris System Administrators, a place where you’ll start
  

  …learning about Sun’s Solaris Operating System (Solaris OS). Select a Solaris certification that you want to pursue and click on the corresponding topics to get started. You’ll quickly see how easy it is to become a certified Solaris System Administrator. You can also buy on-demand labs to practice what you learn!

  • Booting SPARC and x86 Based Systems,
  • Controlling System Processes,
  • Create and Manage Users,
  • Installing Solaris 10,
  • Manage Local Devices,
  • Manage UFS File Systems,
  • Managing Software Packages Using Package Commands,
  • Managing Solaris Patches Using Patch Commands,
  • Managing User Access,
  • Performing File System Backups,
  • Performing Mounts and Unmounts,
  • Printer Services,
  • Safely Shutting Down a Solaris System,
  • System Restores,
  • Working with UFS and ZFS Snapshots…
• OpenSolaris Learning On Demand Service: a cloud service where you can try for free an Opensolaris machine, right from your browser:
  

  You can try out new features of OpenSolaris 2008.11 without the hassles of downloading, installing or configuring–all for free. Simply login to the portal using your My Sun Connection account (registration is free) and then click on the “Join” link to the right and you will be entitled to access the cloud.

The truth, Sun’s doing a lot to spread the use of their OS, and it’s a good thing. Some years ago I would have love the same from HP to learn HP-UX!

ShareThis / Compartelo