]# vzctl start 1
Starting Container …
Wrong HW address don’t start SVE
Error executing mount script /var/opt/pva/pp/sve//scripts/mount
Container start failed

Probamos para ver un poco mas de detalle

[root@hn31 ~]# vzctl –verbose start 1
Starting Container …
Running command: /usr/sbin/vzquota show 1 -p /var/opt/pva/pp/sve//fs
Running command: /usr/sbin/vzquota on 1 -s 0 -R -p /var/opt/pva/pp/sve//fs -b 1048676 -B 1153124 -i 200000 -I 220000 -e 0 -n 0
Mounting root: /vz/template:/var/opt/pva/pp/sve//fs /vz/root/1
Running command: /var/opt/pva/pp/sve//scripts/mount
Wrong HW address don’t start SVE
Error executing mount script /var/opt/pva/pp/sve//scripts/mount
Running command: /usr/sbin/vzquota stat 1 -f -p /var/opt/pva/pp/sve//fs
Running command: /usr/sbin/vzquota off 1 -p /var/opt/pva/pp/sve//fs
Running command: /usr/sbin/vzquota setlimit 1 -p /var/opt/pva/pp/sve//fs -b 1048676 -B 1153124 -i 200000 -I 220000 -e 0 -n 0
Container start failed

El problema es que el script de arranque chequea los interfaces, para ello procedemos a editar el archivo que falla para ponerlo en modo debug el .sh File /var/opt/pva/pp/sve//scripts/mount
poniendo en la primera linea: “#!/bin/bash -x” y de aqui ya empiezo a ver la movida por donde viene

[root@hn31 ~]# vzctl –verbose start 1
Starting Container …
Running command: /usr/sbin/vzquota show 1 -p /var/opt/pva/pp/sve//fs
Running command: /usr/sbin/vzquota on 1 -s 0 -R -p /var/opt/pva/pp/sve//fs -b 1048676 -B 1153124 -i 200000 -I 220000 -e 0 -n 0
Mounting root: /vz/template:/var/opt/pva/pp/sve//fs /vz/root/1
Running command: /var/opt/pva/pp/sve//scripts/mount
+ . /etc/sysconfig/vz-scripts/1.conf
++ VERSION=2
++ ONBOOT=yes
++ KMEMSIZE=11055923:11377049
++ LOCKEDPAGES=256:256
++ PRIVVMPAGES=65536:69632
++ SHMPAGES=21504:21504
++ NUMPROC=240:240
++ PHYSPAGES=0:2147483647
++ VMGUARPAGES=33792:2147483647
++ OOMGUARPAGES=26112:2147483647
++ NUMTCPSOCK=360:360
++ NUMFLOCK=188:206
++ NUMPTY=16:16
++ NUMSIGINFO=256:256
++ TCPSNDBUF=1720320:2703360
++ TCPRCVBUF=1720320:2703360
++ OTHERSOCKBUF=1126080:2097152
++ DGRAMRCVBUF=262144:262144
++ NUMOTHERSOCK=360:360
++ DCACHESIZE=3409920:3624960
++ NUMFILE=9312:9312
++ AVNUMPROC=180:180
++ NUMIPTENT=128:128
++ MEMINFO=privvmpages:1
++ CPUUNITS=1000
++ DISKSPACE=1048576:1153024
++ DISKINODES=200000:220000
++ QUOTATIME=0
++ OFFLINE_MANAGEMENT=yes
++ ARCH=x86
++ PLATFORM=linux
++ SLMMEMORYLIMIT=268435456:268435456
++ VE_ROOT=/vz/root/1
++ VE_PRIVATE=/var/opt/pva/pp/sve/
++ DISTRIBUTION=sve
++ TECHNOLOGIES=’nptl x86′
++ ORIGIN_SAMPLE=basic
++ VEFORMAT=vz3
++ VEID=1
++ IP_ADDRESS=192.168.75.143
+ mkdir -p /vz/root/1/var/opt/pavm/proxy/
+ mkdir -p /vz/root/1/var/log/pavm/
+ mkdir -p /vz/root/1/opt/pavm/
++ cat /etc/vz/redirect.d/vzpp-plesk.conf /etc/vz/redirect.d/vzpp.conf
++ grep PORT
++ sed ‘s/^PORT=”\?\([[:digit:]]*\)”\?/\1/’
+ PORTS_LIST=’8443
4643′
+ ‘[' -z '' ']‘
+ PATH=/bin:/sbin/:/usr/sbin/:/usr/bin/
++ ip route list
++ awk ‘/^default / && $(NF – 1) == “dev” { print $(NF) }’
+ HN_IFACE=
+ HN_ADDRESS=
+ ‘[' -z '' ']‘
+ echo ‘Wrong HW address don’\”t start SVE’
Wrong HW address don’t start SVE
+ exit 1
Error executing mount script /var/opt/pva/pp/sve//scripts/mount
Running command: /usr/sbin/vzquota stat 1 -f -p /var/opt/pva/pp/sve//fs
Running command: /usr/sbin/vzquota off 1 -p /var/opt/pva/pp/sve//fs
Running command: /usr/sbin/vzquota setlimit 1 -p /var/opt/pva/pp/sve//fs -b 1048676 -B 1153124 -i 200000 -I 220000 -e 0 -n 0
Container start failed
[root@hn31 ~]#
[root@hn31 ~]#

desde linea de comandos puedes probar como una linea del script se comporta mal y debes como sigue:

Donde dice:

ip route list | awk ‘/^default / && $(NF – 1) == “dev” { print $(NF) }’

no muestra nada, por lo que hago:

# ip route list | awk ‘/^default / && $(NF – 4) == “dev” { print $(NF -3) }’

Sin embargo opto por poner el interface a pelo en el script, comento la linea de asignación y pongo una asignación eth0, en el script: /var/opt/pva/pp/sve//scripts/mount

# HN_IFACE=`ip route list | awk ‘/^default / && $(NF – 1) == “dev” { print $(NF) }’`
HN_IFACE=’eth0′

y le quitamos el debug de la primera linea.

cd /vz/private

mv xxx.migrated xxx

ln -s /etc/vz/conf/xxx.conf /vz/private/xxx/ve.conf

cd /vz/privatemv xxx.migrated xxxln -s /etc/vz/conf/xxx.conf /vz/private/xxx/ve.conf

En virtuozzo, la documentación es muy escasa y básicamente se dedica a decir que soporta SNMP.

Si queremos empezar a consultar información por SNMP a un Hardware Node, deberos chequear los siguiente pasos:

1. en el fichero /etc/hosts tener una entrada vzsveaddress que referencie la ip de nuestro VPS 1
2. en el fichero /etc/snmp/snmp.conf  añadiremos “proxy -v 2c -c public vzsveaddress .1.3.6.1.4.1.26171″
3. dentro del VPS 1 activaremos el servicio snmpd, manualmente y automaticamente en cada rebote: “service snmpd start” y con ntsysv

una vez hecho esto una consulta del tipo:

# snmpwalk -m SWSOFT-VIRTUOZZO-MIB -v 1 -c public 10.30.20.207 \.1.3.6.1.4.1.26171.1.1

Nos dara un resultado del tipo con información del HArdware Node y de todos los VPS

Cuando esto pasa, muy rara vez ocurre, pero si pasa debermeos hacer revisar la tabla de rutas del destino erroneo y si aparece la borramos hacinedo uns imple:

route del -host a.b.c.d

Es muy raro que suceda pero en ocasiones sucede en migraciones interrumpidas bruscamente ys ituaciones similares.

• Capacidad de hacer backups sin parada
• Posibilidad de levantar nuevas maquinas con el disco virtual de la averiada como directorio secundario
• Posibilidad de asignar recursos adicional al vuelo de forma instantánea (en los VPS sin parada y en los hypervisores con un simple reinicio)
• Nivel de abstracción superior inexistente en servidores físicos.

a veces al actualizar paquetes protesta y todo esta en orden ¿que es? regenera la BBDD de los rpm

[root@hn15 CU-2.6.18-028stab068.3]# rpm -ivh *.rpm
error: Failed dependencies:
        /bin/sh is needed by vzkernel-2.6.18-028stab068.3.x86_64
        /bin/sh is needed by vzkernel-devel-2.6.18-028stab068.3.x86_64
        /bin/sh is needed by vzmodules-2.6.18-028stab068.3.x86_64
[root@hn15 CU-2.6.18-028stab068.3]# rpm -ivh *.rpm –force
error: Failed dependencies:
        /bin/sh is needed by vzkernel-2.6.18-028stab068.3.x86_64
        /bin/sh is needed by vzkernel-devel-2.6.18-028stab068.3.x86_64
        /bin/sh is needed by vzmodules-2.6.18-028stab068.3.x86_64
[root@hn15 CU-2.6.18-028stab068.3]# rpm –rebuilddb
[root@hn15 CU-2.6.18-028stab068.3]# rpm -ivh *.rpm
Preparing…                ########################################### [100%]
   1:vzkernel               ########################################### [ 33%]
   2:vzkernel-devel         ########################################### [ 67%]
   3:vzmodules              ########################################### [100%]
[root@hn15 CU-2.6.18-028stab068.3]#

http://kb.parallels.com/en/1089

 supuestamente te dice como pero, donde diablos esta lo que te dicen que debes tener, el <DISTRIB_DIR>
bajate la iso de Virtuozzo:

#wget http://download.parallels.com/virtuozzo/virtuozzo4.0/linux/iso/lin-x86_64.iso

 

Una vez descargado lo montamos:

#mkdir /root/vz4iso
# mount -o loop -t iso9660 /root/lin-x86_64.iso /root/vz4iso

y luego ya podemos seguir con lo que nos dicen los amigos de parallels.com en su kb 1089

#vzsveinstall -D /root/vz4iso -s SERVICE_CT_IP

# for i in `find /vz/vzup2date/$(awk ‘{print $NF}’ </etc/virtuozzo-release)/ -type d -name TU* | sort -t- -k3 -n`; do echo vzsveupgrade -d $i; done

 

Este ultimo for te imprime los ocmando de upgrade para que hagas u cortar y pegar, me gusta mas asi porque e suna cosa que se hace poco y mejor ver claramente que esta haciendo.

Tambien es una pena que cuando abres un tiquet con prioridad critica, tarden lo insufrible en responder y encima respondan cosas de niños, como si no te hubieses mirado nada, como si no supiesemos usar un buscador.

Tambien es bastante lamentable que cuando les preguntas cosas como estas la respuesta sea si tienes la ultima versión de todo y como has copia los contianers, en vez de decirte la verdad y atajar por el camino recto.

Realmente si valorais vuestro tiempo es preferible que os busqueis gente que se pelee todos los dias con los productos en cuestión que no tener que pedir soporte a la gente de parallels.

Realmente los productos funcionan razonablemente bien y debe haber autenticos “gurus” en los niveles mas altos de la piramide, pero como pasa en general con casi todo ni con un “gold partner” “platinium leches” ni nada que se le parezca vas a tener acceso a esos niveles.

Ciertamente, creo no me creo que los errores que veo cada dia solo me salgan a mi y sea el unico que se los encuentra. SImplemente no me lo creo y lo peor viene cuando acredito al resolución.

Debo dar las gracias a Parallels por obligarme a aprender tanto y sinceramente, estas cosas son las que hacen que el trabajo que realizo entre en la categoria de “VOCACIÓN”.

También debo agradecerle a Parallels que apoyen el de GNU, aunque se salten algunos aspectos.

Tambien debo dar las gracias a la gente de mi entorno (tecnicos,administrativos etc) que no se alteran cuando hablo un poco mas fuerte de lo habitual y los pongo a todos a parir. Debo admitir que en general suelo tener razón en lo que digo aunque lo exprese de forma un poco mas beemente de lo estrictamente necesario.

You are not authorized to log in. Please contact your service provider for support.

SEguramente se debe a algun tipo de corrupcíón del agente que gestiona los servicios de Virtuozzo. En ocasiones pasa cuando el disco duro se llena o cosas similares, aun cuando lo hemos resuelto el problema persiste.

Debe aplicar el comando: vzagent_ctl restart

http://forum.swsoft.com/showthread.php?t=52544

Lamento ser tan exigente pero aun no eh conseguido que la gente de parallels me indique que condiciones deben cumplirse para garantizar, GARANTIZAR, “GARANTIZAR” que el container va a funcionar.

Según parallels cuando migras un container los EZ-Templates son sincronizados y a continaución el container.

Yo he verificado empiricamente que cuando migras unc ontainer de un Hardware Node viejo a uno nuevo (nuevo sin templates), las herramientas de parallels te copia la ultima versión de los paquetes instalados en el container que estas migrando.

Respito LA ULTIMA VERSIÓN. Esto significa que si por alguna razón tiene algún paquete con otra versión que no es la ultima luego no va a funcionar.

Esto es vital para los planes de contingencia, ya que te puede imaginar la cara que se le queda a todo el mundo cuando tienen una movida “chunga”.

Para evaluar que una migración va a funcionar correctamente te propongo un metodo sin parar:

• En el servidor de origen duplicamos el contianer (no requiere parada) vzmlocal -C 123:9123
• Luego lo movemos al de destino vzmigrate root@hndestino 9123
• En el de destino hacemos un vzfsutil -t /vz/template /vz/private/9123 –call

Si van a haber problemas en la migración esto nos dara una buena tanda de quejas varias.

Ni que decir tiene que lo que digo es cierto y que antes actulize los cache de los templates y todos los paquetes del container y eso falla.

Con lo que aqui indico os asegurais el tiro, en general cuando las migración de 1 contianer va entre 2 HN, iran todas, pero no esta mal verificar la primera con un container antiguo preferiblemente.