Solaris: SVM deployment and ZFS migration with minimun downtime

Hace muy pocos días, compré un viejo, pero en excelente estado, servidor Sun Fire 280R. El equipo cuenta con algunos features más que interesantes, equipado con dos procesadores UltraSPARC64 III, 2 Gb. de RAM, RSC card, fuentes de alimentación redundantes, lector de DVD-R y dos discos SCSI de 36 Gb cada uno.
Al momento de bootearlo por primera vez, me encontré con Solaris 10 5/08 instalado, y prácticamente sin uso. Por lo cual no hacía reinstalar el sistema operativo. Había un solo tema negativo en esta configuración por default, el layout de particionamiento de los discos y asignación filesystems no me gustaba. En uno de los discos estaba el sistema operativo, el /export/home, en otro utilizando ZFS cree un zpool donde instalé una zona que no quería volver a reinstalar.

P2V migration: from Solaris 9 server to Solaris 10 branded zone.

Hace poco tiempo atrás, participe en un proyecto en el cual se me asigno la tarea de migrar un obsoleto equipo en Solaris 9, junto a sus aplicaciones, a un nuevo Sun Enterprise M3000 con Solaris 10.
El proceso es en si sencillo y brinda una flexibilidad enorme al hacer este tipo de migraciones que cada vez se vuelven mas frecuentes en datacenters del mundo.
La idea principal es disminuir la cantidad de hardware necesario y el espacio ocupado por este en los datacenters, como así también aprovechar las ventajas que provee la posibilidad de utilizar zonas para disminuir costos, como así también reducir el punto de falla de equipos, debido a que tarde o temprano, esto debería ser migrado ya que en estos tiempos Solaris 9 a quedado obsoleto en el mercado.

BIND: Update zone serial for zone trasfers

Supongamos que tenemos un BIND, configurado como master de una zona y hacemos cambios en el archivo de la zona del mismo. Como se entera el DNS slave, que dichos cambios fueron modificados?. Fácil, el servidor que actúa como master, envía un hash al slave, del archivo de la zona, el slave lo recibe y compara con la copia que tiene el. Si el valor del hash es distinto, entonces inicia la transferencia de la zona.
Supongamos que nuestra configuración es la siguiente:

En el master:

zone "fakezone.net" {
        type master;
        allow-transfer { 192.168.0.2; };
        file "master/fakezone.net";
};

En el slave:

zone "fakezone.net" {
        type slave;
        file "slaves/fakezone.net";
        masters { 192.168.0.100; };
        allow-notify { 192.168.0.100; };
};