sdzzds
04/02/2011, 11:07
Bueno no quite el raid, pero como decia Tony en un post anterior he seguido los pasos que llevan a instalar los modulos con initramfs y ahora ha arrancado. Gracias
Proxmox: kernel 2.6.32-4 disponible
PacoSS
04/02/2011, 10:31
Publicado inicialmente por tonysanchez
sdzzds
04/02/2011, 09:47
Hola Tony este es mi fstab:
#
/dev/md1 / ext3 errors=remount-ro 0 1
/dev/md2 /var/lib/vz ext3 defaults 1 2
/dev/sda3 swap swap defaults 0 0
/dev/sdb3 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
Como quito el raid desde aquí? no necesito cambiar nada de con mdadm?
Gracias
#
/dev/md1 / ext3 errors=remount-ro 0 1
/dev/md2 /var/lib/vz ext3 defaults 1 2
/dev/sda3 swap swap defaults 0 0
/dev/sdb3 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
Como quito el raid desde aquí? no necesito cambiar nada de con mdadm?
Gracias
tonysanchez
04/02/2011, 08:23
Briconsejo.
El tema es ya una clasico que segun soporte ya esta solucionado pero eso es una falacia como al copa de un pino.
El tema sigue estando en que algunos modelos de maquinas (y la ausencia de manual correct por parte de OVH ya que tips hay muchos pero de usuario y no de soporte, lo cual ya os lo digo soporte, falla con VUESTRAS CONDICIONES DE CONTRATACION y vuestra publicidad ya que hablais de manualkes, y hace años que ya no se editan nuevos) peta el tema con el RAID.
Rebota en modo rescue.
Edita el fstab para no usar RAID.
Reinicia. Veras que funciona.
Despues si quieres despotrica con esta gente a ver si te hacen caso.
El tema es ya una clasico que segun soporte ya esta solucionado pero eso es una falacia como al copa de un pino.
El tema sigue estando en que algunos modelos de maquinas (y la ausencia de manual correct por parte de OVH ya que tips hay muchos pero de usuario y no de soporte, lo cual ya os lo digo soporte, falla con VUESTRAS CONDICIONES DE CONTRATACION y vuestra publicidad ya que hablais de manualkes, y hace años que ya no se editan nuevos) peta el tema con el RAID.
Rebota en modo rescue.
Edita el fstab para no usar RAID.
Reinicia. Veras que funciona.
Despues si quieres despotrica con esta gente a ver si te hacen caso.
sdzzds
04/02/2011, 02:40
Publicado inicialmente por PacoSS
He cambiado el default por 1 y por 2, he añadido las lineas con el nombre del kernel pero nada de nada y ahora no puedo arrancarlo.
Por otro lao proxmox no se puede arrancar por net boot no? Se inicia bien pero los VM se queda parados y no arrancan.
Gracias.
PacoSS
22/10/2010, 12:02
Teniendo en cuenta (en mi caso), que mi kernel actual no es vulnerable y me va de perlas, que el proxmox actualiza sin problemas sus scripts con apt-get, ... pues como que me voy a estar quieto.
El momento ideal para mí sería cuando ampliase la máquina, pero como mi uso de la CPU es del 15% en este EG-10Hybrid (frente al 40-50% en un EG-09), pues veo lejana cualquier migración.
No uso qemu, solo OpenVZ, y veo por los parches, que casi todos los cambios vienen por qemu.
Asi que ... virgencita que me dejen como estoy.
El momento ideal para mí sería cuando ampliase la máquina, pero como mi uso de la CPU es del 15% en este EG-10Hybrid (frente al 40-50% en un EG-09), pues veo lejana cualquier migración.
No uso qemu, solo OpenVZ, y veo por los parches, que casi todos los cambios vienen por qemu.
Asi que ... virgencita que me dejen como estoy.
tonysanchez
22/10/2010, 11:40
Para mi es mejor, tener una maquina de pruebas donde realizo las pruebas. Claro que esto es desembolsar XX al mes...
Pero mis clientes estan mas tranquilos que cinco minutos, y por supuesto yo no pierdo 3 horas.
Por cierto 3 hora y pico en horario nocturno a XX la hora de ingeniero, = muchos euros...
E insisto, cuando te des un batacazo por una IP failover queda en Dios sabe donde, y comienzan los trucos para meterla de uno a otro lado, 5 minutos + 5minutos + 5 minutos ya son 15 minutos.
En fin, creo que lo mejor, es aportar al post, lo que soluciona el problema, no nuestras opiniones que a veces son muy vacuas sobre como hacer el trabajo. Lo digo porque ya he visto alguna opinion sobre que y como, y me ha sorprendido mucho.
De buen rollo.
Pero mis clientes estan mas tranquilos que cinco minutos, y por supuesto yo no pierdo 3 horas.
Por cierto 3 hora y pico en horario nocturno a XX la hora de ingeniero, = muchos euros...
E insisto, cuando te des un batacazo por una IP failover queda en Dios sabe donde, y comienzan los trucos para meterla de uno a otro lado, 5 minutos + 5minutos + 5 minutos ya son 15 minutos.
En fin, creo que lo mejor, es aportar al post, lo que soluciona el problema, no nuestras opiniones que a veces son muy vacuas sobre como hacer el trabajo. Lo digo porque ya he visto alguna opinion sobre que y como, y me ha sorprendido mucho.
De buen rollo.
macklus
22/10/2010, 11:13
tonysanchez, me vas a permitir que me de por aludido ;-)
Publicado inicialmente por tonysanchez
Sobre una actualización de proxmox realizada hace unos días, con 3 VM de 467 GB en total:
Tiempo total: 3 horas 57 minutos, en horario nocturno.
No es tan rápido, por supuesto, ni tan óptimo, en eso estamos de acuerdo, pero:
Y sobre todo, me aseguro de que mis clientes no van a tener problema alguno por esas actualizaciones. No es la primera vez que al actualiza un proxmox, o al reiniciarlo, falla estrepitosamente, y entre que lo reinician en el data, y demás, pierdo un tiempo muy valioso, porque los que sufren son los clientes.
Para mi, este tipo de cosas son las que le dan valor a proxmox, y a mis clientes las versiones y demás se la sudan, ellos lo que quieren es tranquilidad, que es lo que les puedo ofrecer con este sistema.
PD: Que quede claro que esto lo comento de buen rollo, y de cara a mantener un debate "sano" sobre el tema.
Saludos.
Publicado inicialmente por tonysanchez
- Restaurar el backup de las VM en el servidor de backups
- Sincronizar los datos con vzmigrate
- Cambiar las IP
- Reinstalar proxmox
- Adaptar proxmox a mi configuración
- Migrar las VM
- Cambiar de nuevo las IPs
Tiempo total: 3 horas 57 minutos, en horario nocturno.
No es tan rápido, por supuesto, ni tan óptimo, en eso estamos de acuerdo, pero:
- Al ser una tarea programada, mis clientes están avisados, y nadie se queja
- El tiempo real de caida para un cliente no es ni 10 minutos
- Me garantiza que, ante cualquier fallo ( por ejemplo que el instalador falle ), mis clientes ni se van a dar cuenta
Y sobre todo, me aseguro de que mis clientes no van a tener problema alguno por esas actualizaciones. No es la primera vez que al actualiza un proxmox, o al reiniciarlo, falla estrepitosamente, y entre que lo reinician en el data, y demás, pierdo un tiempo muy valioso, porque los que sufren son los clientes.
Para mi, este tipo de cosas son las que le dan valor a proxmox, y a mis clientes las versiones y demás se la sudan, ellos lo que quieren es tranquilidad, que es lo que les puedo ofrecer con este sistema.
PD: Que quede claro que esto lo comento de buen rollo, y de cara a mantener un debate "sano" sobre el tema.
Saludos.
tonysanchez
21/10/2010, 23:01
Con cariño para ti PacoSS, que ya lo he probado yo.
http://forum.proxmox.com/threads/468...est-repository
La gracia esta en que el initramfs.conf que tiene la distro instalada, obvia el tema de los modulos.... (kernel monolitco) y el arranque si lo ves por el vKVM veras un,
Que viene a ser como un kernel panic pero mas gracioso.
Siguiendo los pasos del caballero del post, perfect. Bueno yo no monto las cosas como el post, sino con el metodo OVH Manuales, porque sino el rebote malo.
Tambien se puede hacer antes que casque (por eso lo de escribirlo aqui) editando simplemente el fichero
Despues el update-initramfs -vtuk
Aqui un apunte para el TEAM de OVH. El manual sobre el update-initramfs esta mal... ya que
No es un comando correcto ya que le faltan parametros. ... deberias corregirlo que despista y cabrea a lso usuarios este tipo de cosas.
Y tambien aprovecho para decir, que para tener un sistema en el que cuando una maquina cae en desgracia por que esta monitorizada, ponerla en cuarentena para esperar una hora a que el tecnico, vea el probblema, y simplemente te la pase a modo rescue, sin decirte ni pio, o diciendo el meail automatico.."Ya funciona .." y luego "Modo rescue" para eso mejor no hacer nada ....
Y la lastima es que estas cosas, en el data se ven, se pueden reportar, y se pueden solventar, documentandolas para el resto de los "clientes"
Lo demas, es cubrir la pagina ... pero cubrirla de ...
Un saludo
NOTA.
Consejos de ese tipo ...
http://forum.proxmox.com/threads/468...est-repository
La gracia esta en que el initramfs.conf que tiene la distro instalada, obvia el tema de los modulos.... (kernel monolitco) y el arranque si lo ves por el vKVM veras un,
Código:
/bin/sh: can't access tty: job control turned off
Siguiendo los pasos del caballero del post, perfect. Bueno yo no monto las cosas como el post, sino con el metodo OVH Manuales, porque sino el rebote malo.
Tambien se puede hacer antes que casque (por eso lo de escribirlo aqui) editando simplemente el fichero
Código:
/mnt/etc/initramfs-tools/initramfs.conf sed -i "s/^MODULES=.*/MODULES=most/g" /mnt/etc/initramfs-tools/initramfs.conf
Aqui un apunte para el TEAM de OVH. El manual sobre el update-initramfs esta mal... ya que
Código:
update-initramfs `uname -r`
Y tambien aprovecho para decir, que para tener un sistema en el que cuando una maquina cae en desgracia por que esta monitorizada, ponerla en cuarentena para esperar una hora a que el tecnico, vea el probblema, y simplemente te la pase a modo rescue, sin decirte ni pio, o diciendo el meail automatico.."Ya funciona .." y luego "Modo rescue" para eso mejor no hacer nada ....
Y la lastima es que estas cosas, en el data se ven, se pueden reportar, y se pueden solventar, documentandolas para el resto de los "clientes"
Lo demas, es cubrir la pagina ... pero cubrirla de ...
Un saludo
NOTA.
- Cambiar IP failover en modo bridge minimo 5 minutos entre IP e IP, unas 3 IP unos 15 minutos.
- Como no tenemos determinada infratructura, al menos 5 minutos de perdida de datos o de outage para los clientes de cada VPS por migracion
- Posibles fallas en el movimiento de IP's
- Tiempo perdido en migraciones de VPS, cualquier que halla migrado 400GB de VPS sabe a lo que me refiero. No es banal.
- ...
Consejos de ese tipo ...
macklus
30/09/2010, 15:36
Para este tipo de cosas, proxmox es lo mejor.
Mueves las máquinas virtuales a otro servidor, cambias la IP failover, y lo tienes todo funcionando.
Reinstalas el otro servidor, con calma, lo adaptas a tu gusto, vuelves a cambiar, y listo.
Mueves las máquinas virtuales a otro servidor, cambias la IP failover, y lo tienes todo funcionando.
Reinstalas el otro servidor, con calma, lo adaptas a tu gusto, vuelves a cambiar, y listo.
PacoSS
30/09/2010, 11:47
Ni de coña incumplo la ley Zeroth de la informática: "si funciona, no lo toques"
a-n-t-o-n-i-o
30/09/2010, 11:13
Publicado inicialmente por PacoSS
no he probado pasar de 2.6.24-11-pve a 2.6.32-4-pve, por lo que no tengo info al respecto.
PacoSS
30/09/2010, 10:53
El nuevo kernel 2.6.32-4-pve no arranca en mi EG-10-Hybrid.
Por supuesto he seguido los pasos descritos anteriormente, update-grub incluido, y he tenido que arrancar en modo rescue, montar la particion /boot, editar el fichero /boot/grub/grub.cfg y donde decia
default = 0
cambiarlo por 2, que es el antiguo kernel.
Luego de arrancar, también lo he cambiado en el fichero /etc/default/grub, que son los parámetros que usa update-grub.
Asi que sigo con el 2.6.24-11-pve. Mas vale lo malo conocido ...
Por supuesto he seguido los pasos descritos anteriormente, update-grub incluido, y he tenido que arrancar en modo rescue, montar la particion /boot, editar el fichero /boot/grub/grub.cfg y donde decia
default = 0
cambiarlo por 2, que es el antiguo kernel.
Luego de arrancar, también lo he cambiado en el fichero /etc/default/grub, que son los parámetros que usa update-grub.
Asi que sigo con el 2.6.24-11-pve. Mas vale lo malo conocido ...
luis_sanz
22/09/2010, 15:12
Publicado inicialmente por kro
funciona, perfectamente.
Muchas gracias.
Código:
pveversion -v pve-manager: 1.6-2 (pve-manager/1.6/5087) running kernel: 2.6.32-4-pve proxmox-ve-2.6.32: 1.6-19 pve-kernel-2.6.32-3-pve: 2.6.32-14 pve-kernel-2.6.32-4-pve: 2.6.32-19 qemu-server: 1.1-18 pve-firmware: 1.0-8 libpve-storage-perl: 1.0-14 vncterm: 0.9-2 vzctl: 3.0.24-1pve4 vzdump: 1.2-7 vzprocps: 2.0.11-1dso2 vzquota: 3.0.11-1dso1 pve-qemu-kvm: 0.12.5-1 ksm-control-daemon: 1.0-4
PacoSS
22/09/2010, 15:09
Félix enrróllate y déjame un EG, que os hago un kernel que va a salir el pc corriendo del rack para afuera.
a-n-t-o-n-i-o
22/09/2010, 15:04
yo nunca he conseguido actualizar un kernel en proxomox de OVH, la solucion FACIL a esto pasa por esperar a que OVH añada el nuevo kernel al proxmox que instala y volver a reinstalar el servidor.
el problema es que no encuentro forma de saber cuando modifican algo en las distros que hay en el manager, por lo que no hay forma de conocer cuando estara disponible el nuevo kernel, toca reinstalar un par de semanas depues de salir el kernel y probar suerte.
el problema es que no encuentro forma de saber cuando modifican algo en las distros que hay en el manager, por lo que no hay forma de conocer cuando estara disponible el nuevo kernel, toca reinstalar un par de semanas depues de salir el kernel y probar suerte.
kro
22/09/2010, 15:04
luis_sanz wrote:
> he tenido que hacer
> apt-get -y install pve-headers-2.6.32-4-pve
> apt-get -y install proxmox-ve-2.6.32
+ update-grub
> para iniciar la actualizacion.
--
Felix
OVH Team
> he tenido que hacer
> apt-get -y install pve-headers-2.6.32-4-pve
> apt-get -y install proxmox-ve-2.6.32
+ update-grub
> para iniciar la actualizacion.
--
Felix
OVH Team
PacoSS
22/09/2010, 14:53
Me voy a tener que tomar ya en serio el tema este. Solo está instado grub, y no existe el fichedro menu.lst que tiene la configuración.
En otro orden de cosas, me gustaría hacer un kernel monolítico (sin módulos) para mi EG, si alguien deja uno, no lo esta usando, ... me pongo en contacto con él para hacerlo. Son cien reinicios, cuelgues, ... Aunque mas de una vez me ha salido a la tercera.
El porque es para disminuir el "TLB pressure", los ciclos CPU necesarios para acceder a la paginación de memoria y la virtualización. También el consumo de memoria suele ser menor (algunos kb, nada del otro mundo).
En otro orden de cosas, me gustaría hacer un kernel monolítico (sin módulos) para mi EG, si alguien deja uno, no lo esta usando, ... me pongo en contacto con él para hacerlo. Son cien reinicios, cuelgues, ... Aunque mas de una vez me ha salido a la tercera.
El porque es para disminuir el "TLB pressure", los ciclos CPU necesarios para acceder a la paginación de memoria y la virtualización. También el consumo de memoria suele ser menor (algunos kb, nada del otro mundo).
luis_sanz
22/09/2010, 12:36
mmm pues a mi no me sale ni rastro del 2.6.32-4 usando aptitude update && aptitude dist-upgrade
he tenido que hacer
apt-get -y install pve-headers-2.6.32-4-pve
apt-get -y install proxmox-ve-2.6.32
para iniciar la actualizacion.
una vez reiniciado el servidor, sigue estando con la version 2.6.32-3, por lo que ocurre exactamente igual que antes, haber si alguno sabe como pasar al nuevo una vez descargado
he tenido que hacer
apt-get -y install pve-headers-2.6.32-4-pve
apt-get -y install proxmox-ve-2.6.32
para iniciar la actualizacion.
una vez reiniciado el servidor, sigue estando con la version 2.6.32-3, por lo que ocurre exactamente igual que antes, haber si alguno sabe como pasar al nuevo una vez descargado
Código:
pveversion -v pve-manager: 1.6-2 (pve-manager/1.6/5087) running kernel: 2.6.32-3-pve proxmox-ve-2.6.32: 1.6-19 pve-kernel-2.6.32-3-pve: 2.6.32-14 pve-kernel-2.6.32-4-pve: 2.6.32-19 qemu-server: 1.1-18 pve-firmware: 1.0-8 libpve-storage-perl: 1.0-14 vncterm: 0.9-2 vzctl: 3.0.24-1pve4 vzdump: 1.2-7 vzprocps: 2.0.11-1dso2 vzquota: 3.0.11-1dso1 pve-qemu-kvm: 0.12.5-1 ksm-control-daemon: 1.0-4
Código:
/boot# dir config-2.6.32-3-pve initrd.img-2.6.32-3-pve.bak vmlinuz-2.6.32-3-pve config-2.6.32-4-pve initrd.img-2.6.32-4-pve vmlinuz-2.6.32-4-pve grub System.map-2.6.32-3-pve initrd.img-2.6.32-3-pve System.map-2.6.32-4-pve
luis_sanz
22/09/2010, 12:14
Publicado inicialmente por PacoSS
al actualizar y reiniciar no cogia nunca el nuevo kernel.
voy a probar a ver que ocurre en esta ocasion con un server que uso solo para backups y comento
chencho
22/09/2010, 09:49
Terror me da actualizar el kernel...
PacoSS
22/09/2010, 08:34
Ayer publicaron el parche y está en los repositorios.
Según la web de Proxmox-VE:
aptitude update
aptitude upgrade
aptitude install proxmox-ve-2.6.32
En vez de eso, yo he actualizado todo (debian incl) por si acaso:
aptitude update && aptitude dist-upgrade
Y el efecto ha sido el mismo, ha borrado el proxmox-ve-2.6.32-3 e instalado el nuevo.
*El server está en producción y no puedo reiniciarlo hasta la madrugada, asi que no lo he testeado de funcionamiento y vulnerabilidad aún*
Según la web de Proxmox-VE:
aptitude update
aptitude upgrade
aptitude install proxmox-ve-2.6.32
En vez de eso, yo he actualizado todo (debian incl) por si acaso:
aptitude update && aptitude dist-upgrade
Y el efecto ha sido el mismo, ha borrado el proxmox-ve-2.6.32-3 e instalado el nuevo.
*El server está en producción y no puedo reiniciarlo hasta la madrugada, asi que no lo he testeado de funcionamiento y vulnerabilidad aún*