nova-volumeがattachingでハングしてしまいます。
411 views
Skip to first unread message
Koji Tanaka
Jun 5, 2012, 2:11:32 PM6/5/12
to openst...@googlegroups.com
こんにちは。
田仲ともうします。
ただいま、Ubuntu12.04でExxexをVlanManagerで構築中なのですが、Volumeだけがどうしても正常に動作してくれません。その他は大丈夫です。
[ 症状 ]
インスタンスを起動する際にDashboardにてVolumeをアタッチすることはできるのですが、デタッチした後にアタッチすることはできず、Attatchingのまま止まってしまいます。euca-attach-volumeも同様の症状です。
どなたか同じ症状になった方はおりますか？Novaのログも、libvirtのログもsyslogからも有用な情報が見つからなくて困ってます。エラーを吐いてくれると何か分かりそうなのですが・・・、Dashboardではアタッチできるので、novaではなくてlibvirtかkvmの設定がnovaの設定と噛み合ってないのではと想像してます。
とりあえずわかったことなのですが、下記の手順でボリュームをavailableな状態にロールバックすることはできてます。
[ 手順 ]
nova-computeのマシンにログインして、libvirt-binをrestartして、iscsiadmin -m session -r <iscsi_volume_id> -u をするとボリュームをリリースすることはできます。
それと、どうやらEssexではiscsiのdiscoveryは使ってないそうで、iscsi-ip-prefixをnova-computeに設定するのではなく、iscsi-ip-addressをnova-volumeノードに設定するとのことです。僕はそれをつい最近知りました。
これが僕のはじめてのメール送信となります。
まだまだ素人ですが、今後ともよろしくお願い致します。
田仲
田仲ともうします。
ただいま、Ubuntu12.04でExxexをVlanManagerで構築中なのですが、Volumeだけがどうしても正常に動作してくれません。その他は大丈夫です。
[ 症状 ]
インスタンスを起動する際にDashboardにてVolumeをアタッチすることはできるのですが、デタッチした後にアタッチすることはできず、Attatchingのまま止まってしまいます。euca-attach-volumeも同様の症状です。
どなたか同じ症状になった方はおりますか？Novaのログも、libvirtのログもsyslogからも有用な情報が見つからなくて困ってます。エラーを吐いてくれると何か分かりそうなのですが・・・、Dashboardではアタッチできるので、novaではなくてlibvirtかkvmの設定がnovaの設定と噛み合ってないのではと想像してます。
とりあえずわかったことなのですが、下記の手順でボリュームをavailableな状態にロールバックすることはできてます。
[ 手順 ]
nova-computeのマシンにログインして、libvirt-binをrestartして、iscsiadmin -m session -r <iscsi_volume_id> -u をするとボリュームをリリースすることはできます。
それと、どうやらEssexではiscsiのdiscoveryは使ってないそうで、iscsi-ip-prefixをnova-computeに設定するのではなく、iscsi-ip-addressをnova-volumeノードに設定するとのことです。僕はそれをつい最近知りました。
これが僕のはじめてのメール送信となります。
まだまだ素人ですが、今後ともよろしくお願い致します。
田仲
Tomoaki Nakajima
Jun 5, 2012, 10:20:14 PM6/5/12
to openst...@googlegroups.com
田仲さん
お世話になります。中島と申します。
openstackはubuntuのパッケージを使用されていますか？
gitブランチから取得したもの、launchpadからダウンロード、
各ディストリビューターが配布しているもの、
それぞれ同じessexでも微妙に違いますので、
まずはdevstackでessexブランチを使って確認されるといいと思います。
またopenstackはos側の環境(tgtバージョンとか)にも強く依存しますので、
ubuntuのバージョンにも注意してみて下さい。
(私はrhel系で動かしているので、ubuntuでどのバージョンがデファクトなのかわかりませんが・・・)
手元に環境がないので確認できないため、こんな回答で申し訳ないです。
よろしくお願いいたします。
お世話になります。中島と申します。
openstackはubuntuのパッケージを使用されていますか？
gitブランチから取得したもの、launchpadからダウンロード、
各ディストリビューターが配布しているもの、
それぞれ同じessexでも微妙に違いますので、
まずはdevstackでessexブランチを使って確認されるといいと思います。
またopenstackはos側の環境(tgtバージョンとか)にも強く依存しますので、
ubuntuのバージョンにも注意してみて下さい。
(私はrhel系で動かしているので、ubuntuでどのバージョンがデファクトなのかわかりませんが・・・)
手元に環境がないので確認できないため、こんな回答で申し訳ないです。
よろしくお願いいたします。
hyuntae park
Jun 5, 2012, 10:34:06 PM6/5/12
to openst...@googlegroups.com
こんにちは。
朴玄泰ともうします。
早速伺いたいのですが、インスタンスの起動状態によって、動作が変わってきたりしませんか。
たとえば、「起動中」にはできないのに、「停止中」にはできたりなど。
Essexはまだ使ったことがないので、何とも言えませんが、
Diablo時にはインスタンスの起動状態によって、動作が微妙に変わってきた気がします。
以上、よろしくお願いします。
朴玄泰ともうします。
早速伺いたいのですが、インスタンスの起動状態によって、動作が変わってきたりしませんか。
たとえば、「起動中」にはできないのに、「停止中」にはできたりなど。
Essexはまだ使ったことがないので、何とも言えませんが、
Diablo時にはインスタンスの起動状態によって、動作が微妙に変わってきた気がします。
以上、よろしくお願いします。
2012年6月6日 3:11 Koji Tanaka <kj.t...@gmail.com>:
萩原 司朗
Jun 5, 2012, 10:50:37 PM6/5/12
to openst...@googlegroups.com, openst...@googlegroups.com
田仲さん
萩原です。
nova-volumeのログとnova.confがあれば、もしかしたらもう少しわかることがあるのかなと思います。
Koji Tanaka
Jun 6, 2012, 12:36:36 AM6/6/12
to openst...@googlegroups.com
みなさん、ありがとうございます。
私のEssexはUbuntu12.04のパッケージです。gitはまだ試したことがなく、主に下記２つのリンクを参考に構築しました。見よう見まねなのでそんなに自信はありません。私が数カ月前に試したDiabloのFlatDHCPではvolumeはもう少しすんなりアタッチできたように覚えてます。
http://www.hastexo.com/resources/docs/installing-openstack-essex-20121-ubuntu-1204-precise-pangolin
http://dodeeric.wordpress.com/2012/04/29/install-your-own-openstack-cloud-essex-edition/
僕のnova.confは下記のとおりです。--iscsi_ip_address=172.20.1.1はvolumeノードにだけつけていますが--my_ipとそれ以外はどれも同じです。
##### RabbitMQ #####
--rabbit_host=192.168.1.1
##### MySQL #####
--sql_connection=mysql://novadbadmin:XXXX...@172.20.1.1/nova
##### nova-api #####
--auth_strategy=keystone
--cc_host=192.168.1.1
##### ec2 and s3 #####
--ec2_host = 172.20.1.1
--s3_host = 172.20.1.1
##### nova-network #####
--network_manager=nova.network.manager.VlanManager
--public_interface=eth1
--vlan_interface=eth0
--vlan_start=101
--network_host=192.168.1.1
--fixed_range=10.2.0.0/16
--dmz_cidr=192.168.1.0/24
--network_size=1024
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--force_dhcp_release=True
--fixed_ip_disassociate_timeout=30
--my_ip=192.168.1.1
--routing_source_ip=172.20.1.1
##### nova-compute #####
--connection_type=libvirt
--libvirt_type=kvm
--libvirt_use_virtio_for_bridges=True
--use_cow_images=True
--snapshot_image_format=qcow2
--start_guests_on_host_boot=true
--resume_guests_state_on_host_boot=true
##### nova-volume #####
--iscsi_ip_address=172.20.1.1
--num_iscsi_scan_tries=3
--num_targets=100
--iscsi_helper=tgtadm
##### nova-scheduler #####
--scheduler_driver=nova.scheduler.simple.SimpleScheduler
##### glance #####
--image_service=nova.image.glance.GlanceImageService
--glance_api_servers=172.20.1.1:9292
##### Misc #####
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--root_helper=sudo nova-rootwrap
--verbose=true
##### Keystone #####
--keystone_ec2_url = http://172.20.1.1:5000/v2.0/ec2tokens
##### Zone #####
--storage_availability_zone = nova_dev
--node_availability_zone = nova_dev
--default_schedule_zone= nova_dev
nova-volumeのログは下記のようになってます。
2012-06-05 23:58:57 DEBUG nova.rpc.amqp [-] received {u'_context_roles': [u'KeystoneAdmin', u'admin', u'KeystoneServiceAdmin'], u'_msg_id': u'eed9a935ae1c48fbb3405f6558656559', u'_context_read_deleted': u'no', u'_context_request_id': u'req-caf4c806-15c0-4e39-acb9-a81e9ed9b666', u'args': {u'connector': {u'ip': u'192.168.1.1', u'initiator': u'iqn.1993-08.org.debian:01:5255efa0af2f'}, u'volume_id': 4}, u'_context_auth_token': '<SANITIZED>', u'_context_is_admin': True, u'_context_project_id': u'f07ca073f69648708d0480da9d761a42', u'_context_timestamp': u'2012-06-06T03:58:57.479098', u'_context_user_id': u'22783796c597492dbb05f149aff16238', u'method': u'initialize_connection', u'_context_remote_address': u'172.20.1.1'} from (pid=5821) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-06-05 23:58:57 DEBUG nova.rpc.amqp [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] unpacked context: {'user_id': u'22783796c597492dbb05f149aff16238', 'roles': [u'KeystoneAdmin', u'admin', u'KeystoneServiceAdmin'], 'timestamp': '2012-06-06T03:58:57.479098', 'auth_token': '<SANITIZED>', 'remote_address': u'172.20.1.1', 'is_admin': True, 'request_id': u'req-caf4c806-15c0-4e39-acb9-a81e9ed9b666', 'project_id': u'f07ca073f69648708d0480da9d761a42', 'read_deleted': u'no'} from (pid=5821) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
なんとなくnova-volumeよりもnova-computeのプロセスで止まっているような感がするので、nova-computeのログも添付します。。。
Login to [iface: default, target: iqn.2010-10.org.openstack:volume-00000004, portal: 192.168.1.1,3260]: successful
stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:114
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: iscsiadm ('--login',): stdout=Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-00000004, portal: 192.168.1.1,3260]
Login to [iface: default, target: iqn.2010-10.org.openstack:volume-00000004, portal: 192.168.1.1,3260]: successful
stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:116
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: _iscsiadm_update from (pid=5773) _iscsiadm_update /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:120
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: _run_iscsiadm from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:106
2012-06-05 23:58:59 DEBUG nova.utils [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] Running cmd (subprocess): sudo nova-rootwrap iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000004 -p 192.168.1.1:3260 --op update -n node.startup -v automatic from (pid=5773) execute /usr/lib/python2.7/dist-packages/nova/utils.py:219
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'automatic'): stdout= stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:114
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'automatic'): stdout= stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:116
このログの最後のvolume.py:116ではどうやら下記のコマンドを実行しているのですが、この動作自体は手動でも問題なくiscsiボリュームをアタッチできました。
iscsiadm --mode node --targetname iqn.2010-10.org.openstack:volume-00000004 -p 192.168.1.1,3260 --login
このあとにlibvirtにxmlかなにかでボリュームの情報を手渡してinstanceにアタッチしようとして、そこで問題が起こっているように見えるのですが、エラーが出ずにハングしているのでまだよくわかりません。今日はとめどないグーグル検索をやめて、volume.pyのコードの中にデバッグのラインを付け足してハングしているコマンドを手探りしていますが、まだ解決できてません。
tgtのバージョンは1:1.0.17-1ubuntu2
libvirtのバージョンは0.9.8-2ubuntu17.1
qemu-kvmのバージョンは1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu13
となっています。
長くなってしまってすみませんが、
どうぞよろしくお願いいたします。
田仲
私のEssexはUbuntu12.04のパッケージです。gitはまだ試したことがなく、主に下記２つのリンクを参考に構築しました。見よう見まねなのでそんなに自信はありません。私が数カ月前に試したDiabloのFlatDHCPではvolumeはもう少しすんなりアタッチできたように覚えてます。
http://www.hastexo.com/resources/docs/installing-openstack-essex-20121-ubuntu-1204-precise-pangolin
http://dodeeric.wordpress.com/2012/04/29/install-your-own-openstack-cloud-essex-edition/
僕のnova.confは下記のとおりです。--iscsi_ip_address=172.20.1.1はvolumeノードにだけつけていますが--my_ipとそれ以外はどれも同じです。
##### RabbitMQ #####
--rabbit_host=192.168.1.1
##### MySQL #####
--sql_connection=mysql://novadbadmin:XXXX...@172.20.1.1/nova
##### nova-api #####
--auth_strategy=keystone
--cc_host=192.168.1.1
##### ec2 and s3 #####
--ec2_host = 172.20.1.1
--s3_host = 172.20.1.1
##### nova-network #####
--network_manager=nova.network.manager.VlanManager
--public_interface=eth1
--vlan_interface=eth0
--vlan_start=101
--network_host=192.168.1.1
--fixed_range=10.2.0.0/16
--dmz_cidr=192.168.1.0/24
--network_size=1024
--dhcpbridge_flagfile=/etc/nova/nova.conf
--dhcpbridge=/usr/bin/nova-dhcpbridge
--force_dhcp_release=True
--fixed_ip_disassociate_timeout=30
--my_ip=192.168.1.1
--routing_source_ip=172.20.1.1
##### nova-compute #####
--connection_type=libvirt
--libvirt_type=kvm
--libvirt_use_virtio_for_bridges=True
--use_cow_images=True
--snapshot_image_format=qcow2
--start_guests_on_host_boot=true
--resume_guests_state_on_host_boot=true
##### nova-volume #####
--iscsi_ip_address=172.20.1.1
--num_iscsi_scan_tries=3
--num_targets=100
--iscsi_helper=tgtadm
##### nova-scheduler #####
--scheduler_driver=nova.scheduler.simple.SimpleScheduler
##### glance #####
--image_service=nova.image.glance.GlanceImageService
--glance_api_servers=172.20.1.1:9292
##### Misc #####
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--root_helper=sudo nova-rootwrap
--verbose=true
##### Keystone #####
--keystone_ec2_url = http://172.20.1.1:5000/v2.0/ec2tokens
##### Zone #####
--storage_availability_zone = nova_dev
--node_availability_zone = nova_dev
--default_schedule_zone= nova_dev
nova-volumeのログは下記のようになってます。
2012-06-05 23:58:57 DEBUG nova.rpc.amqp [-] received {u'_context_roles': [u'KeystoneAdmin', u'admin', u'KeystoneServiceAdmin'], u'_msg_id': u'eed9a935ae1c48fbb3405f6558656559', u'_context_read_deleted': u'no', u'_context_request_id': u'req-caf4c806-15c0-4e39-acb9-a81e9ed9b666', u'args': {u'connector': {u'ip': u'192.168.1.1', u'initiator': u'iqn.1993-08.org.debian:01:5255efa0af2f'}, u'volume_id': 4}, u'_context_auth_token': '<SANITIZED>', u'_context_is_admin': True, u'_context_project_id': u'f07ca073f69648708d0480da9d761a42', u'_context_timestamp': u'2012-06-06T03:58:57.479098', u'_context_user_id': u'22783796c597492dbb05f149aff16238', u'method': u'initialize_connection', u'_context_remote_address': u'172.20.1.1'} from (pid=5821) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-06-05 23:58:57 DEBUG nova.rpc.amqp [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] unpacked context: {'user_id': u'22783796c597492dbb05f149aff16238', 'roles': [u'KeystoneAdmin', u'admin', u'KeystoneServiceAdmin'], 'timestamp': '2012-06-06T03:58:57.479098', 'auth_token': '<SANITIZED>', 'remote_address': u'172.20.1.1', 'is_admin': True, 'request_id': u'req-caf4c806-15c0-4e39-acb9-a81e9ed9b666', 'project_id': u'f07ca073f69648708d0480da9d761a42', 'read_deleted': u'no'} from (pid=5821) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
なんとなくnova-volumeよりもnova-computeのプロセスで止まっているような感がするので、nova-computeのログも添付します。。。
Login to [iface: default, target: iqn.2010-10.org.openstack:volume-00000004, portal: 192.168.1.1,3260]: successful
stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:114
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: iscsiadm ('--login',): stdout=Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-00000004, portal: 192.168.1.1,3260]
Login to [iface: default, target: iqn.2010-10.org.openstack:volume-00000004, portal: 192.168.1.1,3260]: successful
stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:116
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: _iscsiadm_update from (pid=5773) _iscsiadm_update /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:120
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: _run_iscsiadm from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:106
2012-06-05 23:58:59 DEBUG nova.utils [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] Running cmd (subprocess): sudo nova-rootwrap iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000004 -p 192.168.1.1:3260 --op update -n node.startup -v automatic from (pid=5773) execute /usr/lib/python2.7/dist-packages/nova/utils.py:219
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'automatic'): stdout= stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:114
2012-06-05 23:58:59 DEBUG nova.virt.libvirt.volume [req-caf4c806-15c0-4e39-acb9-a81e9ed9b666 22783796c597492dbb05f149aff16238 f07ca073f69648708d0480da9d761a42] ktanaka: iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'automatic'): stdout= stderr= from (pid=5773) _run_iscsiadm /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py:116
このログの最後のvolume.py:116ではどうやら下記のコマンドを実行しているのですが、この動作自体は手動でも問題なくiscsiボリュームをアタッチできました。
iscsiadm --mode node --targetname iqn.2010-10.org.openstack:volume-00000004 -p 192.168.1.1,3260 --login
このあとにlibvirtにxmlかなにかでボリュームの情報を手渡してinstanceにアタッチしようとして、そこで問題が起こっているように見えるのですが、エラーが出ずにハングしているのでまだよくわかりません。今日はとめどないグーグル検索をやめて、volume.pyのコードの中にデバッグのラインを付け足してハングしているコマンドを手探りしていますが、まだ解決できてません。
tgtのバージョンは1:1.0.17-1ubuntu2
libvirtのバージョンは0.9.8-2ubuntu17.1
qemu-kvmのバージョンは1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu13
となっています。
長くなってしまってすみませんが、
どうぞよろしくお願いいたします。
田仲
2012/6/5 萩原 司朗 <hagi...@fulltrust.co.jp>
Koji Tanaka
Jun 6, 2012, 12:44:44 AM6/6/12
to openst...@googlegroups.com
みなさん、すみません。。。先ほどのメールでは試行錯誤中の古いnova.confを添付してしまいました。こちらが現在のnova.confです。--iscsi_ip_addressは172.20.1.1ではなく、192.168.1.1です。
--num_iscsi_scan_tries=3
--num_targets=100
--iscsi_helper=tgtadm
##### nova-scheduler #####
--scheduler_driver=nova.scheduler.simple.SimpleScheduler
##### glance #####
--image_service=nova.image.glance.GlanceImageService
--glance_api_servers=172.20.1.1:9292
##### Misc #####
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--root_helper=sudo nova-rootwrap
--verbose=true
##### Keystone #####
--keystone_ec2_url = http://172.20.1.1:5000/v2.0/ec2tokens
##### Zone #####
--storage_availability_zone = nova_dev
--node_availability_zone = nova_dev
--default_schedule_zone= nova_dev
田仲
--iscsi_ip_address=192.168.1.1
--num_iscsi_scan_tries=3
--num_targets=100
--iscsi_helper=tgtadm
##### nova-scheduler #####
--scheduler_driver=nova.scheduler.simple.SimpleScheduler
##### glance #####
--image_service=nova.image.glance.GlanceImageService
--glance_api_servers=172.20.1.1:9292
##### Misc #####
--logdir=/var/log/nova
--state_path=/var/lib/nova
--lock_path=/var/lock/nova
--root_helper=sudo nova-rootwrap
--verbose=true
##### Keystone #####
--keystone_ec2_url = http://172.20.1.1:5000/v2.0/ec2tokens
##### Zone #####
--storage_availability_zone = nova_dev
--node_availability_zone = nova_dev
--default_schedule_zone= nova_dev
田仲
2012/6/6 Koji Tanaka <kj.t...@gmail.com>
Koji Tanaka
Jun 6, 2012, 4:37:01 PM6/6/12
to openst...@googlegroups.com
みなさま、
先日メールでお尋ねしたnova-volumeの件ですが、同様の環境で同じ症状の方がありました。もし同じ現象が起こった方がおられたら、下記のリンクをご参考にされてください。
https://bugs.launchpad.net/nova/+bug/996840/comments/4
この方が書いているとおり、僕も構築後しばらくはアタッチできてたんです。変ですね。
よろしくお願い致します。
先日メールでお尋ねしたnova-volumeの件ですが、同様の環境で同じ症状の方がありました。もし同じ現象が起こった方がおられたら、下記のリンクをご参考にされてください。
https://bugs.launchpad.net/nova/+bug/996840/comments/4
この方が書いているとおり、僕も構築後しばらくはアタッチできてたんです。変ですね。
よろしくお願い致します。
萩原司朗
Jun 6, 2012, 9:38:29 PM6/6/12
to openst...@googlegroups.com
萩原です。
--
######################################################################
株式会社 フルトラスト : Fulltrust.inc
東京都台東区松が谷2-23-4 マーサアパートメントハウス 701号
萩原 司朗 / Shiro,Hagihara / Chief Executive Officer
Tel: 03-6231-6790 / Fax:03-6231-6792 / PHS:070-5456-2553
E-Mail : hagi...@fulltrust.co.jp / URL : http://www.fulltrust.co.jp
#######################################################################
パッケージでもソースでもデタッチ後のアタッチは特に何も問題なく行えてしまいます。
デタッチちゃんとしないとおかしくなったりデタッチ後の削除を何度もしないと消えなかったりとかの挙動不審なところはありますけども。
nova.confくらいしか違いは無いと思うんですけどね。
--が謎の動作を引き起こしてるとか。
関係ないかもしれませんが新しい書き方にしてみるとかダメですかね。
以上です。
[DEFAULT]
#verbose=true
allow_admin_api=true
api_paste_config=/etc/nova/api-paste.ini
instances_path=/var/lib/nova/instances
connection_type=libvirt
root_helper=sudo nova-rootwrap
multi_host=true
send_arp_for_ha=true
#behavior of an instance of when the host has been started
start_guests_on_host_boot=true
resume_guests_state_on_host_boot=true
#logging and other administrative
logdir=/var/log/nova
state_path=/var/lib/nova
lock_path=/var/lock/nova
#network
libvirt_use_virtio_for_bridges = true
network_manager=nova.network.manager.FlatDHCPManager
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
public_interface=eth0
flat_interface=eth0
flat_network_bridge=br100
fixed_range=10.0.0.0/8
flat_network_dhcp_start=10.0.0.2
network_size=255
force_dhcp_release = true
flat_injected=false
use_ipv6=false
#vnc
novncproxy_base_url=http://192.168.10.50:6080/vnc_auto.html
xvpvncproxy_base_url=http://192.168.10.50:6081/console
#vnc compute node ip override
vncserver_proxyclient_address=192.168.10.50
vncserver_listen=192.168.10.50
vnc_keymap=ja
#scheduler
scheduler_driver=nova.scheduler.simple.SimpleScheduler
#object
s3_host=stack01
use_cow_images=yes
#glance
image_service=nova.image.glance.GlanceImageService
glance_api_servers=stack01:9292
#rabbit
rabbit_host=stack01
rabbit_virtual_host=/nova
rabbit_userid=nova
rabbit_password=password
#nova database
sql_connection=mysql://nova:password@stack01/nova
#volumes
volume_group=nova-volumes
aoe_eth_dev=eth0
iscsi_ip_prefix=10.
iscsi_helper=tgtadm
#keystone
auth_strategy=keystone
keystone_ec2_url=http://stack01:5000/v2.0/ec2tokens
#memcache
memcached_servers=stack01:11211
2012年6月7日 5:37 Koji Tanaka <kj.t...@gmail.com>:
######################################################################
株式会社 フルトラスト : Fulltrust.inc
東京都台東区松が谷2-23-4 マーサアパートメントハウス 701号
萩原 司朗 / Shiro,Hagihara / Chief Executive Officer
Tel: 03-6231-6790 / Fax:03-6231-6792 / PHS:070-5456-2553
E-Mail : hagi...@fulltrust.co.jp / URL : http://www.fulltrust.co.jp
#######################################################################
Koji Tanaka
Jun 6, 2012, 10:35:24 PM6/6/12
to openst...@googlegroups.com
萩原さん、
どうもありがとうございます。おっしゃるとおり僕もnova.confを疑いつづけたのですがコードをにらみながらキーワードを変えてグーグル検索していたところ、下記リンクにたどり着きました。どうやらlibvirtのバグのようです。
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/996840
僕の現象はレスの中のHendrikさんの現象と全く同じで、構築後しばらく正常に動いてたので、ここ数日は同僚にかなり冷たい疑いの目で見られてました。。。Hendrikさんは代替方法としてlibvirt APIではなくvirsh attach-diskコマンドを使うパッチをポストしてくれてるのでそのパッチを当てたところ今は動いてくれてます。ハングしてログが出ないので困りものですね。。。
田仲
どうもありがとうございます。おっしゃるとおり僕もnova.confを疑いつづけたのですがコードをにらみながらキーワードを変えてグーグル検索していたところ、下記リンクにたどり着きました。どうやらlibvirtのバグのようです。
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/996840
僕の現象はレスの中のHendrikさんの現象と全く同じで、構築後しばらく正常に動いてたので、ここ数日は同僚にかなり冷たい疑いの目で見られてました。。。Hendrikさんは代替方法としてlibvirt APIではなくvirsh attach-diskコマンドを使うパッチをポストしてくれてるのでそのパッチを当てたところ今は動いてくれてます。ハングしてログが出ないので困りものですね。。。
田仲
2012/6/6 萩原司朗 <hagi...@fulltrust.co.jp>
Reply all
Reply to author
Forward
0 new messages