X86Android 4.0 RC2 on KVM

表題のとおり、X86Android 4.0 RC2をLinuxKVMで動かしてみました。
NICまわりで手こずったのでメモメモ。

下記のサイトを参考に、Ethernet patchのあたったイメージを使用する前提で話を進めます。

http://www.webupd8.org/2012/07/android-x86-404-ics-rc2-released-with.html

イメージは以下のものを使用しました。(なかなかダウンロードできない)

http://www.sendspace.com/file/t5a3aj

ISOを用意して、virtinstallで普通にインストールします。
ポイントはNICをmodel=e1000にするところですかね。これでインテルNICをエミュレートしてくれます。

$ sudo virt-install \
–connect=qemu:///system \
–name android4.0 \
–ram 512 \
–disk path=/var/lib/libvirt/images/android4.0.img,cache=writeback,sparse=true,size=5 \
–cdrom=’/home/yutaro/iso/desktop_generic.iso’ \
–vcpus=1 \
–os-type linux \
–os-variant generic26 \
–network bridge=br0,model=e1000 \
–vnc \
–accelerate \
–hvm

インストールが終わったら、デフォルトで入っている「端末エミュレータ」で /etc/init.sh を編集して
起動時にIPアドレスをStaticで振るようにする。(GUIの設定画面は使えませんでした)
各種アドレスは自分の環境に合わせて設定してください。

$ su –

# vi /etc/init.sh
(略)
ifconfig eth0 [IP ADDRESS] up ;Androidゲストのeth0にIPをつける
route add default gw [GATEWAY ADDRESS] dev eth0 ;デフォゲを指定する
setprop net.dns1 [RESOLVER ADDRESS] ;リゾルバ(DNSキャッシュサーバ)を指定する

これで再起動するとネットワークにつながっているはず。
pingとかで確認してみましょう。

仕事中に眠くなってきたので
といった感じで遊んでみました。

 

ユーザ権限で virt-manager がが

デスクトップOSとしてUbuntuを使うとサーバとの連携がいろいろと楽でいいのですが、
まれにその連携がうまくいかないことがあります。

今回はユーザ権限で起動したvirt-managerでlibvirtdに接続ができなかったので
対応した内容をメモ書きで残しておきます。

0. 環境

OS:Ubuntu 12.10 Desktop

1. エラー内容

libvirt に接続できませんでした。

Verify that:
– The ‘libvirt-bin’ package is installed
– The ‘libvirtd’ daemon has been started
– You are member of the ‘libvirtd’ group

Libvirt URI is: qemu:///system

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/connection.py”, line 1027, in _open_thread
self.vmm = self._try_open()
File “/usr/share/virt-manager/virtManager/connection.py”, line 1009, in _try_open
flags)
File “/usr/lib/python2.7/dist-packages/libvirt.py”, line 102, in openAuth
if ret is None:raise libvirtError(‘virConnectOpenAuth() failed’)
libvirtError: ソケットの ‘/var/run/libvirt/libvirt-sock’ への接続に失敗しました: 許可がありません

 

2. 対応内容

[email protected]:~# vi /etc/libvirt/libvirtd.conf

[email protected]:/etc/libvirt# diff libvirt.conf.def libvirtd.conf
88c88
< unix_sock_ro_perms = “0770”

> unix_sock_ro_perms = “0777”
98c98
< unix_sock_rw_perms = “0770”

> unix_sock_rw_perms = “0777”
101c101
< #unix_sock_dir = “/var/run/libvirt”

> unix_sock_dir = “/var/run/libvirt”

[email protected]:~# service libvirt-bin stop
libvirt-bin stop/waiting
[email protected]:~#
[email protected]:~# service libvirt-bin start
libvirt-bin start/running, process 4368
[email protected]:~#

 

デフォルトではソケットファイルが作られないので、
ソケットファイルを生成しつつotherに権限を与えてあげれば良いかと。

ただ、otherに権限与えるのがあまり好ましくない環境ではおすすめしません。
よくよく考えるとlibvirtdグループに実行ユーザ加えてあげればいいような・・・

resolvconfd と dnsmasq と libvirt と unbound と私

※忘れそうなのでメモです。

私が会社で使っている作業用サーバはUbuntuのKVM上で動いているFreeBSDです。(ホストのUbuntuも使ってるけど)
気が向いたときにホストのapt-get update/upgradeをするのですが、たまにKernelのアップデートがくると
再起動をしなくてはいけないので、仕方なく再起動をしています。

この時点で resolv.conf を手書きで書き換えていたりすると、楽しいことが起こったりします。

Ubuntu12.04では resolv.conf  の管理を resolvconfd で行っていて、デフォルトではローカルで起動している
リゾルバ(dnsmasq) を参照するように、起動のたびに 127.0.0.1 を参照するように resolv.conf を書き換えてくれるという仕様になっています。

とても親切ですね。

私が仕事で使っている環境は同ホストで unbound を起動してキャッシュリゾルバとしても使用しているので、
dnsmasq が起動されると bind しているアドレス・ポートがかぶって unbound が起動しなかったりで
一筋縄には行かないのです。(dnsmasqの存在を意識していなかった)

ということで、「dnsmasq が邪魔なら dnsmasq を起動しなければ良い!」 という安直な考えに至り、dnsmasq を stop

[email protected]:/# /etc/init.d/dnsmasq stop
* Stopping DNS forwarder and DHCP server dnsmasq
…done.
[email protected]:/#

これで、安心だろ。
と、おもって KVM の FreeBSD (ゲスト)にログインするとネットワークがつながらない・・・
libvirt で仮想マシンを管理しているので、dnsmasq を切ってしまうとどうやら外に出られなくなるみたいだ(詳しくは調べてません)

「そうしたら  dnsmasq と unbound を共存させればいいんだろ?」という安直な考えに至り、 conf を編集

[email protected]:/# vi /etc/unbound/unbound.conf

server:
interface: 192.168.10.70

(略)

 

[email protected]:/# vi /etc/dnsmasq.conf

listen-address=127.0.0.1
bind-interfaces

これでデーモンを再起動すれば dnsmasq/unbound が共存できます。

ちなみに、前置きが長くなりましたが、ここからが本編です。
resolvconfd の挙動が良く分からなかったので今回はじっくり観察してみました。

Googleなんかで “ubuntu 12.04 resolv.conf” などと検索すると、
大抵のBlog記事は /etc/resolvconf/resolv.conf.d/ 以下のファイルを編集しろと書かれています。

[email protected]:/etc/resolvconf/resolv.conf.d# ls
base  head  original

ここで引っかかりました。
いくら編集して、resolvconfd/networking/server再起動しても  resolv.conf が思ったように書き換わらないので、
Ubuntuのマニュアルをよく読んでみた。

http://manpages.ubuntu.com/manpages/precise/man8/resolvconf.8.html

/etc/network/interfaces を編集すればよいことが判明。(ちゃんと書いてあるじゃん)
オフィシャルなマニュアルをちゃんと読まないと遠回りしてしまうんですね。

ということで  /etc/network/interfaces を以下のようにしてみた

auto br0
iface br0 inet static
address 192.168.10.70
network 192.168.0.0
netmask 255.255.0.0
broadcast 192.168.255.255
gateway 192.168.0.1
dns-nameservers 192.168.10.70 192.168.0.20 8.8.8.8
dns-domain hoge.com
dns-search fuga.net foo.com
bridge_ports eth0
bridge_stp off

iface eth0 inet manual

どうやら “dns-*” な行を読み取って resolv.conf を読みよってくれるようなので、
これでネットワークをリスタートして resolv.conf を見てみましょう。

[email protected]:/# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search choge.com fuga.net foo.com
[email protected]:/#

nameserver が 127.0.0.1 になっていますが、心配ありません。
dnsmasq がロードしている conf を参照すると以下のようになっています。

[email protected]:/# cat /var/run/dnsmasq/resolv.conf
nameserver 192.168.10.70
nameserver 192.168.0.20
nameserver 8.8.8.8

コレに気づかず30分ぐらい時間を無駄にしました。

ちなみに、 dnsmasq や unbound などのデーモンが起動していない(起動しない)環境では /etc/resolv.conf の
nameserver  は 127.0.0.1 ではなく、 /etc/networl/interfaces に書かれている dns-nameservers の値が明示的に入るようです。

親切というか、なんと言うか、今までの掟的なものが頭から離れないとハマること間違いなしですね。