为 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:vpsee@172.16.39.110/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 ubuntu@172.16.39.121

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

如何知道 OpenStack Nova 的安装版本号?

安装完 OpenStack Nova 以后过段时间就很容易忘记自己装的是哪个版本,OpenStack 开发进度很快,遇到问题到 mailing list 寻求帮助的时候最好带上 Nova 的版本号。如何知道自己安装的是哪个版本的 OpenStack Nova 呢?旧版本的 OpenStack Nova 提供了 version 的接口,不过只是针对开发人员,命令行工具没有面向系统管理员的接口,所以只能通过 python 调取 nava API 来获得version 信息:

# nova-manage shell python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from nova import version
>>> version.version_string()
'2011.2'
>>> version.version_string_with_vcs()
u'2011.2-workspace:tarmac-20110415024701-a9bdb77vaatk99lh'
>>>

新版本的 OpenStack Nova 提供了简单的管理员接口,不再需要通过 API 调用了:

# nova-manage version list
2011.3-dev (2011.3-workspace:tarmac-20110428165803-elcz2wp2syfzvxm8)

删除 OpenStack Nova Volume 时遇到的 error_deleting 问题

前段时间 VPSee 在 OpenStack Nova 上删除一个 volume 的时候(vol-00000002)报错,检查了一下 volume 的状态是 error_deleting 然后就无法删除了,不管用 euca-delete-volume 还是 nova-manage volume delete 都无法删除。

# euca-delete-volume vol-00000002
ApiError: ApiError: Volume status must be available

# euca-describe-volumes
VOLUME	vol-00000002  10  nova	error_deleting (mycloud, node01, None, None)	2011-08-30T13:15:24Z
VOLUME	vol-00000003  10  nova	available (mycloud, node01, None, None)	2011-08-30T13:20:04Z

查了一下要删除的 volume-00000002 的情况:

# lvdisplay
...
--- Logical volume ---
  LV Name                /dev/nova-volumes/volume-00000002
  VG Name                nova-volumes
  LV UUID                UgOwdr-W61E-MrdG-PrdY-IToa-LBi8-2XJjXF
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                10.00 GiB
  Current LE             2560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           251:2
...

既然用工具没法删除的话就干脆从数据库里直接删除,无非就是一条记录而已,先从 nova 数据库里找到这条 volume 记录并设置状态为 deleted,然后删除实际对应的 LVM. 从数据库里找到相应的表和记录后设置 status 为 deleted 状态:

# mysql -u root -p
Enter password:

mysql> use nova;

mysql> select status,id from volumes;
+----------------+----+
| status         | id |
+----------------+----+
| creating       |  1 |
| error_deleting |  2 |
| available      |  3 |
+----------------+----+
3 rows in set (0.00 sec)

mysql> update volumes set status='deleted' where id='2';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

退出 mysql 数据库操作回到命令行就会看到 vol-00000002 的状态是 deleted 的,然后用 lvmremove 命令删除:

# euca-describe-volumes
VOLUME	vol-00000002  10  nova	deleted (mycloud, node01, None, None)	2011-08-30T13:15:24Z

# ls /dev/nova-volumes/
volume-00000002 volume-00000003

# lvremove /dev/nova-volumes/volume-00000002
Do you really want to remove active logical volume volume-00000002? [y/n]: y
  Logical volume "volume-00000002" successfully removed

最后用 nova-manage 命令从数据库里彻底删除 vol-00000002(当然也可以直接在 mysql 里用 SQL 语句操作删除对应的记录 DELETE FROM volumes WHERE id=’2′;):

# nova-manage volume delete vol-00000002

# euca-describe-volumes
VOLUME	vol-00000003  10  nova	available (mycloud, node01, None, None)	2011-08-30T13:20:04Z