miércoles, 24 de octubre de 2012

RHEV/OVIRT API with Python

RHEV/OVIRT api allows faster and simple development of scripts / utilities ranging from gathering of information to VM/host, etc manipulation.

For example,a  simple script for connecting to API and list VM's could be:

import sys
import getopt
import optparse
import os
import time
 
from ovirtsdk.api import API
from ovirtsdk.xml import params
from random import choice

baseurl = "https://localhost:8443"
api = API(url=baseurl, username="admin@internal",password="redhat",insecure=True)
for vm in api.vms.list():
  print vm.name


The .list() method works pretty well, but beware, it limits collections to 100 elements for performance reasons, so in those cases, we'll need to check how many results do we have, and paginate by passing an extra argument to our ".list()" invocation, for example:
<br>for vm in api.vms.list(query="page 1")


Furthermore, we can check the number of results by using:

<br>len(api.vms.list(query="page 1"))


And playing together, we could set a list that returns all results by running:

<br>vms = []<br>page = 0<br>length = 100<br>while (length > 0):<br>  page = page + 1<br>  query = "%s page %s" % (oquery, page)<br>  tanda = api.vms.list(query=query)<br>  length = len(tanda)<br>  for vm in tanda:<br>    vms.append(vm)


We can also make funny things like migrate VM's to another host by just running:

<br>vm.migrate()


It's expected for RHEV 3.1 to have a developer guide (now in Beta) at https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1-Beta/html-single/Developer_Guide/index.html

Check it for more examples of use and put the Virtualization to work for you!

jueves, 8 de diciembre de 2011

Herramientas de sincronización/backup

Hace tiempo, estuve buscando una forma de simplificar por un lado, la sincronización de los documentos, fotos, etc entre diversos ordenadores y por otro utilizar esa copia en otros equipos a modo de 'backup' en caso de fallo hardware de algún equipo.

Estuve probando y evaluando diversas herramientas multiplataforma y junto a algunas más, las que más probé fueron estas:

Actualmente necesito 'salvar/sincronizar' unos 35Gb de datos (fotos la gran mayoría y no precisamente en RAW), lo que provocó estas comparativas, preferiblemente de servicios que ofrecieran espacio gratuito.

En resumen, de las opensource (Syncany/Sparkleshare), están todavía bastante en pañales, aunque prometen mucho, más syncany por la variedad de posibles destinos de copias que sparkleshare (necesidad de repositorio git, etc).

De las 'comerciales', Wuala ofrecía posibilidad de compartir espacio local a cambio de espacio en la nube que permitía compartir esos GB  no utilizados por GB fuera de donde tenías tus ordenadores, garantizando que en caso de problemas fisicos, ambientales,etc, poder acceder a los datos, pero en Octubre de 2011, con la salida de la nueva versión, dejaron de ofrecer el servicio, convirtiendo el espacio conseguido en un 'vale' hasta Octubre de 2012... que ha provocado que tenga que reemplazar esa solución que venía utilizando.

Dropbox, a pesar de los referrals y de cuenta de email ".edu", no ofrece más de 16 Gb a no ser que sean planes de pago, que por ahora la deja fuera (además del hecho de no permitir especificar clave de cifrado de los datos, que por otro lado aporta que si alguien había subido el fichero antes, la subida es instantánea).

SpiderOak ofrece menos espacio (pero parte de 5Gb y ahora es posible subir hasta 50Gb por referrals), tiene repositorio para yum para las actualizaciones y se puede ejecutar tanto en modo 'GUI' como en línea de comandos (por contra la sincronización se lanza cada x tiempo, no parece tan fluida como Dropbox).

AeroFS: una recién llegada, que sigue en versión alpha, basada en Java, multiplataforma (EL6 o superior) y que no ofrece de 'salida' espacio online, simplemente la sincronización entre tus equipos, pudiendo hacer  cambios en cualquiera de ellos y luego sincronizándolos entre sí, incluso sin conectividad a Internet (sólo hace falta internet para dar de alta una carpeta nueva en un equipo o dar de alta un equipo (para sincronización de autorizaciones con el servidor de Aerofs)).


Actualmente AeroFS es la que más promete por no limitar el espacio excepto al que dispongas en tus equipos, pero con mi colección de documentos y 4 equipos a la vez he tenido problemas de ficheros renombrados "terminados con números entre paréntesis", sincronizaciones lentas (utilizar un interfaz vía hamachi en lugar del interfaz de red local), no sincronización de enlaces simbólicos y destrucción de ficheros con enlaces duros (deja sólo una copia), pero es la única que cubre por ahora mis necesidades con respecto a lo que hacía wuala (a excepción de no tener aplicaciones para móvil y claro está, no funcionar si ningún equipo con los datos está conectado).

De como evolucionen syncany y aerofs de aquí a octubre, decidirá si escojo una de estas dos o sigo evaluando alternativas para los backups... por ahora sigo con Dropbox para cosas rápidas que no necesito excesiva privacidad y para el resto Wuala y he añadido duplicity para hacer backup a un NAS en mi red local a la espera de ir probando mejor AeroFS y ver cómo respira syncany...

Probando nuevos escritorios

Hace ya años que pasé de KDE con la llegada de KDE 3 a utilizar GNOME, más 'espartano', pero con mejor rendimiento.

Con Fedora 15 pasé a utilizar GNOME 3, bastante 'innovador', algo extraño, pero me fui acostumbrando relativamente bien, pero con la llegada de Fedora 16 y la versión 3.2, noto el equipo (que sigue siendo el mismo) con frecuentes enganchones y lentitud.

Una opción sería subir los 2Gb de memoria a 4Gb, pero me parece tirar dinero cuando el equipo necesitaría una renovación durante el próximo año (P4 dual 2.8 Ghz del año 2004).

Así que me he animado, primero con XFCE, que va mejor, pero lo sigo notando lento de respuesta y por ahora con LXDE, de entorno muy parecido a GNOME 2.x, rápido, con iconos en el escritorio, etc, pero con alguna pega.

Mejora:
  • Velocidad
  • Iconos en el escritorio
  • Velocidad del terminal, tanto en XFCE como en LXDE con respecto a gnome-terminal y combinaciones de teclas muy parecidas para nuevas pestañas, etc
Empeora:
  • El gestor de ficheros no ordena alfabéticamente de forma correcta
  • La configuración de algunos aspectos como combinaciones de teclas para bloquear entorno deben hacerse con un editor de ficheros
  • Echo en falta el 'exposé' de GNOME3 ahora que me había acostumbrado
  • A veces el alt-f2 abre el diálogo de ejecutar por detrás de la ventana activa y toca usar alt-tab para ponerlo en primer plano.

Por ahora voy a seguir con LXDE en dos equipos y ver si finalmente lo pongo en todos o busco alguna alternativa más.

lunes, 27 de junio de 2011

duplicity for managing backups

A few days ago, I was checking a friend's system for backing up.

It was based on rsync on the linux side and rsync server on a windows machine he uses for storing information generated by other software.

Rsync worked pretty well for him until he started to put several strange characters in filenames which rendered the backup unusable to certain point.

After being asked for alternative backup software that was available on several platforms, I've ended testing duplicity.

As a command line interface tool, it can run pretty well on cron jobs, and eases the management of doing full or incremental backups to several kinds of targets.

Duplicity can also take care of tiding backup store removing older backups and automatically perform a full backup if older than x time, so you can automate the full backup management.

Best of all is the backend support, as you can do backups over rsync, scp, ftp, file, imap, ssh, amazon, webdav, etc , so you can use that old NAS to store your backups without any special support except pretty standard protocols even on low-end models.

lunes, 7 de marzo de 2011

Firsts steps with Fedora 15 pre-alpha

Today I've decided to give it a try to F15-prealpha (expected to release tomorrow).

The upgrade performed in the unsupported way (getting and forcing install for newer fedora-release from a mirror then start issuing several yum upgrades) when reasonably good.

Only some minor dependency problems et voilà, system started fine.

Problems so far:
- Firefox 4 has a few approved extensions, I used the "nightly tester tools" to disable version check and enable most of the ones I had with 3.6.x without problems.
- Don't like gnome-shell at the moment
- Desktop icons disappeared...
- Menu bar is black and found no way to configure it yet
- Gnome-applets have some dependency problems and can't install or configure them, furthermore I lost my tray area on one of the computers but works fine on the other.


I hope that tomorrow's release of Alpha will fix some of them in order to warm-up for final launch (http://fedoraproject.org/wiki/Releases/15/Schedule)...

Update: wed 09/03/2011:
After 'Alpha' release:
- Like a bit more gnome-shell, but sometimes my desktop starts in compatibility (legacy) mode
- Active corners (upper left: show windows, favorites, search for apps, lower right: show tray)
- with empathy, notifications of new chats in bottom center of screen that let you answer in that area (but then if you open the window, it will 'random sort' the messages you wrote/received
- GDM will not allow you to login (there's an update on koji that updates accountservice that got possitive karma today and will be pushed to updates repo)
- Under your user name in gnome-shell, there's no 'power off', just 'suspend' but that gets my desktop computer powered off in seconds, and the best of all, started again in seconds (and my computer is an Athlon 64 3Ghz with 2Gb ram from 2004) (http://www.youtube.com/watch?v=xPRh1NvOhqI)
- Still missing desktop icons
- Still missing gnome-applets :'(

Update Wed 16/Mar/2011
- Still missing desktop icons /gnome-applets
- Sometimes gdm doesn't show usernames, but you can enter username/password
- Evolution has a good integration with google services (contacts/calendar/gmail) so you can use it as an offline client
- Some bugs opened on BZ, but still more than 15 days for 'Beta', and a very good ratio of fixes :)


Will keep updating this post with newer information!

lunes, 26 de abril de 2010

Rescate de sistemas virtuales (Xen)

A raíz de un problema debido a reiterados apagones, me vi en la necesidad de levantar una máquina virtual que ya no arrancaba.

En un sistema físico, lo que haríamos, es que según en qué punto estemos, usar un disco de arranque de nuestra distribución y por un lado reparar el sistema de ficheros con fsck o rehacer un initrd.img.

¿Cómo hacemos esto si la máquina en lugar de ser una real, es una virtual?.

Copiando el fichero de configuración de nuestra máquina a 'rescate', podemos editar la línea del cargador (eliminando pygrub) e indicando como kernel e initrd.img los de nuestro cd de distribución (en el caso de Xen, images/xen para EL5).

Una vez arrancado, ya podemos seguir el procedimiento estándar de recuperación.

En el caso de tener que reconstruir el initrd, podemos tener un problema añadido, pero por otro lado, al ser todo máquinas virtuales 'con el mismo hardware', es muy sencillo crear otra máquina virtual e instalarla indicando los mismos nombres para los vg's, particiones de arranque, etc y luego copiar el initrd.img y el kernel de la máquina nueva a la antigua y arrancarla, para llegados a este punto, reinstalar la última versión del kernel disponible con nuestro sistema ya arrancado.

La copia la podemos hacer bien desde el medio de rescate o montando mediante loopback el fichero de la máquina virtual (con LVM's es trivial) (puedes encontrar mucha información al respecto buscando por xen image y loopback offset).

jueves, 15 de abril de 2010

Crear pendrives de arranque (flasheo de bios) en un ejecutable autoextraible (Linux/Windows)

Usando unetbootin (http://unetbootin.sourceforge.net/) podemos crear pendrives de arranque a partir de imágenes ISO o imágenes de disco, así como ficheros propios o bien predefinidos para varias distribuciones.

Si queremos además, crear un fichero ejecutable autodescomprimible, para que el usuario final sólo deba ejecutarlo e introducir un pendrive y que se cree 'solo', deberemos tener además:

- 7zip http://sourceforge.net/projects/sevenzip/files/ (para crear un fichero comprimido con los ficheros a incluir)
- 7zip SFX (7zS.sfx) dentro del fichero 'Extra' de http://sourceforge.net/projects/sevenzip/files/

En una carpeta, copiaremos el ejecutable de unetbootin al que llamaremos unetbootin.exe , añadiremos el fichero 7z.sfx y la imagen de flasheo BIOS a la que llamaremos flash.img.

Yo añado también un fichero 'syslinux.cfg' que desactiva la linea vesamenu.c32 que pone por defecto unedbootin, quedando:


---------- syslinux.cfg --------------
default unetbootindefault
prompt 0
menu title UNetbootin
timeout 100

label unetbootindefault
menu label Default
kernel /ubnkern
append initrd=/ubninit
-----------------------------------------


Con 7zip comprimiremos los ficheros 'flash.img' , 'syslinux.cfg' y 'unedbootin.exe' a un fichero llamado todo.7z

Crearemos un fichero 'config.txt con las órdenes a ejecutar, por ejemplo


------------------- config.txt ----------------
!@Install@!UTF-8!

RunProgram="unetbootin.exe lang=es method=diskimage imgfile='flash.img' cfgfile='syslinux.cfg' nocustom=y nodistro=y message='Presione OK para generar Pendrive de Flasheo BIOS' installtype=USB"

!@InstallEnd@
-------------------------------------------------



Puedes consultar la referencia de comandos en http://sourceforge.net/apps/trac/unetbootin/wiki/commands

Los que hay indicados, ponen el idioma en castellano, indica que usaremos una imagen de disco que está en el fichero 'flash.img', usaremos el fichero de menu 'syslinux.cfg', no permitiremos personalizar la creación, no dejaremos escoger distribución, definimos el mensaje a mostrar y crearemos un medio USB

En el paso final, debemos concatenar los ficheros en un único ejecutable


cat 7zS.sfx config.txt todo7z > autoejecutable.exe


Cuando enviemos el fichero 'autoejecutable.exe' a un usuario, al ejecutarlo, se descomprimirá el fichero 'todo.7z' contenido dentro del ejecutable y se lanzará la línea de comando del 'config.txt', lanzando unetbootin para la creación....

Podemos utilizar este método (sin hacer el autoejecutable), para crear un pendrive de arranque de forma manual y poder actualizar nuestra bios, etc.