为 OpenNebula 制作 Ubuntu 镜像

上次我们介绍了给 OpenNebula 制作 Windows 镜像,当然了少不了 Ubuntu 了,为 OpenNebula 制作 Ubuntu 镜像的步骤和制作 Windows 镜像差不多,以下是具体步骤:

首先下载需要安装的 ubuntu 版本:

$ wget http://releases.ubuntu.com/11.10/ubuntu-11.10-server-amd64.iso

创建一个 10GB 大小的 “硬盘”(raw 格式):

$ kvm-img create -f raw ubuntu.img 10G
Formatting 'ubuntu.img', fmt=raw size=10737418240

然后使用刚才下载的 ubuntu “安装盘” 和刚创建的 “硬盘” 引导启动系统,使用 -vnc 参数打开 vnc 访问,以便可以用其他机器远程登录进行安装操作:

$ sudo kvm -m 512 -cdrom ubuntu-11.10-server-amd64.iso \
-drive file=ubuntu.img -boot d -nographic -vnc :0

在其他机器上用 vnc 客户端登录后就可以看到 Ubuntu 安装界面,按照屏幕的提示完成 ubuntu 的安装工作,需要注意的是分区的时候只分一个区给 /,不要分 swap 区,以后 VPSee 将会提到如何给虚拟机加上交换分区:

$ vncviewer 172.16.39.111:5900

安装完后会自动重启,shutdown -h now 虚拟机后再按照下面命令启动刚刚安装好的虚拟机镜像 ubuntu.img,如果出现 failed to find romfile “pxe-rtf8139.bin” 的错误提示可以通过安装 kvm-pxe 解决:

$ sudo kvm -m 512 -drive file=ubuntu.img -boot c -nographic -vnc :0
kvm: pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin"

$ sudo apt-get install kvm-pxe

再次用 vnc 登录虚拟机镜像,升级和更新系统,可以安装一些必要工具,比如 OpenSSH 之类的:

$ vncviewer 172.16.39.111:5900

$ sudo update
$ sudo upgrade
$ sudo apt-get install openssh-server

创建和编辑虚拟网络配置文件,然后创建一个 OpenNebula 虚拟网络(参考:在 CentOS 上安装和配置 OpenNebula):

$ vi small_network.net
NAME = "Small network"
TYPE = FIXED

BRIDGE = br0
LEASES = [ IP="172.16.39.111"]
LEASES = [ IP="172.16.39.112"]
LEASES = [ IP="172.16.39.113"]

$ onevnet create small_network.net 

$ onevnet list
  ID USER     NAME              TYPE BRIDGE P #LEASES
   0 oneadmin Small network    Fixed    br0 N       0

创建和编辑 Ubuntu 虚拟机的启动配置文件。注意别忘了加上 ARCH = x86_64(否则无法正常启动 Ubuntu),我们刚才安装的是 Ubuntu 64位 Server 版(ubuntu-11.10-server-amd64.iso):

NAME   = ubuntu
CPU    = 1
MEMORY = 512

OS = [ ARCH = x86_64,
        BOOT = hd,
        ROOT = sda1
]

DISK = [ source   = /var/lib/one/images/ubuntu.img,
         clone    = no,
         target   = sda,
         readonly = no ]

GRAPHICS = [ type ="vnc",
             listen ="0.0.0.0",
             port = "5900" ]

NIC    = [ NETWORK = "Small network" ]

依照上面的配置在 OpenNebula 上创建一个 Ubuntu 虚拟机,等待一下 OpenNebula 会自动根据当前资源情况调度,期间不断用 onevm list 命令查看当前虚拟机的创建情况,状态会从 pend -> prol -> boot -> runn,runn 状态就表示虚拟机已经成功创建并正常运行。最后检查一下 OpenNebula 是否成功创建一个名叫 ubuntu 的虚拟机:

$ onevm create ubuntu.one

$ onevm list
   ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
   42 oneadmin   ubuntu runn   1    512M          node00 00 01:16:39

如果发现启动 Ubuntu 镜像后不能 virsh console 到 ubuntu 虚拟机的话,需要设置在 KVM 上访问 Linux 虚拟机终端,并且可以在上面的模板文件里加入:

RAW = [ type = "kvm", data = "<devices><serial type=\"pty\"><source path=\"/dev/pts/5\"/>
<target port=\"0\"/></serial><console type=\"pty\" tty=\"/dev/pts/5\"><source path=\"/dev
/pts/5\"/><target port=\"0\"/></console></devices>" ]

Linux 服务器因 CPU 温度过高自动 shutdown

昨天一台 Linux Xen 服务器莫名其妙就不能访问了,开始以为又碰到 server kernel: ip_conntrack: table full, dropping packet. 问题,没仔细看。后来过了2个小时又不能访问了,看了一下日志是服务器自己 shutdown 了,不是网络的问题。再看日志发现错误信息:

Nov 24 05:32:22 ivps kernel: ACPI: Critical trip point
Nov 24 05:32:22 ivps kernel: Critical temperature reached (76 C), shutting down.

原因是 CPU 温度过高超过了警戒温度,查一下系统默认的警戒温度是75度,所以到了76度系统就自动 shutdown 了:

# cat /proc/acpi/thermal_zone/THRM/trip_points 
critical (S5):           75 C

服务器温度有这么高吗?查看一下当前温度吓一跳,刚启动的系统又到了74度,系统马上又要 shutdown 了:

# cat /proc/acpi/thermal_zone/THRM/temperature 
temperature:             74 C

紧急做法是暂时修改默认报警温度到85度:

# echo 85:0:80:60:0 > /proc/acpi/thermal_zone/THRM/trip_points

# cat /proc/acpi/thermal_zone/THRM/trip_points 
critical (S5):           85 C

一般来说 CPU 温度超过70度都是很高的温度了,如果不是系统和程序的原因要赶紧检查服务器周围的环境,检查机房和机柜温度情况、服务器风扇、内部积灰等,让 CPU 和主板长时间工作在高温下可不是好事情。当然不同 CPU 所能耐的住的温度也不同,VPSee 推荐 Intel Core 2 Quad CPU 保持在70度以下,Intel Core i7 CPU 保持在80度以下,这样 CPU 和系统能全速工作发挥最大效率而温度又不至于损坏 CPU.

为 OpenNebula 制作 Windows 镜像

说是给 OpenNebula 做 Windows 镜像其实就是做个 KVM 上的 Windows 虚拟机而已,操作步骤无非就是:创建一个硬盘、在硬盘上安装 Windows 系统、把安装好的 Windows 镜像当作模板来复制和创建 Windows 虚拟机。

创建一个 10GB 大小的 “硬盘”(raw 格式):

$ kvm-img create -f raw windowsxp.img 10G
Formatting 'windowsxp.img', fmt=raw size=10737418240

然后使用 ISO 文件的 windowsxp.iso 安装盘来安装 Windows,注意运行 kvm 需要 root 权限,否则会出现 open /dev/kvm: Permission denied 错误:

$ sudo kvm -m 1024 -cdrom windowsxp.iso -drive file=windowsxp.img -boot d -nographic -vnc :0

在另外一台机器上启动 vnc 客户端登录完成 windows 安装:

$ vncview 172.16.39.111:5900
或者
$ vncview 172.16.39.111:0

安装完 windows 后可以进行一些必要的定制,比如打开 RDP 访问、设置防火墙不要屏蔽 RDP 和 ICMP 等。

创建和编辑虚拟网络配置文件,然后创建一个 OpenNebula 虚拟网络(参考:在 CentOS 上安装和配置 OpenNebula):

$ vi small_network.net
NAME = "Small network"
TYPE = FIXED

BRIDGE = br0
LEASES = [ IP="172.16.39.111"]
LEASES = [ IP="172.16.39.112"]
LEASES = [ IP="172.16.39.113"]

$ onevnet create small_network.net 

$ onevnet list
  ID USER     NAME              TYPE BRIDGE P #LEASES
   0 oneadmin Small network    Fixed    br0 N       0

创建和编辑 Windows XP 虚拟机的启动配置文件:

$ vi windowsxp.one

NAME  = winxp
CPU   = 1
MEMORY = 1024

OS = [ boot = hd ]

DISK = [ source  = /var/lib/one/images/windowsxp.img,
         clone    = no,
         target   = hda,
         readonly = no ]

GRAPHICS = [ type ="vnc",
             listen ="0.0.0.0",
             port = "5900" ]

FEATURES = [ acpi="yes" ]

NIC    = [ NETWORK = "Small network" ]

依照上面的配置在 OpenNebula 上创建一个 Windows 虚拟机,等待片刻后不断用 onevm list 命令查看当前虚拟机的创建情况,状态一般会从 pend -> prol -> boot -> runn,runn 状态就表示虚拟机已经成功创建并正常运行。最后检查一下 OpenNebula 是否成功创建一个名叫 winxp 的 Windows 虚拟机:

$ onevm create windowsxp.one

$ onevm list
   ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
   32 oneadmin     winxp runn   6   1024M          node00 00 00:20:26

上面的 Windows 虚拟机无法正确得到 OpenNebula 预分配的 IP 地址,需要在 Windows 里配置网络连接手动绑定静态 IP,有办法可以从 OpenNebula 那里自动获得 IP,这个问题留到以后再说。

如何删除 OpenStack Nova 僵尸实例

前天强制重启一台 OpenStack Nova 控制结点以后发现虚拟机消失,但是 euca-describe-instances 命令显示 instances 仍然是 running 的状态,使用 euca-terminate-instances 终止命令仍然无效,暂时把这样的 instance 称作“僵尸实例(zombie instance)”:

# virsh list
 Id Name                 State
----------------------------------

# euca-describe-instances 
RESERVATION	r-bkl83j20	bangcloud	default
INSTANCE	i-0000001d	ami-00000002	172.16.39.121	172.16.39.121	running	vpsee (vpseecloud, node00)	0			2011-11-10T12:45:12Z	nova	aki-00000001	ami-00000000
RESERVATION	r-j335q6ny	bangcloud	default
INSTANCE	i-0000001e	ami-00000002	172.16.39.122	172.16.39.122	running	vpsee (vpseecloud, node00)	0			2011-11-10T12:54:27Z	nova	aki-00000001	ami-00000000

# euca-terminate-instances i-0000001d
# euca-terminate-instances i-0000001e

删除 OpenStack Nova Volume 时遇到的 error_deleting 问题 这篇文章提到的解决办法一样,直接操作数据库来删除这2条僵尸实例的记录。登录 mysql,使用 nova 数据库,找出要删除 instance 的 id,然后删除:

# mysql -u root -p
Enter password:

mysql> use nova;

mysql> select * from instances;

mysql> delete from instances where id = '29';
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`nova`.`virtual_interfaces`, CONSTRAINT `virtual_interfaces_ibfk_1` FOREIGN KEY (`instance_id`) REFERENCES `instances` (`id`))

MySQL 删除 id 为 29 的 instance 时触发外键限制错误,简单的办法是暂时关闭外键检查,等删除后再打开:

mysql> SET FOREIGN_KEY_CHECKS=0;
Query OK, 0 rows affected (0.00 sec)

mysql> delete from instances where id = '29';
Query OK, 1 row affected (0.04 sec)

mysql> delete from instances where id = '30';
Query OK, 1 row affected (0.04 sec)

mysql> SET FOREIGN_KEY_CHECKS=1;
Query OK, 0 rows affected (0.00 sec)

删除 instance 29 和 30后再用 euca-describe-instances 命令验证一下:

# euca-describe-instances

服务器出现 server kernel: ip_conntrack: table full, dropping packet. 问题

昨天上午挂在 VPSee 桌子旁边墙壁上的老古董 IBM TP600E 终于发挥作用,连续报警,监视显示某台服务器丢包非常严重,甚至大多时候不能访问,终端登录系统后检查日志发现 ip_conntrack: table full, dropping packet. 错误:

# vi /var/log/messages
...
Nov  8 08:54:58 server kernel: ip_conntrack: table full, dropping packet.
Nov  8 08:55:03 server kernel: printk: 49 messages suppressed.
Nov  8 08:55:03 server kernel: ip_conntrack: table full, dropping packet.
Nov  8 08:55:08 server kernel: printk: 49 messages suppressed.
...

查看当前 ip_conntrack 记录,已经有 36271,超过了系统设置的 16640 (ip_conntrack_max 默认设置为系统内存(MB 为单位)的 16倍):

$ head /proc/slabinfo 
slabinfo - version: 2.1
# name                 : tunables    : slabdata   
ip_conntrack_expect      0      0    192   20    1 : tunables  120   60    8 : slabdata      0      0      0
ip_conntrack        36271  36216    384   10    1 : tunables   54   27    8 : slabdata   1612   1612    108

# cat /proc/sys/net/ipv4/ip_conntrack_max
16640

kernel 用 ip_conntrack 模块来记录 iptables 网络包的状态,并保存到 table 里(这个 table 在内存里),如果网络状况繁忙,比如高连接,高并发连接等会导致逐步占用这个 table 可用空间,一般这个 table 很大不容易占满并且可以自己清理,table 的记录会一直呆在 table 里占用空间直到源 IP 发一个 RST 包,但是如果出现被攻击、错误的网络配置、有问题的路由/路由器、有问题的网卡等情况的时候,就会导致源 IP 发的这个 RST 包收不到,这样就积累在 table 里,越积累越多直到占满,满了以后 iptables 就会丢包,出现外部无法连接服务器的情况。

知道问题就好办了,要么增加 table 容量以便能记录更多的连接信息(会消耗一点内存),要么就卸载 ip_conntrack 模块。

查看当前 ip_conntrack_max 设置,然后增加两倍到 131072:

# cat /proc/sys/net/ipv4/ip_conntrack_max
16640

# echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max
或者
# sysctl -w  net.ipv4.netfilter.ip_conntrack_max=131072

还有一个参数 ip_conntrack_tcp_timeout_established 需要注意,默认情况下 timeout 是5天(432000秒),需要的话可以减半:

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established 
432000

# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=216000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 216000

综合一下,最好把这些内核参数加到 sysctl.conf 文件以便系统启动后自动读取中:

# vi /etc/sysctl.conf
...
net.ipv4.netfilter.ip_conntrack_max = 131072
net.nf_conntrack_max = 131072
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 216000

还有一种办法就是直接卸载 ip_conntrack 模块,这个办法最简单,到在 /etc/sysconfig/iptables-config 文件里删除或者注释掉 ip_conntrack_netbios_ns 后重启系统:

# vi /etc/sysconfig/iptables-config
#IPTABLES_MODULES="ip_conntrack_netbios_ns"

# shutdown -r now

解决 DataSourceEc2.py[WARNING]: ‘http://169.254.169.254’ failed: url error 问题

上周在一台 Ubuntu 11.10 服务器上安装和配置 OpenStack Nova 后,上传一个从 Ubuntu 官方下载的 oneiric-server-cloudimg-amd64.tar.gz 模板,然后启动一个 Ubuntu 11.10 实例(instance)的时候过了很长时间才能从 vnc 看到 Ubuntu login: 界面,打印出终端输出结果如下,貌似系统多次尝试从 http://169.254.169.254 得到 metadata 失败:

# euca-run-instances -k vpsee -t m1.tiny ami-00000002

# euca-get-console-output i-00000128
...
[    0.980222] init: lxcguest pre-start process (57) terminated with status 1
cloud-init start-local running: Mon, 24 Oct 2011 13:19:49 +0000. up 2.61 seconds
no instance data found in start-local
ci-info: lo    : 1 127.0.0.1       255.0.0.0       
ci-info: eth0  : 1 172.16.38.2     255.255.254.0   02:16:3e:4f:61:4e
ci-info: route-0: 0.0.0.0         172.16.38.1     0.0.0.0         eth0   UG
ci-info: route-1: 172.16.38.0     0.0.0.0         255.255.254.0   eth0   U
cloud-init start running: Mon, 24 Oct 2011 13:19:52 +0000. up 5.23 seconds
2011-10-24 13:19:55,312 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [timed out]
2011-10-24 13:19:59,321 - DataSourceEc2.py[WARNING]: 'http://169.254.169.254' failed: url error [timed out]
2011-10-24 13:20:31,944 - DataSourceEc2.py[CRITICAL]: giving up on md after 208 seconds
...

找了一下资料发现网上有人用绑定 169.254.169.254 到 eth0 的办法,不过 VPSee 试了行不通。

$ sudo ip addr add 169.254.169.254/32 scope link dev eth0

metadata 的转发需要网关来完成,但是从下面的代码(nova/network/linux_net.py)来看,nova 只在 FlatDHCPManager 和 VlanManager 网络模式下调用 metadata_forward() 函数,nova 在 FlatManager 网络模式下不做任何设置,所以需要手动配置 iptable 转发 169.254.169.254 的 80 端口到 nova api 服务器上(网关)。

def metadata_forward():
    """Create forwarding rule for metadata"""
    _confirm_rule("PREROUTING", "-t nat -s 0.0.0.0/0 "
             "-d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT "
             "--to-destination %s:%s" % (FLAGS.ec2_dmz_host, FLAGS.ec2_port))

所以解决办法有两个,要么在网关(nova api 所运行的服务器)上手动运行 iptable 定向端口:

$ sudo iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.16.39.110:8773

要么改变 nova.conf 配置使用 FlatDHCPManager 模式:

$ sudo vi /etc/nova/nova.conf
--daemonize=1
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--verbose
--ec2_host=http://172.16.39.110
--osapi_host=http://172.16.39.110
--rabbit_host=172.16.39.110
--glance_api_server=172.16.39.110:9292
--routing_source_ip=172.16.39.110
--sql_connection=mysql://vpsee:[email protected]/nova
--image_service=nova.image.glance.GlanceImageService
--network_manager=nova.network.manager.FlatDHCPManager
--fixed_range=172.16.38.0/23
--flat_interface=dummy0
--public_interface=eth0

重启 nova 各个服务以后再重新启动一个新 instance 并输出 console:

# euca-run-instances -k vpsee -t m1.tiny ami-00000002

# euca-describe-instances 
RESERVATION	r-0xzn6el3	cloud	default
INSTANCE	i-00000215	ami-00000002	172.16.39.121	172.16.39.121	running	vpsee (cloud, cloud00)	0		m1.tiny	2011-10-28T12:46:52Z	nova	aki-00000001	ami-00000000

# euca-get-console-output i-00000215
...
cloud-init start-local running: Fri, 28 Oct 2011 12:47:05 +0000. up 2.94 seconds
no instance data found in start-local
ci-info: lo    : 1 127.0.0.1       255.0.0.0       
ci-info: eth0  : 1 172.16.39.121   255.255.254.0   02:16:3e:6d:9b:b6
ci-info: route-0: 0.0.0.0         172.16.38.1     0.0.0.0         eth0   UG
ci-info: route-1: 172.16.38.0     0.0.0.0         255.255.254.0   eth0   U
cloud-init start running: Fri, 28 Oct 2011 12:47:08 +0000. up 5.49 seconds
found data source: DataSourceEc2
Generating public/private rsa key pair.
...

最后用 ssh 登录刚启动的 instance 测试一下,很多朋友在这篇文章的评论里问到“我的 instance 可以 ping 通,为啥不能 ssh?”的问题,可能是 ssh 的时候忘了带上 key。需要注意的是 cloud-init 这个脚本在启动 instance 后自动把 ssh 密钥注射到了 instance,ssh 的时候需要带上 vpsee.pem(还记得启动的时候用了 # euca-run-instances -k vpsee …吗?),还需要注意的是 Ubuntu 官方下载的 oneiric-server-cloudimg-amd64.tar.gz 模板的默认用户名是 ubuntu(不是 root),不需要密码登录(用 ssh key 登录):

# ssh -i vpsee.pem [email protected]

Welcome to Ubuntu 11.10 (GNU/Linux 3.0.0-12-virtual x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Fri Oct 28 10:29:14 UTC 2011

  System load:  0.0               Processes:           54
  Usage of /:   46.2% of 1.35GB   Users logged in:     0
  Memory usage: 8%                IP address for eth0: 172.16.39.121
  Swap usage:   0%

  Graph this data and manage this system at https://landscape.canonical.com/
Get cloud support with Ubuntu Advantage Cloud Guest
  http://www.ubuntu.com/business/services/cloud
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

ubuntu@server-24:~$

AlienVPS:$5 256MB OpenVZ VPS

alienvps

AlienVPS,外星人 VPS??是 AlienLayer 的 VPS 业务部分,AlienLayer 还有做网站托管的 ufohost.net 和做服务器租用的 alienrack.com,其实都是一家。去年 AlienVPS/AlienLayer 被另一家纽约的网站服务公司 WebRulon 收购,WebRulon 还收购了 HostMonkey,HostMonkey 的一个创办人也是 Nixism 的创办人,后来 Nixism 卖给了 HostDime,好乱阿~~看样子低价吸引客户然后把整个 business 转手卖出去也是不错的赚钱办法~~难怪最近年付超低价 VPS 这么多,运作方式可能是这样:注册域名和开网站;搭个 WHMCS 管理系统;用超低价去 WebHostingTalk 和 LowEndBox 发广告吸引客户购买;在客户一年服务到期前转手卖掉 VPS 业务,卖 VPS 变成卖人了~~!他们家的 VPS 这周刚好有特价,220M RAM、19GB 硬盘、190GB 月流量只要19美元一年,人民币升值现在算下来才10块钱不到,买个做备份或 VPN 吧,不过要注意的是这款特价 VPS 的内存 220M 是 burst RAM。 国内朋友可以选择他们的拉斯维加斯机房,对中国线路比纽约机房要好,测试 IP 为:208.93.153.101(拉斯维加斯),199.167.194.101(纽约)。VPS 配置如下:

UFO 1 UFO 2
1 core 2 cores
256MB RAM 512MB RAM
512MB Burst 768MB Burst
25GB 硬盘 50GB 硬盘
250GB 流量 500GB 流量
1 IP 1 IP
5美元每月 9美元每月

服务器硬件配置信息:

Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 或者 AMD Opteron(tm) Processor 6128

xend: No such file or directory. Is xend running? 问题

昨天下午升级 一台 Xen 服务器后发现 xend 服务无法启动,启动系统后运行 xen 工具报错:

# xm list
Error: Error connecting to xend: No such file or directory.  Is xend running?

查看一下 xen 日志发现:

[2011-10-11 14:19:09 3974] ERROR (SrvDaemon:349) Exception starting xend ((13, ‘Permission denied’))
Traceback (most recent call last):
File “/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py”, line 341, in run
servers = SrvServer.create()
File “/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py”, line 251, in create
root.putChild(‘xend’, SrvRoot())
File “/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py”, line 40, in __init__
self.get(name)
File “/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py”, line 84, in get
val = val.getobj()
File “/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py”, line 52, in getobj
self.obj = klassobj()
File “/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py”, line 30, in __init__
self.xn = XendNode.instance()
File “/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py”, line 948, in instance
inst = XendNode()
File “/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py”, line 91, in __init__
self.other_config[“xen_pagesize”] = self.xeninfo_dict()[“xen_pagesize”]
File “/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py”, line 937, in xeninfo_dict
return dict(self.xeninfo())
File “/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py”, line 881, in xeninfo
info[‘xen_scheduler’] = self.xenschedinfo()
File “/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py”, line 871, in xenschedinfo
sched_id = self.xc.sched_id_get()
Error: (13, ‘Permission denied’)

后来看了一下管理员的系统维护日志发现这个系统使用的不是 centos 自带的 xen,用的是升级过的 xen 3.4.3,大致可以猜到错误原因了,这种问题一般是升级后 xen 内核和 xen 工具不匹配造成的。查看 grub.conf 发现 yum upgrade 后自动添加的启动条目里使用了新的 xen 内核,这个新的内核和系统上的现有 xen 工具不匹配:

title CentOS (2.6.18-274.3.1.el5xen)
        root (hd0,0)
        kernel /xen.gz-2.6.18-274.3.1.el5
        module /vmlinuz-2.6.18-274.3.1.el5xen ro root=/dev/VolGroup00/LogVol00
        module /initrd-2.6.18-274.3.1.el5xen.img

要解决这个问题的话只需要恢复使用以前的 xen 内核就可以了:

title CentOS (2.6.18-274.3.1.el5xen)
        root (hd0,0)
        kernel /xen.gz-3.4.3
        module /vmlinuz-2.6.18-274.3.1.el5xen ro root=/dev/VolGroup00/LogVol00
        module /initrd-2.6.18-274.3.1.el5xen.img

Thanks, Steve

(This image is modified from Jonathan Mak)

steve jobs 1955-2011

QualityServers:£25 256MB Xen VPS

qualityservers

QualityServers 其实和另一个我们熟悉的英国 VPS 公司 QuickVPS Ltd 是一家,现在 quickvps.co.uk 的域名也指向 qualityservers 了。Quick Ltd 成立于2009年,办公地点在 Lancaster 大学的 Knowledge Business Centre,貌似一个大学生创业公司/项目,否则也不会很容易在大学里租用办公室和网络了。QualityServers 经常发一些优惠,这次是个年付25英镑的 256MB Xen VPS,点击这个链接可以购买。用 VPS 做站不喜欢备份的朋友建议买个这种便宜的 VPS 做备份,两个 VPS 每天 rync 一下就可以,备份的成本很低但是有时候可以救命,还是很划算的~。他们的服务器租用的是 BurstNET UK 的设备,测试 IP 为 217.114.63.178。LowEndBox 上对这家的好评不少,对欧洲线路不感冒的同鞋可以玩一下。VPS 配置如下:

256MB RAM/256MB Swap
10GB 硬盘
每月 750GB 流量
1 IPv4 + 1 IPv6
25英镑每年

服务器硬件配置信息:

2x QC Intel Xeon 5335 @ 2GHz, 16GB RAM, 4x 500GB SATA2 in RAID10, 100Mbit dedicated uplink