Month: March 2013

Openstack architecture diagram (kvm, qemu-kvm, libvirt, nova, cinder)a

Correct me if i am wrong.

Openstack components (nova, cinder, glance) controls libvirt to provide visualization and libvirt use qemu-kvm as the hypervisor. The reason openstack don’t control the qemu-kvm directly is because libvirt provides better cross VM functionality (it can adopt to xen, vmware, etc…) and it provides high-end function such pool management and column management.

KVM is the hypervisor, is emulate the CPU but it don’t do anything about networking and I/O peripheral control. That’s why we need to use qemu-kvm as the emulator to emulator all the peripherals, rather than use KVM directly.

The following diagram is the relationship between kvm, qemu-kvm, libvirt and openstack components.

openstack architecture diagram

read count : 2317

put python+django to apache through virtualhost

to put python+django to apache through virtualhost

1) edit /etc/httpd/conf/httpd.conf

Listen 83

<VirtualHost *:83>
        WSGIScriptAlias / /root/workspace/MyDjangoProject/P1/
        AddType text/html .py
        <Directory /root/workspace/MyDjangoProject>
                AllowOverride None
                Options +ExecCGI +Indexes
                Order allow,deny
                Allow from all
                Require all granted

2) edit /root/workspace/MyDjangoProject/P1/, change it to

from django.core.wsgi import get_wsgi_application
import os
import sys

path = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
if path not in sys.path:

path = '/usr/share/myapplication'
if path not in sys.path:

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "P1.settings")

# This application object is used by any WSGI server configured to use this
# file. This includes Django's development server, if the WSGI_APPLICATION
# setting points here.
application = get_wsgi_application()

read count : 538

error in createsuperuser

error in createsuperuser

/root/workspace/P1>./ createsuperuser
Traceback (most recent call last):
  File "./", line 10, in <module>
  File "/usr/lib/python2.7/site-packages/django/core/management/", line 443, in execute_from_command_line
  File "/usr/lib/python2.7/site-packages/django/core/management/", line 382, in execute
  File "/usr/lib/python2.7/site-packages/django/core/management/", line 196, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/python2.7/site-packages/django/core/management/", line 232, in execute
    output = self.handle(*args, **options)
  File "/usr/lib/python2.7/site-packages/django/contrib/auth/management/commands/", line 70, in handle
    default_username = get_default_username()
  File "/usr/lib/python2.7/site-packages/django/contrib/auth/management/", line 105, in get_default_username
    default_username = get_system_username()
  File "/usr/lib/python2.7/site-packages/django/contrib/auth/management/", line 85, in get_system_username
    return getpass.getuser().decode(locale.getdefaultlocale()[1])
TypeError: decode() argument 1 must be string, not None

To solve the above issues, type in

export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

read count : 480

GDB will remove all breakpoint and set it back repeatly

When you set the breakpoint by input the “b” command, the gdb will not set it immediately, it will wait until the user pressed “c” to cont execute the program. After you pressed “c”, gdb will set all the breakpoints for you. The most funny thing is : when gdb hit a breakpoint and gain back the control, it will remove all breakpoints, it prevent hanging in the same EIP when you do single-step. Here is the prove:

How gdb set breakpoint

read count : 1061

qemu debug server hang after breakpoint is hit

If you are developing a debug server for qemu, after qemu hit a breakpoint, your server have to remove the breakpoint manually and re-insert it after the cpu passed that EIP, otherwise the cpu will forever stay in the EIP and can’t single-step/cont to the next instruction. If you take a look the gdbstub.c, gdb will fire a ‘Z’ command to gdbstub to remove the breakpoint after the breakpoint is hit.

That’s why my debug server not working before.

read count : 1223

How to use QMP, send command remotely to qemu

To use qmp and send command to qemu from another process, start qemu by

qemu-kvm -m 4096m -hda win7.img -chardev socket,id=qmp,path=/tmp/test.qmp,server,nowait -mon chardev=qmp,mode=control 

This will create a file /tmp/test.gmp for interchange the command. Then you can start another terminal and invoke

cat command.txt |socat - /tmp/test.qmp 


{ "execute": "qmp_capabilities" }
{ "execute": "query-status" }
{ "execute": "query-commands" }
{ "execute": "stop" }
{ "execute": "screendump","arguments":{"filename":"peter.png"}  }
{ "execute": "cont" }
{ "execute": "human-monitor-command", "arguments": { "command-line": "info registers" } } 

!!! remark, must invoke { “execute”: “qmp_capabilities” } before invoke any qmp command

read count : 1662

openstack conflict with virtualbox

When you are running vm in virtual box, and try to start any vm in openstack. The vm that are running in virtualbox will crash immediately, you need to do the follow command to shut it down. If you want to restart that VM, please rmmod the kvm module.

vboxmanage controlvm "your vm name" power off

I guess is that the kvm mod try to take over the hypervisor of virtualbox, so the virtual box crash

read count : 279

OOM has trouble to KVM, it can’t shot down the kvm

In Linux, if the system is out of memory, OOM will pick one process to kill. But someone reported the OOM can’t kill the qemu-kvm, that mean if you are running many VMs that eat up all the memory, the Linux will hang because OOM can’t kill them

In tried to run 64 VMs using qemu-kvm with 1GB ram each. Without turn on the swap, the linux just hang, i am using FC18 64 bits. If i turn on the swap, the linux will become very slow, but at least it won’t hang.

So turn on the swap is important when you are playing kvm or openstack.


read count : 269

Restructuring the debugger

At the moment, i am facing 2 big problems of bochs, the first one is unsolvable, bochs running too slow. It is ok if you are doing a hobby OS development, but if you are trying to use bochs to run a full feature Linux kernel or a windows 7, it is just so slow. The second problem is the debugging output format of bochs, I nearly get a email from peter-bochs user a month, they just complain that the latest bochs can’t integrate with peter-bochs. I already raised an idea to use XML instead of plain text output, but no one would love to change.

So my plan is:
1) I am adopting peter-bochs to qemu, it seems ok, but i am stuck into the single step mode of qemu
2) After i create the stub in qemu, i need to propose it to qemu team, don’t know the chance. But even fail, i maintain it by myself

Architecture changes:
1) I am thinking to use OSGI in peter-bochs. I want to split out some modules into dynamic loading, so I can pay money to some people to write module for me, this speed up the whole process
2) I want to split these modules:
a) disassembler
b) dwarf library
c) VM controller
d) profiling module
3) after I split out the controller module, it is possible to pay some money to some people to adopt the debugger to ARM.
4) The dwarf library I created has some weakpoint, because the dwarf spec is so large, I still now sure how many % peter-dwarf library is supported. After I split out that module, expertise can extend/harden it for me.


read count : 407