Tuesday, April 29, 2008

Error en Pegasus tras actualizar a ESX 3.5 Update 1

Hoy e actualizado uno de los ESX 3.5 que tengo en el laboratorio a la versión 3.5 Update 1 y me ha dado un error al reiniciar. Dicho error ya está documento y se cuenta con solución. Como cabe la alta probabilidad de que esto me ocurra más adelante dejo aquí la receta para solucionarlo.

Información obtenida de un articulo de Yellow Bricks y los foros de VMware:


Edit the roleauth-schema compiler directive to include the VMware_Identity class definition using


nano /var/pegasus/vmware/install_queue/3_files/mofs/root/PG_Interop/roleauth-schema.mof


Add the bolded line above the pre-existing member directive.


#pragma include ("VMware_Identity.mof")

#pragma include ("VMware_IdentityMemberOfCollection.mof")


It also needs to be added in the standard cimv2 path.


nano /var/pegasus/vmware/install_queue/3_files/mofs/root/cimv2/roleauth-schema.mof


#pragma include ("VMware_Identity.mof")

#pragma include ("VMware_IdentityMemberOfCollection.mof")


Copy the missing file from the stardard cimv2 path to the shared path.


cp
/var/pegasus/vmware/install_queue/3_files/mofs/root/cimv2/VMware_Identity.mof
/var/pegasus/vmware/install_queue/3_files/mofs/root/PG_Interop/



Stop and start the service with these commands.


/etc/init.d/pegasus stop

/etc/init.d/pegasus start


Once the scripts completes the install_queues will be empty and the service will start much more quickly.

Eso es todo.

Han perdido la cabeza

Lo siento, pero no. Si tu tienes, a fecha 29 de abril de 2008, un software de virtualización que es peor que VMware ESX pues tienes que admitirlo. Puede que esa situación cambie pero no puedes utilizar escusas de mal perdedor.

Y esto a que viene. Pues he leido la siguiente entrada:
HYPER-V QUICK MIGRATION & VMWARE LIVE MIGRATION PART 3...
Las escusas que dan son estúpidas. Si no tienes migración en vivo pues no la tienes, ya la tendras. Pero por no tenerla no vas a decir que no es necesaria. Con excusas como esta si te consideras un gran profesional de los sistemas TI pierdes toda la razón.

Yo por ejemplo digo que VMware ESX es mejor que XenServer, y objetivamente lo es. Pero eso no quita que no sea una opción a tener en cuenta en determinados entornos. Tanto es así que ahora mismo me encuentro estudiando para obtener la certificación Citrix Certified Professional for XenServer 4, porque le veo muchas posibilidades bajo determinadas circunstancias. Realmente donde Citrix XenServer pierde la batalla contra VMware es en la parte de administración: XenCenter. A XenCenter todavía le queda un largo recorrido para poder equipararse a VMware VirtualCenter.

Seguramente algún dia Hyper-V será un gran producto, no en vano esta detras de él la todo poderosa Microsoft, y podrá medirse de tu a tu con VMware, pero hoy no.

Desviación del tiempo en eDirectory bajo VMware ESX Server


En servidores Novell ejecutando eDirectory bajo entorno Linux, lógicamente estoy hablando de la versión SLES, existe el problema de que el reloj de tiempo local de la máquina virtual no se mantiene sincronizado.

Este es un problema conocido y del que se puede obtener una solución y mas información aquí.

La solución es bastante sencilla y consiste en modificar la entrada de arranque en el fichero /boot/grub/menu.lst y añadir la opción clock=pit.

Tras modificar esta opción en las dos máquinas virtuales que están ejecutando el servidor eDirectory tenemos que configurar el servidor de tiempos NTP. A mí particularmente me gusta configurar una de las máquinas virtuales para que sincronice contra: es.pool.ntp.org y la segunda que sincronice con la primera:

Servidor a:
# server 127.127.1.0 # local clock
# fudge 127.127.1.0 stratum 10
server es.pool.ntp.org prefer

Servidor b:
# server 127.127.1.0 # local clock

# fudge 127.127.1.0 stratum 10
server x.x.x.x prefer

Donde x.x.x.x es la IP del servidor A. Como siempre si el servidor esta usando el firewall interno propio de la SLES habrá que abrir el correspondiente puerto.

Tuesday, April 15, 2008

Activar log en Zenworks 7 para Linux

Por defecto el soporte de log del servicio de Importar / Eliminar Workstation Automaticamente en la versión de Zenworks 7 para Linux está deshabilitado y para activarlo tenemos que hacer lo siguiente:

  • Editar el fichero /etc/opt/novell/zenworks/zdm/novell-zdm-awsi.conf
  • Localizar las entradas:
    • logfilelevel : por defecto está puesto a -1 (no log) lo cambiamos a 3 para obtener la máxima salida
    • IMPORT_SERVICE_LOGFILE : ruta del archivo de log, por defecto en /var/opt/novell/log/zenworks/awsi.log
    • REMOVAL_SERVICE_LOGFILE : ruta del archivo de log, por defecto en /var/opt/novell/log/zenworks/awsr.log
Con esto ya podemos depurar los problemas que nos surgan. Además en el archivo novell-zdm-awsi.conf podemos definir otros parámetros del servicio, como pueden ser el servidor LDAP que utilizará para realizar el registro.


Friday, April 11, 2008

Pestaña de seguridad

Para habilitar la pestaña seguridad en un Windows XP que no este unido a un dominio se debe modificar la entrada de registro:

HKLM/SYSTEM/CurrentControlSet/Control/LSA/ForceGuest = 0

A partir de ese momento cuando se pulsa botón derecho sobre una carpeta o fichero aparecerá la pestaña seguridad y podremos gestionar más detalladamente la seguridad que queremos tener .