タグ別アーカイブ: Xen

Linux, PC

XenカーネルでのNICのカスタマイズ

コメントをどうぞ

Xenを使って仮想化しているマシンではネットワークも仮想化される。
そのあたりはこちら参照。

でまあそういうことで、ethtoolなんかでNICの設定をしたい場合は、通常と異なりeth0とかをいじるのではなくて、Dom0でpethをいじるのが正解。
普通はpeth0になってるだろう。

実際にethtoolをたたいてみたら、仮想NICであるethの方はろくに情報が出力されないはずだ。
それに対してpethの方はちゃんと出力されるはず。

# ethtool eth0
Settings for eth0:
        Link detected: yes
# ethtool peth0
Settings for peth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000001 (1)
        Link detected: yes

こんな感じ。

ということでXenカーネルでうごかしてるマシンのNICの設定をいじりたい場合は、pethをいじりましょう。

Linux, PC

linux-image-3.0.0-2とlinux-image-2.6.32-5でNFSがうまく動かない

コメントをどうぞ

カーネル2.6.32-5でなんかI/O周りでkernel OOPSをはくので、むしゃむしゃしてkernelのバージョンをあげたんですよ。
でね、うちはxen使ってDomUが二つ動いていまして、Dom0はkernel 3.0.0-2で問題なく動いたんだけど、DomUの片方はブートしないでござるの巻きに陥ったわけでして、仕方ないのでそっちは2.6.32で動かしたんですよ。
で、色々と動作確認しているうちに、NFSでマウントしていたディレクトリのオーナーとグループがnobody, nogroupになってることに気づいたわけですよ。
そこから色々と試していくうちにわかったのが、NFSサーバのカーネルが3だと2.6でNFS接続するとnobody, nogroupになるということ。
ああ、ちゃんと共有対象ディレクトリのクライアントとサーバのユーザ名およびuid, グループ名およびgidは同じですよ。
2.6がサーバなら3がクライアントでも2.6がクライアントでも問題なし。
3がサーバの時、クライアントが3なら問題ないけど2.6だとだめ。
オプションでall_squashつけてanonuidとanongid設定しても駄目。
軽く数時間はまりましたよ。
とりあえずカーネルが更新待ちだなー。

追記
やっぱりall_squashとanonuidとanongidでいけました。
うそつきましたごめんなさい。
all_squashで全員nobody, nogroup扱いにして、anonuidとanongidでnobody, nogroupのIDを実際に動作させたいユーザのIDにマッピング。

Linux, PC

LVMのスナップショットの動作が怪しい

コメントをどうぞ

うちのサーバ機はxenを使って仮想化して運用している。
そして毎日定期バックアップをLVMのスナップショット機能を利用して行っているのだけども、どうも最近挙動がおかしいことに気づいた。
作成したスナップショットが高確率でファイルシステムにエラーを含んでいる。

# xm pause debian
# lvcreate -s -n snapdebian -L 200G /dev/ms09/debian
  Logical volume "snapdebian" created
# xm unpause debian

としてスナップショットを作成する。
ここまではいい。
が、ここでfsckを走らせるとエラーが出る。

# e2fsck -yfv /dev/ms09/snapdebian
e2fsck 1.41.12 (17-May-2010)
/dev/ms09/snapdebian: recovering journal
Clearing orphaned inode 15466504 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466503 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466502 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466501 (uid=109, gid=109, mode=0100600, size=20)
Clearing orphaned inode 15466500 (uid=109, gid=109, mode=0100600, size=0)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/ms09/snapdebian: ***** FILE SYSTEM WAS MODIFIED *****

  715619 inodes used (2.13%)
     738 non-contiguous files (0.1%)
     182 non-contiguous directories (0.0%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 706955/133
23572155 blocks used (17.56%)
       0 bad blocks
       6 large files

  677160 regular files
   29784 directories
     126 character device files
      40 block device files
       2 fifos
      16 links
    8469 symbolic links (8324 fast symbolic links)
      29 sockets
--------
  715626 files

マウントしてrsyncでバックアップをとるとumountでえらい時間がかかる。
カーネルが文句いってる。

[  647.099517] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466504
[  647.099539] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466503
[  647.099548] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466502
[  647.099556] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466501
[  647.099591] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466500
[  647.099599] EXT4-fs (dm-18): 5 orphan inodes deleted
[  647.099710] EXT4-fs (dm-18): recovery complete
[  647.433114] EXT4-fs (dm-18): mounted filesystem with ordered data mode
[ 1080.113046] INFO: task umount:4061 blocked for more than 120 seconds.
[ 1080.113114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1080.113201] umount        D 0000000000000000     0  4061   2294 0x00000000
[ 1080.113331]  ffffffff8147b1f0 0000000000000282 0000000000000000 ffff8801e6971de8
[ 1080.113544]  0000000000000000 0000000000000000 000000000000f9e0 ffff8801e6971fd8
[ 1080.117004]  0000000000015780 0000000000015780 ffff8801c17654c0 ffff8801c17657b8
[ 1080.117004] Call Trace:
[ 1080.117004]  [<ffffffff8100e629>] ? xen_force_evtchn_callback+0x9/0xa
[ 1080.117004]  [<ffffffff8100ece2>] ? check_events+0x12/0x20
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff81109274>] ? bdi_sched_wait+0x9/0xe
[ 1080.117004]  [<ffffffff8130d19a>] ? _spin_unlock_irqrestore+0xd/0xe
[ 1080.117004]  [<ffffffff8130c3e7>] ? __wait_on_bit+0x41/0x70
[ 1080.117004]  [<ffffffff8100f0ac>] ? xen_smp_send_reschedule+0x0/0x7
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff8130c481>] ? out_of_line_wait_on_bit+0x6b/0x77
[ 1080.117004]  [<ffffffff81065f24>] ? wake_bit_function+0x0/0x23
[ 1080.117004]  [<ffffffff811092ec>] ? sync_inodes_sb+0x73/0x12a
[ 1080.117004]  [<ffffffff8110cea1>] ? __sync_filesystem+0x4b/0x70
[ 1080.117004]  [<ffffffff810f1aa2>] ? generic_shutdown_super+0x21/0xfa
[ 1080.117004]  [<ffffffff8100eccf>] ? xen_restore_fl_direct_end+0x0/0x1
[ 1080.117004]  [<ffffffff810f1b9d>] ? kill_block_super+0x22/0x3a
[ 1080.117004]  [<ffffffff810f226d>] ? deactivate_super+0x60/0x77
[ 1080.117004]  [<ffffffff81104bc0>] ? sys_umount+0x2dc/0x30b
[ 1080.117004]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b

場合によってはこのままumountできずにプロセスが残り続けて死ねる。
とりあえずディスクI/Oがロックされた状態になるんだろう。

この問題は稼働中のext4ファイルシステムのスナップショットを作成した際に起きるようだ。
おそらくジャーナルに書き出したデータが実データに反映されていないような状況でスナップショットを作成した場合に起きるんじゃないかと予測している。
のでext3でも同じ現象が起きるだろう。たぶん。
まあ、別にそれでも変更差分をきちんと吸収してくれているならかまわないんだけども、使い終わったスナップショットをアンマウントするのになんで何分もかかるのかがわからない。

その上、使用済みのスナップショットボリュームを削除しようとしても失敗することがある。

# lvremove -f /dev/ms09/snapdebian
  Unable to deactivate open ms09-debian-real (254:5)
  Failed to resume debian.

これに関してはバグレポートが見つかった。
とりあえず4ヶ月経過しても治っていないらしい。

んーむ。
こうなるとバックアップ手法を見直す必要性が出てくる。
Dom0とDomUとで疑似遠隔rsyncでバックアップとなるのだろうか。
だけどそれだとrootでのリモートログインが必要となるから駄目だな。
ゲストはゲストでバックアップパーティションをディスクとしてアタッチして、各自でバックアップしてもらうような形ならいけるか。

あー、設定するのがめんどくさい。

Linux, PC

xen-toolsを使わないでdebianホストをセットアップ

コメントをどうぞ

ファイルサーバのHDDが死にかけたので再セットアップ。

lvmでパーティションきりきり。

で、ファイルシステム作成。

# mkfs.ext3 /dev/fileserver/fssystem
# mkswap /dev/fileserver/fsswap
# mkfs.ext4 /dev/fileserver/file

ベースシステムのセットアップ。

# mount /dev/fileserver/fssystem /mnt/temp
# debootstrap --arch=amd64 lenny /mnt/temp http://ftp.jp.debian.org/debian

いろいろと書き換え

fstabの設定
# cd temp
# vi etc/fstab

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/xvda1      none            swap    sw              0       0
/dev/xvda2      /               ext3    errors=remount-ro 0     1
/dev/xvda3      /fileserver     ext4    defaults        0       0

ホスト名の設定
# vi etc/hostname

files

hostsの設定
# vi etc/hosts

127.0.0.1       localhost
192.168.1.x     files.waterblue.net     files

nicの設定
# vi etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
 address 192.168.1.x
 network 192.168.1.0
 netmask 255.255.255.0
 broadcast 192.168.1.255
 gateway 192.168.1.1

ネームサーバの設定
# vi etc/resolv.conf

nameserver 192.168.1.x

aptの設定
# vi etc/apt/sources.list

deb http://security.debian.org/ lenny/updates main contrib non-free
deb http://ftp.jp.debian.org/debian lenny main contrib non-free

シリアルコンソールの設定
hvc0を使うようにしてttyは起動しない
# vi etc/inittab

1:2345:respawn:/sbin/getty 38400 hvc0
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

# vi etc/securetty
hvc0

hvc0の作成
# cd dev
# mknod hvc0 c 229 0

xenのDomU用設定ファイルを作る。

#
# Configuration file for the Xen instance file, created
# by xen-tools 3.9 on Sun Oct 11 14:47:01 2009.
#

#
#  Kernel + memory size
#
kernel      = '/boot/vmlinuz-2.6.32-5-xen-amd64'
ramdisk     = '/boot/initrd.img-2.6.32-2-xen-amd64'
memory      = '512'

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
 'phy:/dev/fileserver/fsswap,xvda1,w',
 'phy:/dev/fileserver/fssystem,xvda2,w',
 'phy:/dev/fileserver/file,xvda3,w',
 ]

#
#  Hostname
#
name        = 'file'

#
#  Networking
#
vif         = [ 'ip=192.168.1.x,mac=xx:xx:xx:xx:xx:xx' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

あとは/mnt/tempをアンマウントしてxm create file -cで起動してコンソールログインしてお好きに。
ちなみに、ext4ファイルシステムはカーネル2.6.26だと

# tune2fs -E test_fs /dev/fileserver/file

やってからext4devじゃないとマウントできなかった。
2.6.32だとext4じゃないとマウントできなかった。

Linux, PC

xenの仮想コンソール

コメントをどうぞ

xenでDomUを構築した際、コンソール接続したいと思うだろう。
通常、Linuxではttyが標準のキャラクタデバイスになっているが、xenでは専用の仮想コンソールデバイスがある。

それはxvcであったり、hvcだったりする。

What’s the correct console device name for my Xen PV guest

  • Xenlinux (“xenified”) kernels use “xvc0″ as the console device.
  • Upstream kernel.org pv_ops kernels use “hvc0″ as the console device

Examples of Xenlinux kernels using “xvc0″ console:

  • xen.org linux-2.6.18-xen
  • RHEL5 / CentOS5 kernel-xen 2.6.18
  • Debian Etch 2.6.18-6-xen
  • Debian Lenny 2.6.26-2-xen
  • Ubuntu 8.04 LTS “hardy heron” 2.6.24 xen kernel
  • Novell SLES 10 and SLES 11 xen kernels
  • OpenSUSE xen kernels
  • Various “xenified” forward-ports of the Novell/OpenSUSE Xen patches (2.6.29, 2.6.30, 2.6.31)

Examples of pv_ops domU kernels using “hvc0″ console:

  • All upstream/mainline kernel.org Linux kernels since 2.6.26.
  • Fedora 10, Fedora 11, Fedora 12 kernels
  • Ubuntu 8.10 2.6.27 server-kernel
  • Ubuntu 9.04 2.6.28 linux-image-server
  • Ubuntu 9.10 2.6.31 ec2-kernel

で、xenではDomUとコンソール接続する際、標準ではそのキャラクタデバイスに接続するようになっている。

キャラクタデバイスを変えたい場合は、ブートオプションでxenconsで指定する。
実際はDomUの設定ファイルの、extraを用いて以下のようにすることが多いだろう。

extra='xencons=tty'

みたいな感じで。
でも特に理由がないなら標準の方を使った方がいいんだと思う。たぶん。

でまあ、DomUのセットアップの仕方によっては、DomUにxvc0あるいはhvc0が作られなかったりすることがある。
そういう場合は、作ってやればいい。

# mknod /dev/hvc0 c 229 0

みたいな感じで。

sshでもコンソールでもログインできないときはDomUのファイルシステムをマウントして、マウント先のdevに作ってやる。

で、/etc/inittabに以下を記述

1:2345:respawn:/sbin/getty 38400 hvc0

/etc/securettyに以下を記述

hvc0

ちなみにxvcはxen virtual console, hvcはhypervisor virtual consoleの略らしい。

Linux, PC

今更なんだけど

コメントをどうぞ

xenでinitrdをDom0とDomUで同じのを使うのは基本的にはNGっていう。
というのも、DomUの（仮想）ハードウェア構成は当然Dom0とは異なる。
従って、DomUのinitrdはDomUで作成したものを利用するべきなわけだ。

んだけども、DomUで作成したものはDomUのファイルシステムにおかれるわけで、これはDomUが起動していないときならマウントして中身をみることは可能だけども、 起動しているときは当然みれず、起動前にマウントしていたら当然DomUは起動できない。
実際のところDom0から見える必要があるのは起動時だけなんだけども、起動時にDom0から見える＝DomUのファイルシステムがマウントされている＝DomUは起動できない。

となると、DomUで使うカーネルやら初期RAMディスクやらをDom0のファイルシステム上に配置するのがたぶんまともな解決方法。
だけどそれらは一度配置したあとなかなか更新がかからないなら、scpやらなんやらで移してやればいいんだけども、sidなんかで運用している場合は意外とちょいちょい更新があり面倒。
じゃあ自動で転送する仕組みを作ろう。

とここまで書いてはや数時間。
どうしたらいいものか悩んでいる。
とりあえず、転送自体はscpなりでやればよく、それはスクリプトを書けばいい。
問題はスクリプトを実行するタイミングだ。
cronで回すのはスマートじゃないし、やっぱりinitramfs-toolsが動いた後に動いてほしい。
そうすると。。。かれこれ数時間悩んだが、思いつかない。

initramfs-toolsのmanページを眺めまくったがなんとも。

とりあえず、転送スクリプトだけでも作る。

とおもったところで閃いた。

DomUを起動する時に、いったんDomUのファイルシステムをマウントして、initrdとかをDom0にコピーしてから起動するようにすればいいはずだ。

と思って何とかならないかごちゃごちゃ調べていたら、見つかった。
DomUの設定ファイルはpythonスクリプトを実行できる。
これでかつる。（pythonとか全然書き方しらないけど）

さて、pythonのお勉強を始めるのもあれなので、pythonでシェルスクリプト呼び出す方法を調べた。
osモジュールをimportしてやってos.system関数を呼び出してやればいけるようだ。
ということで、シェルスクリプトを書く。

シェルスクリプトの内容は以下のようにする。

  • DomUが利用するファイルシステムをマウント
  • マウントポイント/bootからkernelとinitrdをコピー
  • アンマウント

ということで、途中いろいろ試行錯誤はあったものの、最終的には以下のようなシェルスクリプトを書いた。

#!/bin/sh

# usage
# kernelfetch.sh DomU_Disk mount_point arch kernel_dist
# DomU_disk_path - path to DomU disk which contains DomU kernel and initrd
# mount_point - path to mount point where DomU_Disk will be mounted
# kernel_dist - Path to the directory where DomU kernel and initrd will be saved

# args check
if [ $# -ne 3 ]; then
 echo "usage: $0 DomU_Disk_path mount_point kernel_dist"
 exit 1
fi

if [ ! -d $2 -o ! -d $3 ]; then
 echo "directory not found"
 exit 2
fi

if [ -f $1 ]; then
 MOUNT_OPT="-o loop"
elif [ ! -b $1 ]; then
 echo "DomU disk not found"
 exit 3
fi

# kernel paths and names
BOOT_DIR="$2/boot/"
KERNEL_PREFIX="vmlinuz-"
INITRD_PREFIX="initrd.img-"

# mount DomU disk which contains kernels
if ! mount ${MOUNT_OPT} $1 $2; then
 echo "mount failed"
 exit 4
fi

# copy the kernel
if ! cp ${BOOT_DIR}${KERNEL_PREFIX}* ${BOOT_DIR}${INITRD_PREFIX}* $3; then
 echo "copy failed"
 umount $2
 exit 5
fi

umount $2

exit 0

このシェルスクリプトは、指定されたディスクイメージあるいはデバイスを、指定ディレクトリにマウントして、指定ディレクトリ/bootからカーネルイメージと初期RAMディスクイメージを指定したディレクトリにコピーして、アンマウントする、という流れになっている。

で、DomUの設定ファイルでこのスクリプトを実行し、持ってきたイメージを使うように書き換える。

import os

os.system('/etc/xen/scripts/kernelfetch.sh /dev/fileserver/fileserver /mnt/xentmp /etc/xen/kernel/file')

kernel      = '/etc/xen/kernel/file/vmlinuz-2.6.26-2-xen-amd64'
ramdisk     = '/etc/xen/kernel/file/initrd.img-2.6.26-2-xen-amd64'

そのほかの部分は通常のDomUの設定と同じ。
ようやくうまく動いた。

Linux, PC

xenのバージョンアップ

コメントをどうぞ

今までxen 3.2 + linuxカーネル 2.6.26-2で運用してきたんだが、思い切ってバージョンアップに踏み切った。
debianではカーネルパニック起こしまくってなかなかバージョンアップできなかったんだけども、ようやくいけたのでかきかき。

動作した組み合わせは

  • linux-image-2.6.32-5-xen-amd64
  • xen-hypervisor-3.4-amd64

の組み合わせだ。
xen 3.4と2.6.26のカーネルとかでも普通にパニックおこしたけどもこの組み合わせはいけた。
ふーやれやれっていうかんじ。

ときにxen 4.0はdebianではいつでるんだろ？
パッケージの様子をみていると、4.0.0-1~experimental.1がpending uploadsにはなってる。
そのうちexperimentalあたりからリリースされる感じだろうか。

Linux, PC

LVMのLVのresize

コメントをどうぞ

結構水青が再稼動してから時間がたっているんだけども、バックアップ環境を整備していないっていう。
まあミラーリングはしてるからあれだけど。
で、今回、RAID1でLVMな構成にするのにはまりまくって涙目になったけども、LVMを使いたい最大の目的がこのスナップショット機能なわけで、つかわないわけにはいかない。

続きを読む LVMのLVのresize →