Oracle VM Server for SPARC OpenStack nova ドライバに固有の問題ではなく、OpenStack コンソールが焦点となる問題が存在します。
この問題に対処するには、コンソールウィンドウの上部にある青色のバーをクリックします。
一部の古いサーバー (UltraSPARC T2 サーバーなど) では、EFI ラベルはサポートされません。そのため、古いハードウェアと新しいハードウェアをサポートするには、VM イメージに基づいて VTOC を作成する必要があります。この問題により、ディスクのサイズ制限も適用されます。
VM で cpu-arch プロパティーが設定されている場合、nova ドライバは cpu-arch プロパティー値をあとで変更できません。この問題は、フレーバの移行がまだ Oracle VM Server for SPARC OpenStack Nova ドライバでサポートされていないために発生します。
ディスクの自動拡張機能を使用するには、ZFS ルートを使用する必要があります。ファイルシステムと、UFS、SVM、VxFS などのボリュームマネージャーは、この機能ではサポートされません。
次の Oracle VM Server for SPARC 機能は、Linux for SPARC 1.0 を実行しているゲストドメインでは動作しません。
動的なボリュームの接続と切断
動的なネットワークの接続と切断
ライブ移行
vntsd コンソールログは、ゲストドメインと一緒には移行されません。その結果、これらのコンソールログは使用できなくなり、最近のログエントリのみが表示されます。
コントローラとコンピュートノードに、管理インタフェース上で一致しない MTU がある場合に、メッセージキューやその他の OpenStack サービスの問題が発生することがあります。これらの管理インタフェースは、OpenStack 管理の通信に使用されます。一致しない MTU 構成には、9000 バイトのコンピュートノード管理ネットワークと、1500 バイトのコントローラノードが含まれていることがあります。すべてのホストが、MTU の観点でその管理ネットワークに合うようにしてください。
OpenStack 構成ファイルの構成行の末尾にコメント (#) を追加すると、問題が発生することがあります。OpenStack は、インラインコメントを値の一部として解釈します。
コメントのみを行に含めて、コメント行がコメント記号 (#) で始まるようにしてください。
たとえば、admin_password=welcome1 #my password 構成行では、パスワードを welcome1 #my password と指定したと解釈されます。
構成ファイルでインラインコメントを調べるには、次の行を使用します。
# cat /etc/service/service.conf |egrep -v '^#' | grep '#'
NFS サーバー設定が正しいことを確認します。間違ったサーバーを選択した場合、NFS 共有をマウントしようとすると、nova-compute サービスがブート時にハングアップしたように見えます。
この問題を回避するには、nova-compute サービスを無効にして、誤った共有に対して試行しているマウントに kill を発行します。ドライバは、共有をさらにマウントしようとする可能性があるため、nova-compute サービスを無効にしたあとで、ドライバによる誤った共有のマウント試行をすべて強制終了してください。その後、nova.conf ファイルを修正して、nova-compute サービスを有効にします。
再構築操作は、まだ Oracle VM Server for SPARC OpenStack Nova ドライバでサポートされていません。Nova 退避操作のみがサポートされています。ユーザーが再構築操作を実行しようとすると、VM の既存のディスクはリサイクルされ、「再イメージ」されないことがあります。
OS イメージを使用した Cinder ボリュームの作成中に、OS イメージのコピーに長時間かかることがあります。Nova は、Cinder によるそのタスクの完了を待機中にタイムアウトになることがあります。nova-compute サービス (Oracle VM Server for SPARC Nova ドライバの外部) は単に一定期間ポーリングし、Cinder がボリュームを作成したかどうかを確認するために待機します。
環境でこれらの「ハングアップ」が発生した場合は、次の値を増やすことを検討してください。
block_device_allocate_retries=360
その後、nova-compute サービスを再起動します。
NFSv4 共有へのアクセスの問題が発生した場合は、コンピュートノードでパニックが発生することがあります。NFSv4 共有が使用不可になったか、遅れが生じたか、10 分以上その他の接続の問題が発生した場合、コンピュートノードは、制御ドメインに対してパニックを発行することでそのコンピュートノード自体をフェンシングします。この問題が頻繁に発生する場合、問題の根本原因を特定するときに dlm_nfs_server エントリをコメントにして DLM を無効にします。
NFSv4 ストレージが高可用性で回復力が高いことを確認します。また、委託が無効になっていることを確認します。
この問題は、ML2 からではなく EVS に対して neutron-server サービスが構成されている場合、および neutron-server サービスが正しく構成される前に、プロファイルがこのサービスをオンラインにしようとした場合に発生します。
この問題を修正するには、次のコマンドを実行して、manifest-import サービスを再起動して neutron-server サービスを無効にします。
cctrl# svcadm restart manifest-import cctrl# svcadm disable neutron-server
クラウドコントローラサービスを手動で構成する場合、neutron-server サービスを再度有効にする前に、/etc/neutron/neutron.conf および /etc/neutron/api-paste.ini クラウドコントローラファイルの構成を完了する必要があります。