tags/xen

reclamando-memoria-en-xen

2009-01-22T04:24:04Z

Desde hace casi dos semanas que estoy probando hacer el upgrade de un servidor de Sarge a Etch. Como todo servidor que se precie, no puede quedar nada mirando el techo, así que la solución obvia era hacer una copia para virtualizarlo y probar allí. La herremienta seleccionada fue xen, porque ya estoy bastante ducho con ella.

La cuestión es que mi máquina con xen "sólo" tiene 768MiB de RAM, y como estaba haciendo upgrades y otras yerbas consumidoras de memoria, mi dom0, que corre mi escritorio, terminó con apenas 128MiB de RAM. Mi escritorio KDE se arrastraba un poco, con mucho swapping, así que una vez terminada la parte que se morfaba todo decidí bajar el domU con el server y reclamar un poco de memoria para el dom0:

$ sudo xm mem-set 0 256

Esto mágicamente duplicó la memoria de mi dom0! No sabía de estas capacidades de xm, lo cual me llevó a leer su manpage. Interesante las cosas de las que es capaz; en particular me llamó la atención que se puede leer el kernel buffer (lo que escupe dmesg) de un domU desde el dom0 y los schedulers de cpu, de los que lamentablemente sólo hay uno por ahora.

sysadmin xen

hosting-humitos

2009-01-22T04:24:04Z

ayer le ofrecí hosting para sus proyectos a humitos. el iluso cayó rápido, sobre todo después de que probó cómo anda svn desde su casa bajando las fuentes de kreissy.

para ofrecerle este servicio le creé una cuenta en mi máquina y lo dejé hacer lo que le parezca, como ya he hecho con otra gente (por ejemplo, mi máquina es un ssh gateway paara alguna gente que se queda detrás del firewaal de la facu, pues tiene corriendo el ssh en el 443, que si está abierto).

como mi máquina es un debian sid, y éste suele sacudir los paquetes de vez en cuando (ya con el desarrollo de kreissy me mordió el cambio de SQLAlchemy, saltando de la 0.3.x a la 0.4.x, que tienen APIs sutilmente incompatibles), se me ocurrió levantar una instancia xen que ya tenía tirada por ahí. les cuento.

hace poco más de un mes nueces trajo su desktop que estaba juntando en un rincón de su pieza y, poniendo uno de los dos discos que tengo, pusimos un debian unstable, al cual convertimos en el dom0 de un xen que corrió dos instancias xen, una para él y otra para mí. la mía corría un debian etch directamente de mi disco, por las dudas en algún momento él se tuviera que llevar la máquina.

y ese momento llegó hace una semana: la vendió. me devolvió mi disco, que terminó de nuevo en mi máquina. lo monté como lo ten;ia antes y todos contentos.

entonces, hoy instalé un kernel xen. como esto es un debian sis, y no hay kernels con xen más arriba del 2.6.18, y sid ya corre 2.6.22 (para cuándo el .23?!?), tuve que bajar los paquetes linux-image-2.6.18-5-xen-6862.6.18.dfsg.1-13i386.deb y linux-modules-2.6.18-5-xen-6862.6.18.dfsg.1-13i386.deb a mano e instalarlos a mano. para instalarlos usé dpkg a lo macho, pero bien podría haber usado gdebi. configuré grub un poco a mano y reinicié.

hace mucho que uso debian, y desde hace mucho que uso kelmers compilados específicamente para mi hw (he notado que en máquinas chicas eso aumenta bastante la velocidad, así porqué no aplicar un poco la filosofía gentoo en este caso?). el tema es que estuve un rato reconfigurando algunas cosas para que anden con cómo levantó el kernel genérico algunas cosas (red y soporte de IDE en vez de PATA). sé que esas cosas se pueden arreglar con udev, pero la verdad es que siempre me llevé medio mal con él y ahora no tenía tiempo de revisarlo.

cuestión que después de un par de toqueteos levantó sin más problemas. me restregué las manos, creé el archivo de configuración de la instancia xen, y disparé un xm create. para asegurarme que estaba todo bien, con xm console luxury me ataché a la consola del domU. ésta felizmente me mostró cómo arrancó todo el sistema hasta que llegó el momento de correr /sbin/init. entonces es cuando no hizo más que imprimir:

request_module: runaway loop modprobe binfmt-464c

y nada más. buscando encontré referencias que no entendía, hasta que me cayó la ficha: la máquina de nueces era una amd64, y la instancia xen estaba en esa arquitectura. acá tengo un athlon xp 2600+, que es i386. el loco se negaba a correr soft compilado para 64 bits.

en fin. humitos empezó a subir sus cosas a su home en el dom0. ya después veré si migro eso a una máquina aparte o no. también estuvimos jugando con svk y svnadmin.

xen debian sysadmin

presentando-xarope

2009-01-22T04:24:04Z

en la oficina laburamos mucho con Zope y Plone. es la tecnología que mas clientes concentra y en la que mas gente especializada tenemos. un problema que surge de usar estas bestias es que no es fácil encontrar hosting que los soporte, mucho menos barato, cosa que se encuentra hasta debajo de las baldosas para LAMP. se puede especular largo y tendido sobre los porqués, pero la cuestión es que esto es cierto.

Como un plan para remediar esto, y tal vez sacar unos mangos en el camino, es que decidimos crear Xarope y Caroteno. Caroteno es un servicio de hosting Zope/Plone barato y Xarope es la herramienta que nos permitirá conseguirlo, utilizandon alguna tecnología de virtualización.

la idea de Xarope es que sea, por un lado, un instalador que sea capaz de convertir un servidor cualquiera en un servidor de hosting, y por otro, en una herramenienta para administrar las máquinas virtuales.

Hoy (por anteayer), después de un par de meses de desarrollo, hemos lanzado el primer release de Xarope. El instalador está casi enteramente hecho en bash, mientras que la herramienta de administración está casi toda hecha en python. Por debajo usamos xen y apache. más detalles en la página del proyecto.

en cuanto a Caroteno, tenemos el servicio andando desde hace algo así como un mes. más información en beta.caroteno.com.

xarope xen python