Nuestro funcionamiento es muy sencillo, creamos una máquina virtual, generalmente ubuntu, esta maquina se arranca y se le ofrece conexión remota al profesor. Una vez que está todo listo, se replica la imagen a los demas equipos para que los alumnos lo tengan todo listo.

Con esto nos ahorramos mucho tiempo de configuración, puesto que no tenemos que ir equipo por equipo, ni hacemos venir al profesor (sobretodo si son cursos europeos o similares)

Bueno, pues hasta la semana pasada todo iba correcto, trabajamos con el Player version 2, las imagenes hacian NAT sobre el cliente base (tambien conocido como Dom0) y al estar esto por NAT la ip era auto asignada. Recordemos que haciendo Bridge necesitarmos tener una ip diferente para el dom0 y para la imagen.

El caso… por algun tipo de movimiento de la gente de Vmware han decidido que la utilidad vmnetcfg no esté disponible así como así.

Pues bien, por circustancias de la vida, y en concreto una imagen de CentOS que usamos para un curso de Schrödinger nos fue necesario actualizar a  la versión 3… y oh sorpresa… nos quedamos sin esta utilidad.

Pues bien… parece que la cosa tiene solución, en concreto 2 posibles, por un lado utilizar los paquetes de la version 2.5 (aunque si actualizasteis como yo, adios paquetes)… o la más comoda, que es extraer el contenido del paquete de instlación del player3.

En concreto lo que yo hice fue lo siguiente:

ejecutar cmd (INICIO -> EJECUTAR -> Teclear(CMD))

Teclear(vmware-player-version.exe /e Directorio_temporal)

Con esto hemos desempaquetado (extraido) el contenido del instalable en Directorio_temporal.

Ahora nos desplazamos hasta ese lugar, una vez dentro podemos ver un fichero estilo network.cab, pues bien, lo descomprimimos (yo he usado winrar).

Una vez descomprimido, hoh sorpresa ficherito vmnetcfg.exe (ademas con icono nuevo)

Ahora solo falta moverlo al directorio de nuestra instalación del Player y ya lo tendremos.

No entiendo muy bien este moviemiento de VMware, de si disponer de dicha aplicación pero que no sea disponible en la instalación… pero bueno, mientras sea asi de “sencillo” disponer de ella.

En nuestro caso, donde trabajo, tenmos 3 librerias de cintas lt0, cada cinta con una capacidad superior al Terabyte… lo que hace que tengamos muuuuchos datos guardados y muuuchos y muy diferente indole.

Conociendo esto, tenemos que ver que estos datos generan unos ficheros, que data protector llama, internal database filenames y que se guardan a nivel local donde reside el servidor.

Por defecto este fichero tiene un límite de 2G, en concreto de fnames.dat tiene un valor de 2097152 kB.

Pero… que ocurre cuando estamos haciendo un backup y tenemos el siguiente mensaje:

[12:1168] There is no more space in the Internal Database for filenames.

Claramente el principal problema es que directamente nos quedamos sin logs… dios… os imaginais un itAdmin o SysAdmin sin logs a los que recurrir… un kaos…

Pues la solucion es muy sencilla, se trata simplemente de aumentar o añadir tamaño extra a nuestro fnames.dat.

Este fichero se encuentra por defecto en la ruta /var/opt/omni/server/db40/datafiles/cdb

Es importante primero revisar si efectivamente nos quedamos sin espacio, para ello usaremos el comando “/opt/omni/sbin/omnidbutil -extendinfo” que nos muestra la informacion.

Os pongo un ejemplo de mi caso:

Base file “fnames.dat”:
Device               = /var/opt/omni/server/db40/datafiles/cdb
Number of extensions = 3
Maximum size         = 2097152 [kB]
Current size         = 2097152 [kB]
Extension file “fnames.dat1″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat2″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat3″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Maximum size with extensions = 8385536 [kB]
Current size with extensions = 8385536 [kB]

Como podeis ver, en mi caso el fichero ya habia sido aumentado hasta en 3 ocasiones, y siempre de 2 en 2 gigas

Pues ahora, unicamente necesitamos indicarle que genere otros 2 gb para poder seguir almacenando datos.

omnidbutil -extendfnames /var/opt/omni/db40/datafiles/cdb -maxsize 2048

Acordaros de poner la ruta si no disponeis del comando en el path.

Con este comando, generais un fnames.datX donde X es el numero incremental en relacion al ultimo, en nuestro caso, X corresponderá a 4

Realizando el comando anterior, “/opt/omni/sbin/omnidbutil -extendinfo”,

Base file “fnames.dat”:
Device               = /var/opt/omni/server/db40/datafiles/cdb
Number of extensions = 4
Maximum size         = 2097152 [kB]
Current size         = 2097152 [kB]
Extension file “fnames.dat1″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat2″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat3″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 2096128 [kB]
Extension file “fnames.dat4″:
Device       = /var/opt/omni/server/db40/datafiles/cdb
Maximum size = 2096128 [kB]
Current size = 0 [kB]
Maximum size with extensions = 10481664 [kB]
Current size with extensions = 8385536 [kB]

Si os fijais, ahora tenemos un fichero nuevo, y el valor de Maximun size es diferente al de Current size.