Archivo de la categoría: Linuxadas

MacOS Xen: Snow Leopard as guest on a Xen domU

Some days ago I started trying to get MacOS X to run as a virtual machine on Xen. After all if the OSx86 guys are getting it to run on normal PC hardware, why not on virtual hardware?

There’s not much info available and most of them is incomplete. The more accurate sites I could find were:

Some notes:

  • I’m using Debian Squeeze with the bundled Xen 4.0 for the hypervisor and the dom0. The server si a cheap (~300€) PC with a DualCore E5700 @3Ghz and 4Gb of RAM. Other versions of Xen may need different options or have a slightly different config file syntax.
  • I assume you already know how to configure a Xen domU, access it through Xen’s built-in VNC server, etc.
  • Instead of using the original Snow Leopard DVD and then patching like here, I’m taking the easy road using iATKOS S3 v2 which is already upgraded to 10.6.3 and bundles several the OSx86 patches.

My /etc/xen/hackosx.cfg file is a mix of those on the previously mentioned pages:

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 512
device_model='/usr/lib64/xen/bin/qemu-dm'

name = "hackosx"
#vcpus=1
pae=1
acpi=1
apic=1
#HPET=1
#timer_mode=0
#vpt_align=0
#vcpus_avail=1
#localtime=1
NE2000=0

vif = [ 'type=ioemu,ip=192.168.10.10,bridge=xenbr0' ]
disk = [
        'phy:/dev/mapper/xen-hackosx_hd,ioemu:hda,w',
        'file:/root/iATKOS_S3v2.iso,hdc:cdrom,r',
  ]

# first boot from disk, then from cd if that fails
boot="cd"
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=1
vncconsole=0
vncunused=1
vncpasswd='pass'

stdvga=1
serial='pty'
monitor=1

Fix the path to the HD image file/dev and the iATKOS ISO if you need.

So, let’s begin:

  • On the dom0 run “xen create /etc/xen/hackosx.cfg” and access it via VNC.
  • Run Disk Utility and partition the virtual HD. Return to the installer.
  • On the screen where you select the destination HD, click the customize button on the bottom left. Besides the default options (on the screenshot) I also selected the following (NOT on the screenshot and NEEDED for OS X to run on Xen):
    • Patches->Modified Kernels->qoopz 10.3.0
    • Drivers->Main Hardware->SATA/IDE->Intel SATA/IDE
    • Drivers->Main Hardware->PS/2->Apple PS/2
    • Drivers->Network->Wired->Realtek->RTL8139

    iATKOS default options

  • Continue with the installation.

The installer proceeds normally until the end. In my case it gets stuck in “Remaining time: 8 minutes approx.” so after a while seeing the progress bar not… well… progressing, I went to the dom0 and restarted the virtual machine. Note: I had to re-install several times until I got the right options and the installer hanged for me at that point always.

Despite the unfinished installation, access again the VM after restarting it with VNC. This time you’ll see the usual OS X 1st time wizard configuring the language, time zone, user account, etc. Yay!

Now, on to the upgrade to 10.6.6:

If everything worked as expected, now you’re running MacOS X Snow Leopard updated to 10.6.6 on a Xen domU. o/

Some additional details:

  • Network performance with the default OS X RTL-8139 driver is TERRIBLE (at least right after installing iATKOS, before upgrading to 10.6.6). Follow these instructions to replace it.
  • If you go to apple menu on the upper left corner and then “About this Mac”, the Finder restarts and you don’t get the About window. :-/ Nevertheless the system is upgraded: “uname -r” says 10.6.0 (same as in my MacBook Pro) and the App Store is installed.
  • Run Software Update. There’s a Safari update, a Java one and an iTunes one. ;-) (yes, Software Update works and these upgrades don’t break any of the MultiBeast patching).
  • Install VineServer (it’s free). Is a much better VNC server than the one integrated in Xen and more compatible/standard than the one bundled in OS X.
  • Disable power saving in System Preferences -> Energy Saver. When the virtual OS goes into power saving I don’t know how to wake it, you can VNC to it but it’s completely unresponsive. Maybe there’s a fix, iATKOS and/or MultiBeast have a fix for power saving (not for Xen of course, but maybe it helps) and Xen’s config seems to have some options for power management.

Enjoy. :-)

March 23th update: Apple released the MacOS X 10.6.7 upgrade yesterday. I’ve just tried to install it through Software Update and it works. No need to run MultiBeast even.

Resolución de Xorg en un cliente (domU) Xen

[spanish]

Al instalar Linux como cliente Xen en un domU y activar el acceso por VNC, con un poco de suerte todo funciona salvo que no se puede cambiar la resolución del sistema. Hagas lo que hagas (a través de los menús, editando el xorg.conf) parece que sólo se puede usar la resolución 800×600.

Después de buscar un rato en Google dí con este correo que comenta una nueva opción extra=”xenfb.videomem=5,1024 “ para configurar la memoria RAM de vídeo del cliente, y por tanto las resoluciones soportadas. Lo probé pero no funcionó. Investigando más en ésta línea averigüé que esta opción “extra” de la configuración de Xen sirve para pasarle parámetros adicionales al kernel del sistema cliente, así que ese “xenfb” debía ser un módulo del kernel. Buscando en mi cliente Ubuntu módulos llamados *xen* dí con “xen-fbfront”:

$ modinfo xen-fbfront
filename:       /lib/modules/2.6.35-24-generic/kernel/drivers/video/xen-fbfront.ko
alias:          xen:vfb
license:        GPL
description:    Xen virtual framebuffer device frontend
srcversion:     0EB34742ACF8D2559403034
depends:        fb_sys_fops,syscopyarea,sysfillrect,sysimgblt
vermagic:       2.6.35-24-generic SMP mod_unload modversions
parm:           video:Video memory size in MB, width, height in pixels (default 2,800,600) (array of int)

Así que parece que en algún momento del desarrollo, se renombraron tanto el módulo como la opción para indicar la memoria, pero la idea básica era la misma. Lo probé, ¡y funcionó!

Así que en resumen, lo que hay que hacer es añadir al fichero de configuración del domU (/etc/xenDOMAIN.conf) en el dom0 la siguiente línea, ajustando los parámetros de memoria y resolución al gusto:

extra="xen_fbfront.video=4,1024,768 "

[/spanish][english]When installing a Linux system as a Xen guest on a domU and activating the VNC access, hopefully everything runs fine except that you can’t change the resolution. No matter what you do (through the GUI, editing the xorg.conf file) it seems all it can do is 800×600.

After googling for a solution I stumbled upon this post which commented on a new extra=”xenfb.videomem=5,1024 “ option for dealing with guest video RAM (and thus, supported resolutions). But it didn’t worked out. Digging deeper on this approach I realized this “extra” Xen configuration was used for passing extra parameters to the guest’s kernel, so this “xenfb” should be a module on the guest OS. Then I looked for *xen* modules on my Ubuntu guest and found “xen-fbfront”:

$ modinfo xen-fbfront
filename:       /lib/modules/2.6.35-24-generic/kernel/drivers/video/xen-fbfront.ko
alias:          xen:vfb
license:        GPL
description:    Xen virtual framebuffer device frontend
srcversion:     0EB34742ACF8D2559403034
depends:        fb_sys_fops,syscopyarea,sysfillrect,sysimgblt
vermagic:       2.6.35-24-generic SMP mod_unload modversions
parm:           video:Video memory size in MB, width, height in pixels (default 2,800,600) (array of int)

So it looks like the module and the option got renamed along the way. Tried it, and it worked!

So, all in all, what you need to add is this line to your domU config file (/etc/xenDOMAIN.conf) on the dom0, adjusting memory and resolution parameters at will:

extra="xen_fbfront.video=4,1024,768 "

[/english]

kpartx: Montar las particiones de un archivo imagen de disco

[spanish]A veces resulta útil poder montar las particiones de un archivo con la imagen completa de un disco, por ejemplo de un programa de backup (o un dd) o de una máquina virtual, sin tener que recurrir a ese software de backup o VM. Estos ficheros normalmente son una copia bit a bit de lo que debería haber en el disco real, por lo que el formato interno tanto de la tabla de particiones como de las particiones en sí son los normales que el sistema entiende y debería poder utilizarlos. El único problema es que ni la imagen ni las particiones están accesibles a través de un fichero de dispositivo de bloques en /dev para poderlas montar.

kpartx es un pequeño programa que hace precisamente eso, detecta las particiones que pueda haber en una imagen de disco y genera en /dev los mapeos necesarios para poder montarlas como si fueran particiones en un disco real. Es muy sencillo de usar: se le pasa el nombre del fichero y muestra la lista de particiones. Si se le añade el parámetro -a crea los dispositivos; si -d, los borra. mount.

Vaya mi agradecimiento a esta página, que es donde he sabido de la existencia de kpartx. Además ahí explican cómo hacer lo mismo pero a mano, detectar los inicios de cada partición y utilizar el “loop device” para acceder a ellas y montarlas.[/spanish][english]Sometimes it is useful to mount the partitions in a disk image file, e.g. from a backup (or dd) or a virtual machine, without having to use that backup or VM software. These files are usually a 1:1 copy of what should be on an actual disk, so the internal partition table format is the same the operating system would use on a disk and also the format of the partitions themselves are ext2/3/FAT/whatever. So the system should be able to use them, the only problem is that neither this image file nor its partitions are mapped to proper block device files in /dev.

Enter kpartx, a small utility that analyzes a disk image file, detects the partitions in it and creates device files for each partition, so that they can be mounted as if they were real partitions on a physical disk. Usage is very simple: just pass the file to it and kpartx shows the partition table. Add the -a parameter to that and kpartx creates the device files; -d and it deletes them. mount.

Kudos to this page where I learnt about kpartx, and which by the way explains a way to manually map the partitions using the loopback interface. [/english]

Imágenes en "negativo" tras escalar con ImageMagick

Un apunte rápido de una cosa que solucioné en el trabajo hace unas semanas y desde entonces he visto en otro par de sitios.

Al escalar imágenes con el convert de ImageMagick (o con alguna de sus API) algunas fotos se quedan como en negativo: tonos negros, verdes oscuro, etc. aunque por supuesto la imagen original se ve bien. Después de darle vueltas el “problema” con estas imágenes es que el color iba codificado en CMYK en lugar de RGB, y por lo visto ImageMagick en el escalado por defecto usa RGB como salida y no realiza la conversión necesaria.

Solución rápida: antes de escalar las imágenes, pasarlas a RGB con:


convert -colorspace rgb original.jpg rgb.jpg

En medios exclusivamente digitales es difícil que esto pase, ya que para imágenes en pantalla se usa RGB. Sin embargo en medios que trabajen también con papel (prensa, editoriales, publicidad) es más fácil porque CMYK es el modelo que se usa para imprimir, y es posible que alguna foto en este formato pase inadvertidamente a la versión digital del medio.