I am working now on Ubuntu Karmic Koala.

As I said in my previous post, Qemu is a complete platform emulator that can emulate the Integrator ARM machine platform (CPU and devices!).

In Karmic Koala the latests Qemu version (0.11.0) is shipped within Ubuntu repositories so with this line we can install it:

# sudo apt-get install qemu qemu-kvm qemu-kvm-extras

ARM test images

From the Qemu home page we can download a Linux 2.6 ARM example image builded by Paul Brook and extracting it in $PRJROOT/images, we can find the README file where it is written how to launch the test platform:

# cp DownloadDirectory/arm-test-0.2.tar.gz $PRJROOT/images
# cd $PRJROOT/images
# tar -xvf arm-test-0.2.tar.gz
# cd arm-test
# cat README

So, with or without the graphical interface we can test the qemu arm installation with the followings:

# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img
or
# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \
  -nographic -append "console=ttyAMA0"

A suitable Linux config file

Over the test purpose , executing the test image can give the kernel configuration file stored in /proc/config.gz ! so:

# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \
  -nographic -append "console=ttyAMA0"
Uncompressing Linux...............................................
........................... done, booting the kernel.
Linux version 2.6.17-rc3 (paul@wren) (gcc version 4.1.0 (CodeSourcery ARM))
 #53 Thu May 4 15:05:18 BST 2006
CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
Machine: ARM-IntegratorCP
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-through cache
CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets
CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets
Built 1 zonelists
Kernel command line: console=ttyAMA0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total

...

Log in as root with no password.
qemu login: root
# cp /proc/config.gz .
# tar -xvf config.gz
# vi config.gz

With this file we can configure the mainline linux kernel! (copying from screen, copying within net, scrolling the options with a near mainline make menuconfig window).

ARMv5te Toolchain to build the kernel

The machine emulated by qemu-arm is based on the core ARMv5te , so I need the correct toolchain for build all the necessary code.

The Pengutronix OSELAS environment can do that in the OSELAS toolchain project. Similarly at what described in Initializing a Linux Embedded Development Host Machine moving in $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/ we can select the suitable ptxdist configs with:

# cd $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/
# ls ptxconfigs/
arm-1136jfs-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig
arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig.old
arm-cortexa8-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
armeb-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
armeb-xscale-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
...
arm-v4t-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-v4t-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-v5te-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-v5te_vfp-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-xscale-linux-gnueabi_gcc-4.2.3_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
...
# ptxdist select ptxconfigs/\
  arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
# ptxdist menuconfig

In the menuconfig, all can live as it is but in “misc->prefix for installation” we can choose $PRJROOT/tools where $PRJROOT must be manually extended. So with:

# ptxdist go

A part from minor dependencies that we can solve installing software with apt-get, the toolchain is built and the correct prefix will be:

CROSS_COMPILE_OSELAS_v5=$PRJROOT/tools/OSELAS.Toolchain-1.99.3/arm-v5te-linux-gnueabi/\
   gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin/arm-v5te-linux-gnueabi-

If we assign the environmental variable CROSS_COMPILE=CROSS_COMPILE_OSELAS_v5 the kernel configured by the upper config file and compiled with this toolchain is a good kernel to execute within the qemu-system-arm emulator!

A suitable Root Filesystem

Ok we have a good kernel ad a small initrd filesystem, but we have to develop application to run in the emulated device!

We can use the OSELAS.BSP Phytec phyCORE project installed following the description in Initializing a Linux Embedded Development Host Machine.

Download the platform_config file platformconfig-qemu and the ptxconfig one ptxconfigThiny (that is the normal ptxconfig removing all graphic subsystem for a speedier compilation)

Every two configuration file must be placed in $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/configs so with:

# cd $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/
# ptxdist select configs/ptxconfigThiny
# ptxdist platform configs/platformconfig-qemu
# ptxdist toolchain $CROSS_COMPILE_OSELAS_v5
# ptxdist go
# ptxdist images

In  $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/ we will find the root.ext2 image, ready to be the SD/MMC image of the qemu device!

Running qemu

If in the $PRJROOT directory we create the images/phyCORE directory and we put all the necessary:

# cd $PRJROOT
# mkdir -p images/phyCORE
# cp (kernel_path)/arch/arm/boot/zImage images/phyCORE/
# cp $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/root.ext2\
  images/phyCORE/

then we can start qemu:

# qemu-system-arm -kernel images/phyCORE/zImage -sd images/phyCORE/root.ext2 \
  -nographic -append "console=ttyAMA0 root=/dev/mmcblk0"

Results

In results we have a complete developing environment: emulator, toolchain, kernel, software ecosystem.

Kernel modification that do not deal with the hardware abstraction layer can be well developed in the emulator and tested by ad-hoc software inserted in the phyCORE-qemu distribution!

To save writing cycles of the Armadillo NAND flash, in those days I had  searched a way to execute the developing kernel on an ARM emulator.

First try: Android Emulator

I am working on Android? so why not using the Android Emulator tool??

I am not a guru on this, so maybe I’m wrong with something.. Someone will correct me if there were an easier way.

Android emulator is known to be build over the Qemu Open Source Process Emulator but Google tend to do things harder than they are: they have introduced a new virtual hardware device based on ARMv5te architecture called Goldfish.

Qemu emulate so well the ARM Integrator platform (same processor architecture), why build another? why create another buggy linux platform? buggy in the sense that it work for the kernel version that is developed, but must be maintained in the successive kernel release and who do this work? Maybe unanswerable question..

I’ve tried to port in mainline the Goldfish platform taking it from the android-goldfish-2.6.29 branch, correcting all the Coding Style problems given by checkpatch.pl resulting in: early support, console output  and maybe network ability, but no ability to mount initrd images or nand images -> no rootfilesystem ability and so I not spend here so many time describing this developing path.

Fortunately the light bulb come up my head and through the Qemu home page I’ve found that the reference machine platform for ARM emulation is the ARM Integrator, well supported in mainline Linux kernel and within the downloads I’ve found a reference kernel plus initrd file to use within.
Good! Second try!

If VirtualBox opens fine, but when you try to start a virtual machine (VM) you get the following error:

Failed to start the virtual machine Windows XP.
VirtualBox can’t operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).

… it means another virtualisation package – kvm – is interfering with VirtualBox. kvm isn’t installed on Ubuntu by default, so you probably installed qemu, the popular open-source emulator.

A quick fix is to stop kvm via the terminal:

sudo /etc/init.d/kvm stop

To stop this happening completely, mark the following packages for complete removal in Synaptic if they’re installed: kvm, qemu, qemu-kvm & qemu-launcher. Or you can do it via the terminal, and ignore errors regarding packages that weren’t installed (so can’t be uninstalled):

sudo apt-get remove kvm qemu qemu-kvm qemu-launcher

You should now be able to start your VM, without having to close and restart VirtualBox.

Hi, I’m Tyson Key, a college student currently residing somewhere in the north of England.

When I’m not studying, I happen to advocate and contribute to open source, and open platforms and enjoy spending time testing and documenting software, and exploring various aspects of low-level operating system and computer networking technology – all whilst trying to be a generally reasonable and agreeable person…

Of course, I also happen to be a heavy user, and advocate of the Symbian platform, and have been involved with the Symbian Foundation to varying extents, since its announcement.

Introduction aside, I’ve been invited to introduce the Symbian Virtual Platform. This is a project that I’ve been involved in beta testing, prior to the release of the Symbian Kernel Taster Kit.

What’s the Symbian Virtual Platform?

The Symbian Virtual Platform consists of a customised version of QEMU (an Open Source CPU instruction set and hardware emulator), containing several additional features, along with a corresponding baseport referred to as Syborg.

This combination potentially represents the future of inexpensive, accurate, user-level application testing, and low-level debugging and experimentation on the Symbian Platform, without the need for additional hardware.

As a bonus, some of the hallmark causes of frustration with the older Windows-based emulator (commonly referred to as WINS or WINSCW dependant upon toolchain used) are removed, such as:

• Low performance
• Simulation inaccuracy (e.g. differing memory models with various limitations, behavioural differences from real hardware, and disabled/restricted software functionality)
• Platform dependence – QEMU is well-supported under Windows, most Linux distributions and Mac OS X, and also runs under many other operating systems

What can it do for you?

The “official”/mainline version of QEMU already emulates an ARMv5 architecture CPU, and a number of hardware features including – but not limited to:

• Serial ports – complete with the ability to redirect traffic to a file, which is essential for Symbian Platform debugging and problem diagnosis
• Ethernet chipsets – a driver for which is included in Syborg, although additional work is necessary, before being suitable for intensive use
• Various forms of Flash memory devices (e.g. MultiMediaCard/SD Card, and SPI NAND Flash)
• An audio chipset – support for this in the baseport was recently contributed by Johnathan White of Accenture

However, the version supplied by Symbian also adds a number of useful features that enhance this functionality to potentially save development time and effort, and let users/enthusiasts test software quickly and easily without access to a physical handset, including:

• The ability to run real Symbian OS binaries “as-is” – meaning that you no longer also need to rebuild software to run within an x86 and Windows-only simulator
• A host file system-backed emulated drive (S:\ on the QEMU guest, which maps to \svphostfs on the host) that acts as an extension of firmware when custom executables are added, and allows for quickly moving files between the host and guest whilst the Platform is running
• A Python-based dynamic hardware modelling system that allows for varying degrees of control over the behaviour of the emulated system at runtime, without needing to modify QEMU source code and rebuild

The source code for these enhancements, and the baseport are available in the Symbian Foundation repositories.

Intrigued? Here’s what it looks like…

An EShell session, showing the output of various utilities, on a Windows XP host

What have I done with QEMU?

• Built several ROM images containing various Platform components, and documented the results on the Symbian forums so that others can assist in resolving problems, and enhancing the results
• Spent time debugging the execution of various binaries using serial port file redirection, and resolving dependency issues, as they arose

Which leads nicely on to a practical example, based upon a problem that I faced…

Getting the EUserHL Walkthrough test suite running

A forum thread that I started, with additional suggestions from the community, prior to writing this post is available here for reference. I’ll now attempt to explain how I answered a not-too-uncommon question using several features of the Symbian Virtual Platform, and a process of elimination -

How can I test a Platform component (in this case – EUserHL), when I don’t have access to the source code?

The initial steps involved boil down to:

• Install and configure the Symbian Kernel Taster Kit and RVCT 4.0 according to the instructions on the Symbian Wiki
• Create a directory on the host file system at \svphostfs and a set of subdirectories to hold executables and DLLs inside: sys\bin
• Copy \epoc32\release\armv5\urel\euserhl_walkthrough.exe and \epoc32\release\armv5\urel\euserhl.dll to \svphostfs\sys\bin
• Start a cmd.exe prompt session, and switch to \symbian-qemu-0.9.1\bin\

• Run QEMU using the prebuilt Syborg ROM image using: arm-none-symbianelf-qemu-system -M \sf\adaptation\qemu\baseport\syborg\syborg.dtb -kernel \epoc32\rom\syborg.img within the active cmd.exe session
• Once the ROM has booted to EShell, attempt to invoke euserhl_walkthrough.exe
• Notice that execution simply bails, before printing a rather vague, generic “Not found” error message

Obviously, this a rather sorry state of affairs – but there’s hope.  So, let’s move on:

• Halt the previous QEMU session
• This time, run QEMU again using arm-none-symbianelf-qemu-system -M \sf\adaptation\qemu\baseport\syborg\syborg.dtb -kernel \epoc32\rom\syborg.img -serial file:”EUserHLDebug.txt” to redirect serial port output to a file
• Within the EShell session, invoke trace /L 4 to enable debugging of executable loading and DLL iteration
• Attempt to invoke euserhl_walkthrough.exe once again within EShell, to receive the familiar “Not found” error
• Open \symbian-qemu-0.9.1\bin\EUserHLDebug.txt on the host, using your favourite text editor
• Following the chain of execution, from euserhl_walkthrough.exe onwards, to euserhl.dll, we can see that various dependency DLLs are located successfully (demarcated by “New image found“)
• However, if we closely follow euserhl.dll, the fact that a critical dependency is missing at a late stage is alluded to by “No suitable image found” – although reattempts are constantly being made to locate the missing DLL
• Unfortunately, this debug output does not tell us exactly which DLL we require – so we turn to another useful tool (elftran)
• At this stage, it would be a good idea to halt the QEMU session, to avoid some rather confusing behaviour that arises from the handling of the S:\ drive, and executable caching when copying additional DLLs and executables to \sys\bin within it

Now, we should be on the home stretch:

• Within another cmd.exe session, run: elftran \svphostfs\sys\bin\euserhl.dll > EUserHLDeps.txt to create a file containing information related to the dependencies of the euserhl.dll binary, amongst other attributes
• Searching for “imports from” within the EUserHLDeps.txt file will reveal that euserhl.dll depends upon estor.dll – which doesn’t exist in the prebuilt ROM image, or in \svphostfs\sys\bin
• Copy \epoc32\release\armv5\urel\estor.dll to \svphostfs\sys\bin
• Run arm-none-symbianelf-qemu-system -M \sf\adaptation\qemu\baseport\syborg\syborg.dtb -kernel \epoc32\rom\syborg.img once again
• With a little luck, attempting to invoke euserhl_walkthrough.exe should result in:


Partial output from running the EUserHL Walkthrough test suite

• Have fun exploring the serial debugging and tracing tracing functionality, and the host-bound file system

If that’s not enough, you can even try to build these components into a ROM image:

• Copy \sf\os\kernelhwsrv\kernel\eka\rombuild\tshell.oby to \sf\os\kernelhwsrv\kernel\eka\rombuild\tshellwitheuserhl.oby
• Add the following lines to the bottom of \sf\os\kernelhwsrv\kernel\eka\rombuild\tshellwitheuserhl.oby:
  file=\epoc32\release\armv5\udeb\estor.dll \sys\bin\estor.dll
  file=\epoc32\release\armv5\udeb\euserhl_walkthrough.exe\sys\bin\euserhl_walkthrough.exe
  file=\epoc32\release\armv5\udeb\euserhl.dll \sys\bin\euserhl.dll

• Delete euserhl_walkthrough.exe, euserhl.dll and estor.dll from \svphostfs\sys\bin\ to ensure that the contents of the ROM are not being supplemented/overridden with the contents of S:\sys\bin on the guest at boot time
• Within a cmd.exe session, switch to \sf\os\kernelhwsrv\kernel\eka\rombuild
• Run rom –variant=syborg –inst=armv5 –build=udeb –type=tshellwitheuserhl –name=\epoc32\rom\tshellwitheuserhl.img to attempt to build a new ROM image containing the EUserHL DLL, walkthrough/demo application, and the EStor DLL
• If everything worked according to plan, you should be able to run your new ROM image using: arm-none-symbianelf-qemu-system -M \sf\adaptation\qemu\baseport\syborg\syborg.dtb -kernel \epoc32\rom\tshellwitheuserhl.img within the \symbian-qemu-0.9.1\bin\ directory
• Invoking euserhl_walkthrough.exe for the final time should produce the same result as the previous exercise!

Additional Resources and Information

• A series of forum threads related to PIPS and networking, and the legacy, development-specific TechView GUI, in addition to the aforementioned EUserHL thread that I started, and continue to contribute to
• A list of backlog items and planned features for the Symbian Virtual Platform are available, here
• Johnathan’s presentation about the Symbian Virtual Platform at SEE 2009:
  View this document on Scribd

First you have to mount a medium on which we are going to install the Debian system. Generally, you have two options:

• Using a USB Flash drive:
  

  
## MAKE SURE THAT YOU UPDATE THIS
$ export ROOTDEV=/dev/sdc1
$ sudo mkfs.ext3 $ROOTDEV
$ sudo tune2fs -c 0 -i 0 $ROOTDEV
$ export MNTPOINT=/mnt/diskimage
$ sudo mount $ROOTDEV $MNTPOINT


• Using a Qemu image:
  

  
$ export MNTPOINT=/mnt/diskimage
$ export IMGFILE=hd0.img
$ sudo mount -o loop,offset=32256 "$IMGFILE" $MNTPOINT


Once we have the medium mounted at $MNTPOINT, we can proceed with installing Debian there and configuring it for Bifferboard:

$ export DBS_OS_VERSION=lenny
## replace "bg." with your local archive, or just omit it
$ export DBS_LOCAL_ARCHIVE=bg.
$ sudo debootstrap --arch i386 ${DBS_OS_VERSION} $MNTPOINT/ http://ftp.${DBS_LOCAL_ARCHIVE}debian.org/debian
## ... go grab a pizza or something ... this will take a while
$ sudo cp /etc/resolv.conf $MNTPOINT/etc/
$ sudo mount proc $MNTPOINT/proc -t proc
$ sudo chroot $MNTPOINT
##
## We are now in the "chroot" environment as root
##
/# apt-get -qq update && apt-get install wget
/# cd /root && wget http://www.famzah.net/download/bifferboard/debootstrap-postconfig.sh
/root# chmod +x debootstrap-postconfig.sh && ./debootstrap-postconfig.sh
/root# passwd root
/root# exit
##
## Back to our machine
##
$ sudo umount $MNTPOINT/proc
$ sudo umount $MNTPOINT


Now you have a minimum Debian installation customized for Bifferboard in the following way:

• Custom kernel for Bifferboard installed by a .deb package.
• Ethernet interface configured as DHCP client.
• Temporary directories /tmp and /var/tmp mounted on a RAM-disk.
• All APT sources “main contrib non-free” enabled.
• Serial console on ttyS0 (115200 8N1).
• RTC (real-time clock) kernel modules blacklisted – the Bifferboard has no RTC.
• IPv6 disabled – takes a lot of resources and we won’t use it anyway, for now.

I may add any further customizations if needed. You can always review the debootstrap-postconfig.sh script for details on what is being configured.

You can use this image/disk as a rootfs which you can boot directly on Bifferboard or try in Qemu. Note that you have to install our Debian kernel on Bifferboard prior to booting this rootfs.

Used resources:

• Debian Administration: Installing new Debian systems with debootstrap
• Installing Ubuntu from a Unix/Linux System

The idea is to be able to easily manage a Qemu image outside of Qemu, natively on Linux. This can help you to alter the files on the Qemu image easily on Linux and then test the modified Qemu image on a Qemu virtual machine.

You can download an empty, formatted with Ext3 Qemu raw image at the following URL address:

• empty-ext3-2GB.img.tgz (download size is 2 MBytes)

There is nothing special about how you can achieve this yourself:

• Create an empty Qemu image file.
• Run an installation CD of Debian (or any other Linux) under Qemu and use the empty image as an available hard disk.
• Partition and format the Qemu hard disk (resp. the Qemu image file) using the Linux installer.
• Interrupt the Linux installer, stop Qemu, mount the Qemu image on Linux and clean it up.

You can achieve the above using the following commands:

# make sure to update the .iso URL if needed
$ wget http://cdimage.debian.org/debian-cd/5.0.3/i386/iso-cd/debian-503-i386-netinst.iso
$ qemu-img create hd0.img 2G
$ qemu -hda hd0.img -cdrom debian-503-i386-netinst.iso -boot d
# continue with the installation to the point where you can set up the partitions
# set up a primary partition using the entire disk space, do not set up a swap partition; save changes to disk and continue
# interrupt the installation (for example from the second console by executing "halt"), stop the virtual machine, we will not need it any further
$ sudo mkdir -p /mnt/diskimage
$ sudo mount -o loop,offset=32256 hd0.img /mnt/diskimage
$ sudo rm -r /mnt/diskimage/*
$ sudo mkdir -m 0700 '/mnt/diskimage/lost+found'
$ sudo umount /mnt/diskimage

Now we have an empty Qemu image which we can mount in both Linux and Qemu.

Here is an example on how to mount this image in Qemu:

qemu -usb -usbdevice disk:hd0.img

Do not use the image simultaneously as Linux mount and Qemu hard disk.

Used resources:

• Installing Debian/Hurd with QEMU

Following the instructions found at these articles, I build a .deb package for Qemu which is suitable for the RDC processor which is used by Bifferboard. The instructions and patches can be found at the official Qemu Wiki page of Bifferboard.

There is nothing special I’ve done here, just packaged the qemu binary, so that you can easily try the “qemu-rdc” binary. The download link follows:

• qemu-rdc_0.10.5-1_i386.deb (595K)

Here are some simple instructions on how to test your own “bzImage” kernel build:

#
# Installation instructions for the .deb package and for the Qemu setup
#
famzah@FURNA:~$ wget http://www.famzah.net/download/bifferboard/qemu-rdc_0.10.5-1_i386.deb
famzah@FURNA:~$ sudo dpkg -i qemu-rdc_0.10.5-1_i386.deb
famzah@FURNA:~$ mkdir test-kernel
famzah@FURNA:~$ cd test-kernel/
famzah@FURNA:~/test-kernel$ svn co https://bifferboard.svn.sourceforge.net/svnroot/bifferboard/qemu/
famzah@FURNA:~/test-kernel$ cd qemu/run
famzah@FURNA:~/test-kernel/qemu/run$ vi run-qemu.sh # at the last line, change "qemu" with "qemu-rdc"

#
# You can now test your kernel/rootfs build. For example:
#
famzah@FURNA:~/test-kernel/qemu/run$ cp /home/famzah/biffer/qemu/custom_bzImage ./bzImage
famzah@FURNA:~/test-kernel/qemu/run$ QEMU_BIN=qemu-rdc ./run-qemu.sh

If you want to attach a USB mass-storage device and try your rootfs build there, please follow the instructions at the official Qemu Wiki page of Bifferboard on which parameters to add to “qemu-rdc” in “run-qemu.sh”.

You can exit the emulator by pressing CTRL+a and “x”. You will get some help info by pressing CTRL+a and “?”. See the man or documentation pages of “qemu” for more information.

In a few days I’ll post an article and a .deb package for a kernel 2.6.30.5 build with (almost) all possible modules, suitable for running a native i386 Debian rootfs installation on Bifferboard.

P.S. Today I got my serial USB RS232 @ 3.3V cable and can now start with some real tests

Šalia grafinių darbelių nusprendžiau išbandyti ir keletą TVS naujoje savo konfigūracijoje. LAMP (Linux Apache MySQL PHP) serverį pasileidau be problemų. Kadangi su wordpress jau esu pažįstamas tai artimiausiu metu išmėginsiu Drupal (jau suinstaliavau, dabar tereikia užmanyti kokį projektuką, kad būtų įdomiau nei “Hello, World”). Vėliau “pačiupinėsiu” ir kitas sistemas. Galbūt netgi savo ką nors paPHPinsiu paprastiem puslapiam vaizduoti.

Ir šiandien išbandysiu kaip veikia virtualizuoti winXP iš po linux (licenciją turiu oficialią, o ir šiaip įdomu). Tuo pačiu pastudijuosiu ir QEMU, o vėliau ir kitus virtualizatorius. Vakar mėginau instaliuoti iš CD, tačiau, kadangi aš dirbu GNOME aplinkoj (įtariu todėl), man nepasileido kqemu modulis, kas labai stabdo virtualios sistemos darbą. Šiandien mėginsiu iš *.iso failo instaliuoti, jei greitis bus panašus, tuomet mėginsiu virtualbox ar dar ką nors. Na ir, aišku pamėginsiu parašyti čia, kaip gi man sekėsi.

Este post faz referência sobre virtualização computacional, modelo de abstração de recursos computacionais, afim de prover redução de recursos necessários para consolidar diferentes arquiteturas, sob um único hardware básico (ou avançado, indo do gosto do freguês).

Pretendo cobrir a parte sobre virtualização de sistemas operacionais (virtualização de plataformas), portanto, não falarei detalhadamentesobre as outras abordagens de virtualização. Apesar de ser um assunto relativamente novo, é um assunto, ao mesmo tempo, relativamente muito velho. Entendo por virtualização a grande invenção da memória virtual (que abstrai um segundo dispositivo de armazenamento, como memória principal, e estende sobre esse o espaço de endereçamento de instruções), as interfaces virtuais de rede (onde, por exemplo, dependendo das capacidades do dispositivo, pode-se criar diversas interfaces de rede virtuais, com diversos pontos de acesso em IP, por exemplo, sob um único dispositivo físico), as interfaces virtuais de armazenamento (que podem ser, desde abstrações via rede, até um storage inteiro virtual), VPNs (que nada mais são que redes inteiras virtuais), virtualização de desktops (como terminais burros, ou por exemplo, serviços de terminais remotos), virtualização e clustering de sistemas de gestão de bancos de dados, e por aí vai!

Falando sobre Hypervisor

Para entrar no tema que eu quero sobre virtualização, não dá pra começar sem falar de uma entidade chamada de Hypervisor. Este é o sujeito responsável por prover uma interface lógica entre o que vai prover um ambiente de virtualização (chamado comumente de hospedeiro) e o que vai ser virtualizado (chamado comumente de convidado). Técnicamente, é uma porção de código que é executado pelo software hospedeiro, e age como um controlador de hardware e monitor do sistema operacional do software convidado. Geralmente, nesses moldes, o sistema operacional convidado, executa sob um nível abaixo do nível do Hypervisor.

A primeira figura exibe quais as camadas definidas na arquitetura de virtualização a qual estou me referindo.

Figura 1 – Arquitetura básica da virtualização provida pelo Hypervisor.

Há dois principais modos de execução do Hypervisor. O modo nativo (portanto, para virtualization), e o modo abrigado (portanto, full virtualization).

O primeiro modo de execução, chamado abrigado (com a palavrinha mágica – hosted), faz com que toda a plataforma de hardware disponível ao convidado seja totalmente virtualizada. Portanto, são implementados e aplicados gatilhos e tratadores nas chamadas de sistema e instruções de máquina (instruções nativas – sistema operacional convidado não sofre nenhuma modificação) enviadas pelo sistema operacional convidado, e convertidas para as instruções de máquina e chamadas de sistema do sistema operacional hospedeiro, portanto, executadas nativamente. O resultado de tais ações é novamente convertido para o formato de retorno do sistema operacional convertido, e tudo caminha nas mil maravilhas.

A figura 2 mostra um modelo esquemático de aplicação do modelo 1 do Hypervisor.

Figura 2 – Arquitetura básica do modelo hospedado.

Definem-se como vantagens dessa abordagem, o fato sistema operacional convidado não precisa ser modificado; para este, é uma máquina física como qualquer outra. Não há custos adicionais, nem modificação no software original, reservando as características originais do sistema operacional convidado. A grande desvantagem dessa abordagem é o desempenho comprometido (em relação ao desempenho original, o que não significa que fique lento – leia-se sem condições mínimas de emprego em um ambiente corporativo de produção). A queda do desempenho dá-se pela interpretação de todas as instruções disparadas pelo hardware virtual disponível para a máquina convidada. Além disso, claro, ainda há o escalonamento de processos do sistema operacional, através de um núcleo premptivo.

O segundo modo de execução, chamado nativo (com a palavrinha mágica – bare-metal), cria um meio termo nas coisas. Através de um núcleo de chamadas de sistema (vulgo Kernel, no mundo *nix) modificado, torna o sistema operacional convidado, alguém que sabe que está sendo virtualizado, mas que consegue, através desse núcleo modificado, alcançar nativamente o hardware disponível na arquitetura do sistema hospedeiro. Mágico, não?

Este novo núcleo, é então parte do Hypervisor (que agora é parte do sistema operacional convidado, e parte do sistema operacional hospedeiro), fazendo com que seja mais simples chegar ao hardware, e fazer algumas traduções das chamadas mais críticas do sistema.

Como vantagens da técnica, está principalmente o desempenho, tornando as coisas mais fáceis, fazendo com que não haja tradução de instruções, nem emulação de hardware. Por exemplo, se você comprou sua nova Intel® PRO/1000 GT Desktop Adapter, ele vai ser Intel no sistema hospedeiro, e Intel no sistema convidado. Na primeira abordagem, ela seria Intel no sistema hoespedeiro, e Network Virtual Driver, no sistema convidado. A principal desvantagem é a modificação do núcleo do sistema convidado, aumentando a probabilidade do número de falhas (por sair da árvore principal de desenvolvimento do software, e ter dedos de terceiros), incompatibilidade de padrões, aumento de custo de manutenção, e blá blá blá.

A figura 3 define um modelo esquemático de como aconteceria a implantação do segundo caso.

Figura 3 – Implantação do modelo nativo do Hypervisor.

Em relação ao modelo de virtualização de plataformas, com a presença de um Hypervisor, o assunto termina por aqui. Não há muito mais novidades na área.

Continuando com o assunto de virtualização, é válido dizer que o hardware x86 é particularmente difícil de virtualizar. Com essa motivação, tanto a Intel, quanto a AMD, criaram tecnologias de virtualização diretamente embutidas no processador. A Intel a chamou de Intel-VT (VanderPool), e a AMD, AMD-V (Pacifica). Tais extensões são responsáveis por adicionar capacidades que são difíceis ou ineficientes de virtualizar via software, facilitando o trabalho do pessoal que desenvolve na área.

Falando sobre implementações

Há diversos softwares comerciais e livres que implementam este modelo de monitor de máquinas virtuais, e com a idéia geral de virutalização de plataformas, dá pra nomear algumas categorias, de forma simplificada, e alguns softwares virtualizadores, que a implementam.

No primeiro modelo, nativo, encaixam-se nomes como VMware ESX Server, IBM System z Hypervisor, Microsoft Hyper-V, Xen, Citrix XenServer, Oracle VM Server, Parallels Server, Sun’s Logical Domains Hypervisor, e finalmente, o Kernel-based Virtual Machine (KVM), disponível nas distribuições empresariais de Linux. Todos esses softwares permitem a virtualização do sistema operacional hospedeiro, bem como o sistema operacional convidado, exigindo a modificação de seu núcleo.

Já no segundo modelo, hospedado, encaixam-se nomes como VMware Server, VMware Workstation, VMware Fusion, o projeto livre QEMU, Microsoft Virtual PC e Microsoft Virtual Server, Sun’s VirtualBox, Parallels Workstation e Parallels Desktop. Estes software virtualizam qualquer sistema opercional comum, sem a necessidade de sua modificação.

Virtualização e instâncias de sistemas operacionais

Especificamente, o Sun Solaris e o BSD, implementam um outro modelo de virtualização de sistema operacional.

O Sun Solaris (a partir de 2005) implementa Zones, definido como um abstração virtual do sistema operaciona, onde aplicações executam. Tais aplicações são protegidas e separadas umas das outras. Através de uma única instância principal do sistema operacional, pode-se gerencial diversas Zones (como instâncias do mesmo sistema).

O uso do gerenciamento de recursos da arquitetura em questão, faz com que uma Zone seja chamada de Container, criando o conceito de Solaris Containers. A maioria das pessoas utilizam  os dois termos, sem fazer distinção entre eles.

Existem dois tipos de Zones. As Zones nativas, criam instâncias do mesmo sistema operacional (Solaris), enquanto as Branded Zones, disponibilizam uma insfra estrutura virtual de hardware, para que seja possível criar instâncias de outros sistemas operacionais, como o Linux, por exemplo.

Da mesma maneira, existem os Jails (que vieram antes dos Containers, em 1990, criados a partir do FreeBSD). Jail implementa o mesmo sentido de abstração do sistema operacional, criando instâncias desse, fazendo com que haja muito mais flexibilidade do uso do sistema operacional, em um ambiente de produção.

Acredito que o uso de instâncias de sistema operacional, tenha tido como principal motivação, a flexibilidade de modelos de segurança que o *nix não conseguia prover, mas isso é um outro assunto.

Para terminar o post, volto a dizer que virtualização pode ser vista de diversas formas, e existem diversos modelos e ferramentas para implementar. Vão desde abstrações de hardware de entrada e saída, até abstrações do sistema operacional. O que vale realmente realmente, é estudar e medir as necessidades e as disponibilidades, para que seja feita a escolha certa.

O modelo de cloud computing se encaixa em virtualizações. É um tema recente, poderoso, mas com a escolha errada, pode se tornar extremamente perigoso.

Até a próxima!

Referências:

http://en.wikipedia.org/wiki/Virtualization

http://en.wikipedia.org/wiki/Hypervisor

http://www.sun.com/servers/coolthreads/ldoms/index.jsp

http://en.wikipedia.org/wiki/Paravirtualization

http://www.ibm.com/developerworks/br/library/l-hypervisor/index.html

http://blogs.technet.com/lpalma/archive/2008/10/01/paravirtualiza-o-emula-o-bare-metal.aspx

http://www.intel.com/products/desktop/adapters/pro1000gt/pro1000gt-overview.htm

I found an amazing linux kernel debugging post on the web, in this summer.

http://issaris.blogspot.com/2007/12/download-linux-kernel-sourcecode-from.html

More interestingly, this linux kernel debugging is using Eclipse. After following the procedure, I could create a good environment for debugging kernel source code. So, for easy presentation, I created slides, based on my experiments. Hopefully, it helps some people who are in the beginning of hacking and programming linux kernel.

DebugKernelEclipse-HyungWonChoi (PDF)

These experiments were done in the following environment:

OS: Fedora Core 11 (2.6.29.4-167.fc11.i686.PAE)
Linux Kernel Source Code: 2.6.30.2
Eclipse version:
- eclipse-cdt-5.0.2-2.fc11.i586
- eclipse-platform-3.4.2-11.fc11.i586
QEMU:
- qemu-common-0.10-16.fc11.i586
- qemu-kvm-0.10-16.fc11.i586
- qemu-img-0.10-16.fc11.i586
- qemu-system-x86-0.10-16.fc11.i586

Thanks..

Auf der Suche nach freien Alternativen zu Virtualbox bin ich auf Aqemu, ein grapisches QT4-Frontend für qemu gestoßen. Da ich qemu schon auf der Kommandozeile kannte, hab ich hin und her überlegt ob ich es überhaupt installieren soll…

Nachdem die Neugierde doch überwog, hab ich über apt das Paket aqemu installiert. Ich war gleich angenehm überrascht, mit allen Abhängigkeiten (inkl. qemu) wurden nur ca. 8 MB Platz nach der Installation belegt. Nach dem Start der Software begrüßte mich ein Fenster, das ähnlich wie das von Virtualbox aussieht. Also schon mal keine große Umgewöhnung zu meiner jetzigen Virtualisierungslösung. Eins vorweg, leider gibt es noch keine deutsche Lokalisierung für Aqemu unter Sid.

Einstellungsfenster

Um eine Virtuellemaschine einzurichten viel meine Entscheidung auf den Wizard. In ein paar Schritten lässt sich kinderleicht eine neue Maschine samt virtueller Festplatte einrichten. Dabei ist die Generierung der virtuellen Platte unter Aqemu viel schneller als unter Virtualbox erledigt. Kein ewig langes warten bis eine 10 GB Platte eingerichtet/erstellt ist, nach dem Klick auf Apply ist die Machine bereit. Was ich auch toll finde, eine Netzwerkverbindung von der virtuellen Netzwerkkarte zur realen klappt auf Anhieb.

Da nun eine Netzwerkverbindung besteht habe ich über den Reiter “Device Manager” die neueste Version von Frugalware Netinstall direkt aus der ISO-Datei installiert. Hier seht selbst, Installation von Frugalware unter Aqemu:

Aqemu Frugalware Installation

Nun läuft Frugalware unter (A)qemu anstandslos. Bedingt durch den geringeren Speicherverbrauch (Fesplatte), der schnellen Einrichtung und der intuitiven GUI wird Aqemu, Virtualbox auf meinem Schleppi ablösen. Das einzige was mich jetzt noch stört ist der fehlende USB-Support, dazu müsste ich mir einen neuen Kernel backen… Mal gucken, wenn ich mal die Muße dazu habe mach ichs vielleicht.

Hi friends,

Setting up networking in Qemu instance is very simple if you are using ‘user mode’ networking stack. And most of us don’t care about Full fledged networking while using Qemu Guests. But configuring Network in Qemu with full access requires TUN/TAP configuration.

Here is some simple steps which I did to configure TUN/TAP in Ubuntu 9.04,

Inside Ubuntu(Host), type the following commands:

$ sudo apt-get install qemu kqemu-common kqemu-source
$ wget ftp://ftp.osuosl.org/pub/lfs-livecd/lfslivecd-x86-6.3-r2145-min.iso
$ sudo qemu -cdrom lfslivecd-x86-6.3-r2145-min.iso -boot d -kernel-kqemu -m 512 -net nic -net tap &
$ sudo ifconfig tap0 192.168.10.1
$ sudo sysctl -w net.ipv4.ip_forward=1
$ sudo iptables -t nat -A POSTROUTING -j MASQUERADE
$ sudo iptables -t filter -P FORWARD ACCEPT

Inside lfslivecd(Guest) type the following commands:

$ ifconfig eth0 192.168.10.2
$ route add default gw 192.168.10.1
$ cat > /etc/resolv.conf <<EOF
nameserver 208.67.222.222
nameserver 208.67.220.220
EOF
$

Ofcourse, you can use any distro as a guest in qemu. Enjoy Qemuing.

Hi friends,

Don’t know about the how useful it will be, but I found some way to enable my friends to access my Qemu Guest Instance running LFSLiveCD in Ubuntu Host using ’ssh’. Here is the steps I did,

1. Download Qemu Packages

$ sudo apt-get install qemu kqemu-common kqemu-source

2. Download LFSLiveCD from here

3. Now start the LFSLiveCD guest using the following command

$ qemu -cdrom lfslivecd-x86-6.3-r2145-min.iso -boot d -m 512 -net nic -net user -redir tcp:35000::22

4. Now Qemu will start ‘LFSLiveCD’ with user mode network stack, that is, from LFSLiveCD, ip 10.0.2.2 will be the Default gateway and DHCP server. ip 10.0.2.3 will be the DNS server and the LFSLiveCD will get 10.0.2 15. If you look ‘netstat’ output in Host(here Ubuntu), there will be a line which tells port ‘35000′ is listening. Qemu process is listening in that port, it will redirect connections from Host(Ubuntu’s) 35000 port to Guest(LFSLiveCD’s) 22(ssh) port. All we need to do is, start ’ssh’ service in LFSLiveCD Guest. Type the following command in Qemu.

[root:]# cd /etc/rc.d/init.d
[root:]# ./sysklogd start
[root:]# ./sshd start
[root:]# passwd
New Password: [newrootpassword]
Retype New Password: [newrootpassword]
[root:]# tail -f /var/log/*.log

Now you have ’sshd’ running in the guest, and you also changed the ‘root’ password to a known password. All you need to do is, ask your friends to ’ssh’ to your Host’s(Ubuntu) ip address but with ‘35000′ port instead of default ‘22′ port. And ask them to login as ‘root’ as userid and ‘[newrootpassword]‘ as password. Your friends will be so much happy to see thay are became ‘root’. In the mean while you can also login to your guest with ’ssh root@127.0.0.1 -p 35000′. If you want, add a new user and share that userid and password to your friends, so that they can have less power.

Instead of Ubuntu Host, We can do this in Windows XP, as a Normal powerless user. The below thing you need to do,

1. Download QemuManager Zipfile Edition from here.
2. Download LFSLiveCD from here.
3. Configure LFSLiveCD inside QemuManager(follow this Guide).
4. While configuring Network, DoubleClick ‘NetWork Card 1′, GoTo Port Redirectors tab, type ‘35000′ in ‘Port Visible to Host’ and ‘22′ in ‘Port Visible On Guest’ and click ‘Add’ button.
5. Start ‘LFSLiveCD’ Qemu Guest. and Do all changes I explained above to start ’sshd’ inside LFSLiveCD.
6. Download ‘Putty.exe’ from here.
7. Start ‘Putty.exe’ with Host as ‘127.0.0.1′ and Port as ‘35000′ and Connection Type as ’ssh’.
8. Login with ‘root’ as username and ‘[newrootpassword]‘ as your password.
9. If you want to share your Qemu Guest, with your windows friends who’s machines and your’s machine are in same subnet, then ask them to start ‘putty.exe’ with host as your machine’s ip address, port as ‘35000′, username as ‘root’ and password as ‘[newrootpassword]‘. You can also create seperate ‘user’ in your Guest(LFSLiveCD) and share with your friends.
10. Enjoy Virtualization.

I also tried this method in my friend’s Vista laptop, but it failed!! First, it is not allowing to run QemuManager.exe as a normal user, Second, it is giving warning while opening ‘35000′ as listening port, Finally, ‘putty.exe’ is not at all connecting to Guest Instance, even though ’sshd’ is running in the LFSLiveCD Guest. If anyone have success story, kindly share.

Finally Thanks to my company for blocking access to the linux learning server, which make me to go for alternate methods and finally endup in the Windows XP method.

I am listing here some of the virtualization tools used in Linux .

1. User Mode Linux (UML) – http://user-mode-linux.sourceforge.net
2. Qemu – http://www.qemu.org
3. KVM – http://www.linux-kvm.or
4. Bochs – http://bochs.sourceforge.net
5. CoLinux – http://www.colinux.org
6. VirtualBox – http://www.virtualbox.org
7. VMware – http://www.vmware.com
8. GXemul – http://gxemul.sourceforge.net
9. OpenVZ – http://wiki.openvz.org/Main_Page
10. Skyeye – http://skyeye.sourceforge.net
11. Xen -  https://www.xen.org
12. Virtual PC – http://www.microsoft.com/windows/virtual-pc/
13. OVP – http://www.ovpworld.org/index.php

Good info on how to get qemu and vmware vms to talk

http://stupefydeveloper.blogspot.com/2008/08/vm-networking-qemu-and-vmware.html

For more half-baked ideas, see my “ideas” tag.

After we wrote virt-df and later libguestfs, what customers were asking me about was to be able to read out of /proc and /sys in a running virtual machine.

Of course that’s not possible with libguestfs. libguestfs reads the filesystem. /proc is a synthetic “filesystem” that only exists in the living C structs in the Linux kernel. What’s worse, those structs change with every release and every vendor specific patch. Following C structs is not easy, although we did it (with the help of a giant database) for virt-mem.

The prize of being able to “read” /proc is great — reading out statistics, process tables, network configuration, and much more information besides.

To do this tractably, what we need is to be able to inject syscalls into the virtual machine. If we could inject the following sequence of syscalls, we’d be able to read /proc in a completely portable manner without needing to chase kernel structs:

open ("/proc", O_RDONLY);
getdents (fd, ...);
read (fd, ...);

Here is my half-baked idea for how to do it.

1. Wait for a userspace program to be running. Then pause the VM.
2. Fork qemu, so we have a complete copy of the VM, its state, memory and so on. The original (parent) process can now be resumed, and hence the VM resumes. The rest of this discussion concerns only the child process.
3. Disconnect qemu from any outside influence. This means disconnecting any block devices, network devices, and perhaps other devices. This ensures our private copy of the VM can’t accidentally overwrite any state from the real, running VM.
4. At this point we have a “captured” userspace process in the VM. It doesn’t particularly matter which process we happened to capture. We now set up the stack frame and registers for the system call we want to execute. Any previous contents of the memory and registers can be discarded.
5. Set the emulation running. (The captured userspace process now runs and performs the syscall).
6. Trap back into qemu when the syscall exits.
7. Capture the return value from the syscall, which might be a status code, error or read buffer. In any case, we’ve successfully injected a syscall into the VM and this has allowed us to read something out of /proc.
8. Discard the qemu child process.

We make the modest assumption that the syscall we chose will run without scheduling. Even if it does schedule, the fact that we have disconnected qemu from any block devices (writes effectively go to /dev/null) should mean at least it won’t damage anything.

Notice that we’re using the public syscall interface to the Linux kernel, not depending on the details of changing internal structures.

As ideas go this seems tractable, although the implementation is both technically difficult and probably hard to get upstream. We need a way to trap-and-pause when a VM switches to userspace. We need to be able to fork the VM and do all sorts of modifications on our copy. Then we would need some nice wrappers around this so the user just has to type “virt-ifconfig myvm” (note: previously we implemented virt-ifconfig as part of the virt-mem project by chasing kernel structs).

Para montar  uma image  do QEMU  no filesystem,  devemos calcular  o [offset] da  partição. Ou seja multiplicar o setor inicial por 512 (quantiade de  bytes por setor). Veja o simples exemplo abaixo:

# sfdisk -luS hda1DB91.img
Disco hda1DB91.img: não foi possível obter a geometria

Disco hda1DB91.img: 248 cilindros, 255 cabeças, 63 setores/trilha
Unidades = setores de 512 bytes, contando a partir de 0

 Device Boot    Start       End   #sectors  Id  System
hda1DB91.img1            63    530144     530082  82  Linux swap / Solaris
hda1DB91.img2   *    530145   3984119    3453975  83  Linux
hda1DB91.img3             0         -          0   0  Vazia
hda1DB91.img4             0         -          0   0  Vazia

Efetue  o seguinte cálculo (setor inicial*512):

530145*512= 271434240

Agora  utilize o comando mount.

# mount -o loop,ro,noexec,offset=271434240 hda1DB91.img /mnt/suse9.1

Simples não…

Depuis le temps que je voulais mettre en ligne un petit blog sur lequel je pourrais poster de temps à autres quelques news et articles en rapport avec l’informatique, aujourd’hui je me lance enfin.  J’essaierai d’écrire sur Blog Pistache` deux à quatre fois par semaines pour parler le plus souvent de PHP et d’Ubuntu, plus généralement de développement web et de Linux. D’autres sujets seront sûrement abordés:  WordPress, puisque c’est la plateforme de gestion de blogs que je suis amené à découvrir, quelques news personnelles ou informatiques, certainement des coups de gueule (je ne sais pas encore sur quoi mais je trouverai bien)… Le but de ce blog étant principalement de communiquer le peu de savoir et d’expérience que je possède, j’essaierai de remplir cette tâche du mieux que je pourrai. Blog Pistache` est aussi un bon moyen pour moi de garder un œil sur la blogosphère, puisque dans le domaine des nouvelles technologies en général, être en veille est primordial si on ne veut pas se retrouver, dans moins de temps qu’il n’en faut pour l’écrire, aussi dépassé qu’un Hello World en Fortran.

Je profite aussi de ce premier post pour annoncer que le lancement de mon blog coïncide avec l’installation toute fraîche sur mon laptop de la dernière Ubuntu stable en date à savoir Ubuntu 9.04 aka Jaunty Jackalope. Avant de tout reformater j’avais en dual boot Windows XP et une précédente version d’Ubuntu, mais ça faisait longtemps je n’utilisais plus les partitions de Windows que comme support de stockage et ce grâce à un magnifique écran bleu qui ne manquait jamais de s’afficher à chaque tentative d’accès au système d’exploitation de Microsoft. Cette fois j’ai bien pris garde de n’installer que Linux et si un jour des envies masochistes me reprennent il y aura toujours QEMU ou même VirtualBox. Donc après avoir personnalisé ma nouvelle Ubuntu voici ce que ça a donné :

Mon bureau sous Ubuntu 9.04

Rien de bien extraordinaire, un fond d’écran vectoriel de chez devianArt, quelques screenlets et le tour est joué. Quand on voit aujourd’hui les possibilités de configuration qu’offrent les environnement de bureaux tels que GNOME et KDE, on se demande ce que peut bien encore envier Linux à Windows. Sur ce, amis geeks, bienvenue sur Blog Pistache` et à bientôt !

]]> http://snnangola.wordpress.com/2009/08/01/maquinas-virtuais-com-qemu/ Sat, 01 Aug 2009 20:14:13 +0000 snnangola http://snnangola.wordpress.com/2009/08/01/maquinas-virtuais-com-qemu/

Bom, definitivamente estamos na época da virtualização. Existem diversas ferramentas para diferentes sistemas, geralmente funcionam tanto em Linux como em Windows. O VMWare, o VirtualBox sao as opções mais conhecidas. No Windows costumo usar o VirtualBox, no Linux o Qemu. Escolhi o Qemu por ser uma opção que dá maior poder de manejamento a quem cria as maquinas virtuais. Ferramentas como VirtualBox e VMWare encapsulam muita coisa.

A instalação

O Qemu pode ser encontrado aqui. Baixei os pacotes de fonte por serem independentes da plataforma.

Descompacte e instale como em:

$ tar xzfv qemu-0.10.5.tar.gz
$ cd qemu-0.10.5

Lá dentro a shell de configuração:

$ ./configure
$su

Como root:

[root@localhost alunoeng]# make
[root@localhost alunoeng]# make install

Em seguida, baixar e instalar os fontes do modulo do kernel Qemu Accelerator (Kqemu):

[root@localhost alunoeng]# tar xzfv kqemu-1.4.0pre1.tar.gz
[root@localhost alunoeng]# cd kqemu-1.4.0pre1
[root@localhost alunoeng]# ./configure
[root@localhost alunoeng]# make
[root@localhost alunoeng]# make install

Adicionar o modulo KQemu ao Kernel e editar o file rc.local adicionando uma linha identica a abaixo para executar a cada inicio do sistema:

[root@localhost alunoeng]# modprobe kqemu
[root@localhost alunoeng]# vi /etc/rc.d/rc.local

Adicionar em rc.local a linha modprobe kqemu

Uma vez tudo isso, podemos criar a nossa primeira maquina virtual e seu disco:

Antes criar o dir /home/alunoeng/ubuntuimg/

[root@localhost alunoeng]#mkdir /home/alunoeng/ubuntuimg/

Criar o disco ubuntu.qcow com tamanho de 2000M

[root@localhost alunoeng]# qemu-img create -f qcow /home/alunoeng/ubuntuimg/ubuntu.qcow 2000M

Insira um disco .iso na drive de CD ou DVD ( a minha esta localizada em /dev/sr0)

Se necessitar saber o path onde está o seu disco e sabendo o nome de pelo menos um file do seu disco você pode fazer:

[root@localhost /]# cat /etc/mtab | grep -i eag
/dev/sr0 /media/Eagle40Server-2.0 iso9660 ro,nosuid,nodev,uhelper=devkit,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500 0 0

Como vimos o path da minha drive de CD é /dev/sr0, logo criemos a maquina virtual e diagamos que ela dá o boot pelo cdrom com 12m mb de memoria RAM usando o arquivo ubuntu.qcow:

[root@localhost alunoeng]# qemu -cdrom /dev/sr0 -boot d -m 128 /home/alunoeng/ubuntuimg/ubuntu.qcow

Uma janela de instalação do sistema deverá aparecer.

Para dar boot:

[root@localhost alunoeng]#qemu -cdrom /dev/sr0 -boot c -m 128 ubuntu.qcow

I have checked out the recent sources for Android 1.5 Cupcake on my Jaunty box and have not been able to compile it. After some research, I have found a solution, which originates from the android-porting mailing list. The problem is buried in the customized Qemu Makefile. You should apply the following pach and hope everything works fine for you, too:

project external/qemu/
diff --git a/Makefile.android b/Makefile.android
index 4c697fb..98d2084 100644
--- a/Makefile.android
+++ b/Makefile.android
@@ -18,7 +18,7 @@ MY_CFLAGS := $(CONFIG_INCLUDES) -O2 -g \

 # this is needed to build the emulator on 64-bit Linux systems
 ifeq ($(HOST_OS)-$(HOST_ARCH),linux-x86)
-  MY_CFLAGS += -Wa,--32
+  MY_CFLAGS += -Wa,--32 -D_GNU_SOURCE
 endif

 ifeq ($(HOST_OS),freebsd)

Because I had such great experience in the past with VirtualBox I downloaded and installed VirtualBox 3.0 Beta 1 recently. And I must say that it just works flawlessly! 1. The Installation after downloading the Files was really fast, then 2. My Windows XP is as fast as anything I could imagine. I can actually have my Linux and my Windows XP running at the same time with no performance problems whatsoever with 2 GB of RAM. Ok I got one of those Intel SSDs (160GB) that might make a difference but I really give VirtualBox my thumbs-up and Qemu my Thumbs-Down, including my toes! I tried to use Qemu for a long time but (between the VirtualBox versions 1.5 and 3.0) and for the mean time I am back to VirtualBox because it is such a real pleasure to use it! Thank you VirtualBox! Thank you to DownloadSquad for pointing this out to me.

If you want to test out some experimental libguestfs changes to a virtual machine, you can use a qemu snapshot to test changes before committing them. Here’s how.

First, use qemu-img to create a snapshot. In this case I have a base file called “RHEL52PV32-20090213.img” and my temporary snapshot will just be called “snapshot”. The file “snapshot” is linked to the base file.

$ qemu-img create -b RHEL52PV32-20090213.img -f qcow2 snapshot
Formatting 'snapshot', fmt=qcow2, backing_file=RHEL52PV32-20090213.img, size=8388608 kB

Now we start guestfish on the snapshot. Notice a new feature of guestfish – just use “guestfish -i image” or “guestfish -i libvirt_domain” to automatically mount all the partitions within the image in the correct places. In this case I wanted to remove the root password from the image:

$ guestfish -i snapshot

Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for help with commands
      'quit' to quit the shell

><fs> mounts
/dev/mapper/VolGroup00-LogVol00
/dev/sda1
><fs> vi /etc/shadow
><fs> sync

At this point, only the snapshot has changed. The base image is left alone. I test-booted the snapshot to check that my change was correct. If the change was bad, I could have just deleted the snapshot file, but since everything was OK, I committed the change back into the base image:

$ qemu-img commit snapshot
Image committed.

The “snapshot” file is no longer needed, unless you want to test further changes.

(Thanks to Dan Berrange for working out the details)