[cloudstack-users:0177] Re: 【質問】CloudStackへの基本ゾーンの作成（XenServer）でシステムVMが起動できない

2013年 5月 20日 (月) 21:40:33 JST

松浦様

二河です。

いつもありがとうございます。

>コンピュートノードから、

>プライマリストレージ(=/home/primary)をマウントした際に

>nobodyになってしまう現象は回避された。

>ということでよろしいでしょうか?

こちらは解消されました。

それでもNGな状態です。

management-server.logの出力は変化がありません。

システムVM作成の物理的な登場人物として、

・NFSサーバのプライマリ領域

・NFSサーバのセカンダリ領域に格納したシステムVMのテンプレート（展開に成功している）

・Hypervisorホスト（プライマリ領域をNFSv4でマウントさせ、rootで書き込みが可能。nobody:nobodyにならない）

があると思います。

（管理サーバのGUIは別。裏で動いているのは上記のみという認識です）

NFSの問題が現時点で掘り下げられない場合、

システムVMのテンプレートの展開に問題があるのか…と思い、

先ほどの投稿をさせていただいた次第です。

よろしくお願いいたします。

From: 松浦直樹 [mailto:matsuura.naoki ＠ pinetree-bay.com] 
Sent: Monday, May 20, 2013 6:53 PM
To: 二河 等
Cc: users ＠ cloudstack.jp
Subject: Re: [cloudstack-users:0162] Re: 【質問】CloudStackへの基本ゾーンの作成（XenServer）でシステムVMが起動できない

二河様

松浦です。

>CloudStackの管理サーバのUIからゾーンを作成する際に、

>プライマリストレージをマウントする際に利用されるNFSのバージョンはいくつになるのでしょうか？

>（一説ではv4と聞いています）

 CentOS 6 であれば、NFSv４でよいと思いますが、、

nfsstat -m で確認できるようです。

コンピュートノードから、

プライマリストレージ(=/home/primary)をマウントした際に

nobodyになってしまう現象は回避された。

ということでよろしいでしょうか?

ここまで上手くいっていて、さらにNG状況ということでしたら

ご質問当初の状況と変わっている可能性があると思います。

NGの際の、ManagementServerログの内容が変わったりしていないでしょうか?

システムVMのテンプレートDLのメッセージは、直ぐに確認できないのですが

問題無いような気がします。。。すみません。直ぐには確認できません。

以上

ご確認ください。

2013年5月20日 17:23 二河 等 <h.nikoh ＠ msr.co.jp>:

松浦様

二河です。

ご指摘ありがとうございます。

リンク先も参考にさせていただきました。

CloudStackの管理サーバのUIからゾーンを作成する際に、

プライマリストレージをマウントする際に利用されるNFSのバージョンはいくつになるのでしょうか？

（一説ではv4と聞いています）

v3やv4でマウントし、nobodyにならないこと、

およびroot権限にて書き込みが可能なことが確認できております。

プライマリストレージのマウント自体もうまくいっているように見えています。

ナイトハンズオンで作成した環境と今回の社内検証では、

ネットワークの状態が異なるという点があります。

・ナイトハンズオン→クローズド

・社内検証→社内LAN

ですが、やはり問題はNFSのところかと思ってます。

ためしにNFSではなく、iSCSI接続のDiskをプライマリストレージに指定しましたが、

同じ状況が発生しています。

システムVMのダウンロード・展開に失敗しているのでしょうか？

以下、システムVMのテンプレートダウンロード時のメッセージです。

<xenserver>

[root ＠ csmtest ~]# /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -F

--2013-04-25 19:58:38--  http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2

<proxy> に接続しています... 接続しました。

Proxy による接続要求を送信しました、応答を待っています... 200 OK

長さ: 1011 [text/html]

`/usr/lib64/cloud/common/scripts/storage/secondary/143182ef-68d3-456d-9814-18628d3dcb3b.vhd' に保存中

100%[==========================================================>] 1,011       --.-K/s 時間 0s      

2013-04-25 19:58:55 (56.4 MB/s) - `/usr/lib64/cloud/common/scripts/storage/secondary/143182ef-68d3-456d-9814-18628d3dcb3b.vhd' へ保存完了 [1011/1011]

File /usr/lib64/cloud/common/scripts/storage/secondary/143182ef-68d3-456d-9814-18628d3dcb3b.vhd does not appear to be compressed

Moving to /mnt/secondary/template/tmpl/1/1///143182ef-68d3-456d-9814-18628d3dcb3b.vhd...could take a while

Successfully installed system VM template  to /mnt/secondary/template/tmpl/1/1/

<kvm>

[root ＠ centoscsm ~]# /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /home/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm - F

--2013-05-16 10:55:16--  http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2

<proxy> に接続しています... 接続しました。

Proxy による接続要求を送信しました、応答を待っています... 200 OK

長さ: 1013 [text/html]

`/usr/lib64/cloud/common/scripts/storage/secondary/1a82fb10-4ded-4a1e-98c5-bbb0102dcdab.qcow2' に保存中

100%[==========================================================>] 1,013       --.-K/s 時間 0s      

2013-05-16 10:55:57 (31.1 MB/s) - `/usr/lib64/cloud/common/scripts/storage/secondary/1a82fb10-4ded-4a1e-98c5-bbb0102dcdab.qcow2' へ保存完了 [1013/1013]

File /usr/lib64/cloud/common/scripts/storage/secondary/1a82fb10-4ded-4a1e-98c5-bbb0102dcdab.qcow2 does not appear to be compressed

Moving to /home/secondary/template/tmpl/1/3///1a82fb10-4ded-4a1e-98c5-bbb0102dcdab.qcow2...could take a while

Successfully installed system VM template  to /home/secondary/template/tmpl/1/3/

よろしくお願いします。

From: 松浦直樹 [mailto:matsuura.naoki ＠ pinetree-bay.com] 
Sent: Friday, May 17, 2013 10:34 AM
To: 二河 等
Cc: users ＠ cloudstack.jp

Subject: Re: [cloudstack-users:0162] Re: 

【質問】CloudStackへの基本ゾーンの作成（XenServer）でシステムVMが起動できない

二河様

松浦です。

とりあえず、問題は、cloudstack云々ではなく

NFSマウントのように感じます。

nobodyの状態では、先に進めないとおもうので

まずは、一旦コンピュートノードから、Primary領域を手動でマウントして、rootで書き込みができるようにする

と言う所までは、準備状況として確認できた方がよいとおもいます。

まずは、そのための切り分けを行った方がよいかもしれません。

現状は、、、、

mountはできているけど、リモートから書き込んだときに

アクセス権がおかしく見える。

ということのようですので

rpc.idmapdまわりなような気がします。

(他も確認ポイントがあるかも知れませんがよく分かりません)

(NFSサーバー側のアクセス権の話でも無いような気がします。)

以下ページの/etc/idmapd.confの設定  項

あたりの解説がわかりやすかったです。

(ご参考)

http://www.turbolinux.co.jp/products/server/11s/user_guide/nfssetup.html

NFSサーバー上のｉｄｍａｐｄ．ｃｏｎｆの内容を、サーバーとクライアントで同じ内容にする必要がある。

と書かれているので、

私はやったこと無いですが、NFSサーバー上のｉｄｍａｐｄ．ｃｏｎｆを

コンピュートノードにコピーして、お試しいただいてもよいかもしれません。

(オリジナルのバックアップを取っておく等はお願いします。)

#私の場合、ｉｄｍａｐｄ．ｃｏｎｆの

#domain=hoge の記載が不一致でnobodyの状態になったことがありました。

#という内容を前回お伝えしました。

今私が分かるのはこれくらいなのですが・・・

こういった問題が起こるのは、NFSv４特有の問題(仕様)のようなので

NFSのバージョンを下げると、とりあえずは上手くいくかもしれません。

(あまりおすすめでは無い気がしますが。。。)

以上

お手数ですが

ご確認ください。

2013年5月16日 17:44 二河 等 <h.nikoh ＠ msr.co.jp>:

松浦様

二河です。ありがとうございます。

まさに読書会にて輿水さんがおっしゃってました。

アクセス権や所有者・グループを見直し、

さらにlibvirtdやcloud-agentの再起動を試したにも関わらず、

状況は変わりません。

From: 松浦直樹 [mailto:matsuura.naoki ＠ pinetree-bay.com] 
Sent: Wednesday, May 15, 2013 11:19 PM
To: 二河 等

Cc: users ＠ cloudstack.jp
Subject: Re: [cloudstack-users:0162] Re: 【質問】CloudStackへの基本ゾーンの作成（XenServer）でシステムVMが起動できない

二河 様
松浦です。

ユーザー会の輿水さんがおっしゃっていた内容ですね。

/etc/idmapd.conf
のdomainの記載が、NFSのサーバ、クライアントでそろってなくて
同じ現象になったことがあります。
設定をそろえたところ、root,rootになった事がありました。

ご確認ください。

2013年5月15日 12:09 二河 等 <h.nikoh ＠ msr.co.jp>:

松浦様

二河です。ご連絡ありがとうございます。

コンピューティングノードにプライマリストレージをマウントすることができてはいたのですが、

その中に作成されたファイルやディレクトリの所有者とグループが「nobody」になっていました。

（xenがうまくいかなかったので、途中からKVMに切り替えています）

[root ＠ kvmtest ~]# ls -lsa /mnt/55f33d51-098c-3102-acb5-8f936b915013

合計 1920

   4 drwxrwxrwx. 3 root   root       4096  5月 14 14:45 2013 .

   4 drwxr-xr-x. 4 root   root       4096  5月 14 15:15 2013 ..

136 -rwxr--r--. 1 nobody nobody   262144  5月 14 14:45 2013 726aa60a-d89d-439e-9694-243aba384209

   4 drwxr-xr-x. 2 root   root       4096  5月 14 14:45 2013 KVMHA

136 -rwxr--r--. 1 nobody nobody   262144  5月 14 14:45 2013 c5fd9103-66ca-4fa1-9cd1-f2338ab31de7

   4 -rw-r--r--. 1 root   root         11  5月 14 12:38 2013 hb-98e03e58-0613-4879-adcc-207f29d81089

1632 -rwxr--r--. 1 nobody nobody 10485760  5月 14 14:45 2013 v-2-VM-patchdisk

NFSサーバ側でchownコマンドで「root:root」にし、

かつchmodコマンドでディレクトリやファイルのアクセス権をまとめて777に変更していますが、

それでもシステムVMの作成はうまくいきませんでした。

KVMに変更したので、

libvirtdの再起動と、

cloud-agentの再起動も試しています。

セカンダリストレージは管理サーバにマウントされた状態で、

所有者・グループはroot、アクセス権は755です。

NFSサーバ（CentOS6.3）の/etc/idmapd.confの内容を以下に示します。

-------------------------------------------------------------------

[General]

#Verbosity = 0

# The following should be set to the local NFSv4 domain name

# The default is the host's DNS domain name.

Domain = basis-g.local

# The following is a comma-separated list of Kerberos realm

# names that should be considered to be equivalent to the

# local realm, such that <user>@REALM.A can be assumed to

# be the same user as <user>@REALM.B

# If not specified, the default local realm is the domain name,

# which defaults to the host's DNS domain name,

# translated to upper-case.

# Note that if this value is specified, the local realm name

# must be included in the list!

#Local-Realms =

[Mapping]

Nobody-User = nobody

Nobody-Group = nobody

[Translation]

# Translation Method is an comma-separated, ordered list of

# translation methods that can be used.  Distributed methods

# include "nsswitch", "umich_ldap", and "static".  Each method

# is a dynamically loadable plugin library.

# New methods may be defined and inserted in the list.

# The default is "nsswitch".

Method = nsswitch

# Optional.  This is a comma-separated, ordered list of

# translation methods to be used for translating GSS

# authenticated names to ids.

# If this option is omitted, the same methods as those

# specified in "Method" are used.

#GSS-Methods = <alternate method list for translating GSS names>

#-------------------------------------------------------------------#

# The following are used only for the "static" Translation Method.

#-------------------------------------------------------------------#

#[Static]

# A "static" list of GSS-Authenticated names to

# local user name mappings

#someuser ＠ REALM = localuser

#-------------------------------------------------------------------#

# The following are used only for the "umich_ldap" Translation Method.

#-------------------------------------------------------------------#

#[UMICH_SCHEMA]

# server information (REQUIRED)

#LDAP_server = ldap-server.local.domain.edu

# the default search base (REQUIRED)

#LDAP_base = dc=local,dc=domain,dc=edu

#-----------------------------------------------------------#

# The remaining options have defaults (as shown)

# and are therefore not required.

#-----------------------------------------------------------#

# whether or not to perform canonicalization on the

# name given as LDAP_server

#LDAP_canonicalize_name = true

# absolute search base for (people) accounts

#LDAP_people_base = <LDAP_base>

# absolute search base for groups

#LDAP_group_base = <LDAP_base>

# Set to true to enable SSL - anything else is not enabled

#LDAP_use_ssl = false

# You must specify a CA certificate location if you enable SSL

#LDAP_ca_cert = /etc/ldapca.cert

# Objectclass mapping information

# Mapping for the person (account) object class

#NFSv4_person_objectclass = NFSv4RemotePerson

# Mapping for the nfsv4name attribute the person object

#NFSv4_name_attr = NFSv4Name

# Mapping for the UID number

#NFSv4_uid_attr = UIDNumber

# Mapping for the GSSAPI Principal name

#GSS_principal_attr = GSSAuthName

# Mapping for the account name attribute (usually uid)

# The value for this attribute must match the value of

# the group member attribute - NFSv4_member_attr

#NFSv4_acctname_attr = uid

# Mapping for the group object class

#NFSv4_group_objectclass = NFSv4RemoteGroup

# Mapping for the GID attribute

#NFSv4_gid_attr = GIDNumber

# Mapping for the Group NFSv4 name

#NFSv4_group_attr = NFSv4Name

# Mapping for the Group member attribute (usually memberUID)

# The value of this attribute must match the value of NFSv4_acctname_attr

#NFSv4_member_attr = memberUID

-------------------------------------------------------------------

From: 松浦直樹 [mailto:matsuura.naoki ＠ pinetree-bay.com] 
Sent: Tuesday, May 14, 2013 6:19 PM
To: 二河 等
Cc: users ＠ cloudstack.jp
Subject: Re: [cloudstack-users:0162] Re: 【質問】CloudStackへの基本ゾーンの作成（XenServer）でシステムVMが起動できない

二河さま

松浦と申します。

よろしくお願い致します。

xenはあまりさわったこと無いので、よく分からず。。

なのですが・・・

>（マウント先は管理サーバのCentOSです）

NFSマウントは、コンピューティングノード(xen)から、プライマリストレージがマウントされるか?

の確認が必要かもしれません。

確認済でしたらすみません。

ご確認ください。

2013年5月13日 11:28 二河 等 <h.nikoh ＠ msr.co.jp>:

輿水様

ありがとうございます。

>NFSは仮想サーバであっても問題ないです。
承知しました。

>NFSv4をお使いでしょうか？
使っています。

>手動でmountした状態で、作成されるファイルのパーミッション（所有者）は
>どのようになりますか？
>nobodyになると、NGです。

以下のようになりました。Nobodyではないので、大丈夫かと思います。
-rw-r--r--. 1 root root    5  5月 13 11:13 2013 test
（マウント先は管理サーバのCentOSです）

よろしくお願いいたします。

二河

-----Original Message-----
From: Mayumi K [mailto:samemoon ＠ gmail.com]
Sent: Monday, May 13, 2013 11:03 AM
To: 二河 等
Cc: users ＠ cloudstack.jp
Subject: Re: [cloudstack-users:0160] Re: 【質問】CloudStackへの基本ゾーンの作成（XenServer）でシステムVMが起動できない

二河さま

ユーザー会の輿水です。

> CloudStackの管理サーバや、NFSサーバは、
> 仮想でも「Hyper-V上のものはNG」といった制約などあるのでしょうか？

NFSは仮想サーバであっても問題ないです。
NFSv4をお使いでしょうか？

手動でmountした状態で、作成されるファイルのパーミッション（所有者）は
どのようになりますか？
nobodyになると、NGです。

よろしくお願いいたします。

2013年5月13日 10:57 二河 等 <h.nikoh ＠ msr.co.jp>:
> 島崎さん
>
> ありがとうございます。
>
> /etc/exportsの内容は以下の通りです。
> /home *(rw,async,no_root_squash)
>
> Exportしているディレクトリは以下の通りです。
> /home/primary
> /home/secondary
>
> アクセス権は両方とも「777」です。
>
> CloudStackの管理サーバや、NFSサーバは、
> 仮想でも「Hyper-V上のものはNG」といった制約などあるのでしょうか？
>
> 二河
> _______________________________________________
> users mailing list
> users ＠ cloudstack.jp
> http://ml.cloudstack.jp/mailman/listinfo/users
_______________________________________________
users mailing list
users ＠ cloudstack.jp
http://ml.cloudstack.jp/mailman/listinfo/users

-------------- next part --------------
HTMLの添付ファイルが除去されました.
URL: http://ml.cloudstack.jp/pipermail/users/attachments/20130520/79c62b23/attachment-0001.html