仮想化通信

日本仮想化技術株式会社の公式エンジニアブログ

Juju/MAASでデプロイするOpenStackでLXDを使う方法

Juju/MAASを使ってOpenStackをデプロイ...と言いますか、Nova Computeチャームを使ってデフォルト設定のままデプロイすると、virt-type KVMとしてデプロイされます。インスタンスを起動するとVMが作成され、その中で指定したOSが起動します。

これをNova ComputeでLXDを使うには次のような内容のyamlファイルを書き、juju deployコマンドを実行します。Nova-LXDを動かすにはデプロイノードに2つのストレージボリュームが必要です。そのうち1つには起動フラグを設定しておく必要があります。

yamlファイル例

nova-compute:
    openstack-origin: "cloud:xenial-pike"
    enable-live-migration: yes
    enable-resize: yes

nova-compute-lxd:
    openstack-origin: "cloud:xenial-pike"
    enable-live-migration: yes
    enable-resize: yes
    virt-type: lxd

juju deployコマンド例

% juju add-machine --constraints tags=lxd1
(lxd1タグを持つJuju Machineを追加)

% juju machines
(Juju Machine番号を確認)

% juju deploy --config lxd-compute.yaml nova-compute nova-compute-lxd --to 10
% juju deploy lxd && juju config lxd block-devices=/dev/sdb storage-type=lvm
(Juju Machine番号が10の場合の実行例)

f:id:virtualtech:20171018141927p:plain:w480

KVMと比べると利用できるOSは制限されるものの、インスタンスの作成や削除、起動が速くてちょっと感動してしまいました。Juju/MAASを使ってOpenStackを構築する際にはぜひ、Nova-LXDをお試しください。

ちなみに参考サイトの一番下にリンクを貼りましたが、Nova-KVMとNova-LXDの共存をする方法をまとめています。必要であれば参考情報としてどうぞご覧ください。

参考サイト

Ubuntu JujuでデプロイしたマシンをAnsibleで管理するには

はじめに

最近、JujuとMAASを使ったOpenStack環境の構築を検証しています。 こちらでその辺りの情報を公開しています。

Jujuは様々なインフラにアプリケーションのデプロイと構成管理を行うツールで、MAASはMetal As a Serviceを提供するツールです。 これらはオープンソースで開発されており、ユーザーは公開されたドキュメントとパッケージを使って、自由にインストールして使うことができます。 サポートが必要であれば、Ubuntu Advantageを結ぶことで、 Canonicalによる技術支援を受けることができます。

JujuはAWSやAzureといったクラウド環境のほか、MAASで管理するサーバーを使うこともできるため、JujuとMAASを組み合わせることで既存のサーバーを使ってOpenStackやHadoop、最近流行りのKubernetes環境なども構築可能です。

Jujuはアプリケーションの展開を物理層にデプロイできるだけではなく、コンテナーにも展開できます。例えばApache Webサーバーを任意のノードに展開する場合は次のようにコマンドを実行することで簡単にデプロイすることができます。

ytooyama@maas:~⟫  juju deploy apache2 --to 1

これで、Jujuのマシン番号1のサーバーに対して物理環境にOSをインストールして、apache2をセットアップします。一方、コンテナーにデプロイする場合は次のようにコマンドを実行します。

ytooyama@maas:~⟫  juju deploy apache2 --to lxd:1

これで、Jujuのマシン番号1のサーバーに対してコンテナーを動かすために物理環境にOSのインストールとLXD/LXC環境を構築してコンテナーを起動、コンテナー上にapache2をセットアップします。

実際はapache2のインストール、サービスの起動、ポートの開放などの処理が行われます。コンテナーにデプロイした場合は、ブリッジ接続のコンフィグレーションも行われます。必要な場合は特定の形式(yaml形式)で記述した設定を元にカスタマイズの上デプロイすることもできます。

Jujuについては次のドキュメントをご覧ください。

jujucharms.com

Jujuには視覚的でわかりやすい、Juju GUIというものが用意されており、このDashboardを使ってデプロイしたアプリケーションの管理(アップデート、設定変更など)ができますし、スケールの拡大、縮小も可能です。同じ操作をJuju CLIで行うこともできます。

ただし、対象の台数が多くなってくると、Juju GUIやCLIツールを使って状況の確認をしたり、場合によってssh接続して様々なログを確認したりする事になります。数台規模の環境であればそれでも十分ですが、50台から100台規模になってくると結構しんどいですよね。

そこでようやく本題になるのですが、JujuでデプロイしたアプリケーションやOSを管理するためにAnsibleを使おうという話です。

Juju関連のこと

Jujuをセットアップすると、Jujuがアプリケーションを展開する前にOSをその環境にセットアップします。現状はOSとしてUbuntuが使われます。Jujuが構成管理をする際、インストールしたときに自動生成したキーペアを使って公開鍵認証によってリモートアクセスします。生成されるキーペアは、~/.local/share/juju/sshのパスの配下に展開されます。

AnsibleはSSHプロトコルとPythonを利用してノードを構成管理するツールです。構成管理を適用するノードにアクセスする際に公開鍵認証かパスワード認証を用いますが、Jujuがデプロイする環境ではパスワードが設定されません。従って、自動生成された鍵を使って公開鍵認証をする形になります。

Jujuがデプロイしたアプリケーションノードの一覧はJuju machenesコマンドで一覧表示できます。実際にコマンドを実行すると次のような結果が表示されます。

ytooyama@maas:~⟫ juju machines 
Machine  State    DNS            Inst id              Series  AZ       Message
0        started  172.17.29.223  cqd8ba               xenial  default  Deployed
0/lxd/0  started  172.17.29.225  juju-575e9e-0-lxd-0  xenial  default  Container started
0/lxd/1  started  172.17.29.227  juju-575e9e-0-lxd-1  xenial  default  Container started
0/lxd/2  started  172.17.29.193  juju-575e9e-0-lxd-2  xenial  default  Container started
0/lxd/3  started  172.17.29.194  juju-575e9e-0-lxd-3  xenial  default  Container started
0/lxd/4  started  172.17.29.195  juju-575e9e-0-lxd-4  xenial  default  Container started
0/lxd/6  started  172.17.29.201  juju-575e9e-0-lxd-6  xenial  default  Container started
1        started  172.17.29.224  4pp3th               xenial  default  Deployed
1/lxd/0  started  172.17.29.226  juju-575e9e-1-lxd-0  xenial  default  Container started
1/lxd/1  started  172.17.29.228  juju-575e9e-1-lxd-1  xenial  default  Container started
1/lxd/2  started  172.17.29.196  juju-575e9e-1-lxd-2  xenial  default  Container started
1/lxd/4  started  172.17.29.197  juju-575e9e-1-lxd-4  xenial  default  Container started
1/lxd/5  started  172.17.29.198  juju-575e9e-1-lxd-5  xenial  default  Container started
1/lxd/6  started  172.17.29.199  juju-575e9e-1-lxd-6  xenial  default  Container started
1/lxd/7  started  172.17.29.200  juju-575e9e-1-lxd-7  xenial  default  Container started
2        started  172.17.29.222  kcnfd8               xenial  default  Deployed
2/lxd/0  started  172.17.29.229  juju-575e9e-2-lxd-0  xenial  default  Container started

Machineはそれぞれの環境につけられたJujuが管理するマシン番号で、番号しか表示されていないものは物理サーバー、lxdの記述のあるものはコンテナーを示しています。例えば0/lxd/1ならば、マシン番号0のサーバーのコンテナーの1番ということがわかります。マシン番号0番には6個のコンテナーが存在することがわかります。

この出力結果の中でAnsibleでノードを管理するときに必要な情報はIPアドレスです。awkコマンドを使って抜き出してみましょう。

ytooyama@maas:~⟫ juju machines|awk '{print $3}'
DNS
172.17.29.223
172.17.29.225
172.17.29.227
172.17.29.193
172.17.29.194
172.17.29.195
172.17.29.201
172.17.29.224
172.17.29.226
172.17.29.228
172.17.29.196
172.17.29.197
172.17.29.198
172.17.29.199
172.17.29.200
172.17.29.222
172.17.29.229

うまくいった...とおもいきや、1行目のDNSがちょっと邪魔です。インベントリーファイルに書き込んでから一行目を削除する方法でも良いですが、つぎのようにフィルタリングできます。

ytooyama@maas:~⟫ juju machines|awk 'NR>1 {print $3}'
172.17.29.223
172.17.29.225
172.17.29.227
172.17.29.193
172.17.29.194
172.17.29.195
172.17.29.201
172.17.29.224
172.17.29.226
172.17.29.228
172.17.29.196
172.17.29.197
172.17.29.198
172.17.29.199
172.17.29.200
172.17.29.222
172.17.29.229

いい感じです。次のように実行して、Ansibleのインベントリーファイルを作っておきます。 hostsという名前で作成したインベントリーファイルにはIPアドレスの一覧のみ追記されます。

ytooyama@maas:~⟫ juju machines|uniq|awk 'NR>1 {print $3}' > hosts

Ansibleコマンドによる管理

Ansibleがシステムにインストールされており、インベントリーファイルも作成済みであれば、Ansibleとモジュールを使ってノードの管理が可能になります。AnsibleではインベントリーファイルにAnsibleで操作する対象のノードをIPアドレスかFQDNで記述しておく必要があります。Ansibleで操作する想定でないノードを誤操作しないようにする予防策というわけですね。

ansibleコマンドでノードを操作するにはインベントリーファイルを-iオプションで指定します。そのほか、利用するモジュールやユーザー認証に関わる情報(ユーザー、パスワードやキーペアなど)も必要です。これらはインベントリーファイルに記述することができますが、とりあえず次のようにコマンドにオプション指定することで実行可能です。

ytooyama@maas:~⟫ ansible -i hosts 172.17.29.223 -m ping -u ubuntu --private-key=~/.local/share/juju/ssh/juju_id_rsa

実はこのままだとエラーで失敗します。Ansibleは対象のノードにPythonのバージョン2がインストールされている必要があるためです。 ただ、Python 2は現行は利用可能ですが、サポート期限が迫っているという現状があります。また、Linux ディストリビューションによってはPython 2はデフォルトでインストールされず、必要な場合は別途インストールする必要が出てきます。例えばUbuntu 16.04とか。

現行のAnsibleをインストールする場合はPython2が依存パッケージとして同時にインストールされますが、「Ansible 2.2でPython3サポート」が行われたため、オプションを追加することでPyton 3.5以降がインストール済みであることを条件として、その条件にマッチしたノードをサポートするようになりました。

Ansible 2.2以降でのPython3サポートについては先ほどのリンク先の情報に書かれているように大体のコードは正常に動くが動かない場合もあると書かれています。うまく動かない場合はノードにPython2をインストールして対応しましょう。

ytooyama@maas:~⟫ ansible -i hosts 172.17.29.223 -m ping -u ubuntu --private-key=~/.local/share/juju/ssh/juju_id_rsa --extra-vars=ansible_python_interpreter=/usr/bin/python3
172.17.29.223 | SUCCESS => {
    "changed": false, 
    "failed": false, 
    "ping": "pong"
}

これで当初の目的は達成できるわけですが、コマンドとオプションが長すぎて入力が大変です。そこで、インベントリーファイルに必要な情報を書き込んでみます。

[remote]のようにグループを作成して、その下にIP、FQDNを記述するとコマンドを実行するときにそのグループを指定して複数のターゲットに対してコマンドを実行できます。また、[remote:vars]でそのグループの設定を記述します。公式のマニュアルに記述例が掲載されています。

[remote]
172.17.29.223
172.17.29.225
172.17.29.227
172.17.29.193
172.17.29.194
172.17.29.195
172.17.29.201
172.17.29.224
172.17.29.226
172.17.29.228
172.17.29.196
172.17.29.197
172.17.29.198
172.17.29.199
172.17.29.200
172.17.29.222
172.17.29.229

[remote:vars]
ansible_python_interpreter=/usr/bin/python3
ansible_user=ubuntu
ansible_ssh_private_key_file=/home/ytooyama/.local/share/juju/ssh/juju_id_rsa

このインベントリーファイルを使ってansibleコマンドでpingを実行してみます。全てのサーバーにpingを実行できます。

ytooyama@maas:~⟫ ansible -i hosts remote -m ping
172.17.29.193 | SUCCESS => {
    "changed": false, 
    "failed": false, 
    "ping": "pong"
}
...
172.17.29.229 | SUCCESS => {
    "changed": false, 
    "failed": false, 
    "ping": "pong"
}

Ansible Playbookコマンドによる管理

ansibleコマンドは一つの処理を行うには十分ですが、複数の処理を一括で実行する場合は不向きです。そんなときにはAnsible Playbookを使います。Ansible PlaybookはYAML形式で処理を記述します。例えばpingを実行したい場合は次のようにPlaybookを作成します。 Playbookの先頭にはハイフンを3つ入れてください。そのあとに処理や実行先の情報、ユーザー情報を指定したり、変数などを定義します。

---
- hosts: remote
  tasks:
   - name: try ping
     ping:

早速実行してみましょう。

ytooyama@maas:~⟫ ansible-playbook ping.yaml -i hosts

PLAY [remote] ********************************************************************************************

TASK [Gathering Facts] ***********************************************************************************
ok: [172.17.29.194]
ok: [172.17.29.227]
ok: [172.17.29.225]
ok: [172.17.29.193]
ok: [172.17.29.223]
ok: [172.17.29.195]
ok: [172.17.29.201]
ok: [172.17.29.228]
ok: [172.17.29.224]
ok: [172.17.29.226]
ok: [172.17.29.196]
ok: [172.17.29.198]
ok: [172.17.29.199]
ok: [172.17.29.200]
ok: [172.17.29.197]
ok: [172.17.29.222]
ok: [172.17.29.229]

TASK [try ping] ******************************************************************************************
ok: [172.17.29.223]
ok: [172.17.29.194]
ok: [172.17.29.227]
ok: [172.17.29.193]
ok: [172.17.29.225]
ok: [172.17.29.195]
ok: [172.17.29.201]
ok: [172.17.29.224]
ok: [172.17.29.226]
ok: [172.17.29.228]
ok: [172.17.29.196]
ok: [172.17.29.197]
ok: [172.17.29.198]
ok: [172.17.29.200]
ok: [172.17.29.199]
ok: [172.17.29.222]
ok: [172.17.29.229]

PLAY RECAP ***********************************************************************************************
172.17.29.193              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.194              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.195              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.196              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.197              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.198              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.199              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.200              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.201              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.222              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.223              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.224              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.225              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.226              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.227              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.228              : ok=2    changed=0    unreachable=0    failed=0   
172.17.29.229              : ok=2    changed=0    unreachable=0    failed=0   

ここまでできれば、あとはPlaybookの書き方次第で様々なことを実現可能です。 AnsibleのPlaybookのサンプルがドキュメントやGithub上に公開されているので、色々試してみたら楽しいかと思います。

ちなみにUbuntuで新しいバージョンのAnsibleを使うにはAnsible PPAを追加すると便利です。ページに書かれているコマンドを実行すると、Ubuntuのサポートされたバージョンで最新のAnsibleが利用できます。このPPAはRed Hat社のAnsibleチームが管理しているので安心です。Ubuntu 14.04 LTSや16.04 LTSなどで利用することを推奨します。

Ubuntu Xenial (16.04) でOpen vSwitch+DPDKな環境を作る(vHost User Clientモード編)

以前、UbuntuでOpen vSwitch+DPDKを導入してKVMで利用する手順をここで書かせていただきました。

tech.virtualtech.jp

tech.virtualtech.jp

tech.virtualtech.jp

以前取り上げた方法は全てvHost User Serverモードによって動かす手順です。vHost User ServerモードはOVS-DPDKがリセットされるとソケットが破棄されるため、OVSとQEMUを再起動するまでVMとの接続が再確立されませんでした。

これでは不便だよねということでそのあと開発されたのがvHost User Clientモードです。vHost User ClientモードはOVS-DPDKはvHostクライアントとして動作し、QEMUがサーバーとして動作します。この構成では、Open vSwitchがクラッシュしたとしても、ソケットはQEMUによって管理されるため、vHost User Serverモードよりも接続の復旧が容易になります。

詳細はこちらをご覧ください。

software.intel.com

OpenStackでDPDKを使う場合も、Ocata以降ではvHost User Clientモードをサポートしているので、デフォルトではこちらのモードで動作します。vHost User Clientモードを利用するにはOVS 2.6、QEMU 2.7以降が必要です。ただし、RHEL7の場合はqemu-kvm-rhev-2.6.0-23.el7以降のバージョンにバックポートされています。CentOS 7ではバージョン7.3以上で同バージョンのqemu-kvm-evを利用可能です。

vHost User Clientモードに切り替える

以降、これまで紹介した手順でDPDK、OVS、QEMUがインストールされていることを前提に、vHost User Clientモードに切り替える方法をご紹介します。

sockディレクトリー作成

sockファイルを展開するディレクトリーを作成します。

# mkdir -p /usr/local/openvswitch/
sockファイル作成

ファイルを作っておきます。作成したファイルはOpen vSwitchが起動するとsockファイルになるようです。

# touch /usr/local/openvswitch/dpdkvhostclient0
# touch /usr/local/openvswitch/dpdkvhostclient1    
(作成するポートの数だけ作成) 
ブリッジ作成

dpdkvhostuserclientポートをぶら下げるためのOVSブリッジポートをnetdevタイプで作成します。

# ovs-vsctl add-br ovsbr1 -- set bridge ovsbr1 datapath_type=netdev
ポート作成

ポート作成方法はvHost User Serverモードとほとんど一緒ですが、type=dpdkvhostuserclientという設定とoptionsとしてvhost-server-pathを指定します。

# ovs-vsctl add-port ovsbr1 dpdkvhostclient0 \
    -- set Interface dpdkvhostclient0 type=dpdkvhostuserclient \
       options:vhost-server-path=/usr/local/openvswitch/dpdkvhostclient0

# ovs-vsctl add-port ovsbr1 dpdkvhostclient1 \
    -- set Interface dpdkvhostclient1 type=dpdkvhostuserclient \
       options:vhost-server-path=/usr/local/openvswitch/dpdkvhostclient1
DPDKポートのマウント

次に、DPDKデバイスポートを追加します。これはvHost User Serverモードと方法は一緒です。

# ovs-vsctl add-port ovsbr1 dpdk0 -- set Interface dpdk0 type=dpdk
vhostuserclient インターフェイスの追加

virsh editコマンドでvHost User Interfaceを設定します。mode='server'と設定するのがvHost User Serverモードで動かした時と異なる点です。この設定にあるmodeはQEMU側の動作モードを指定します。vHost User ClientモードはQEMUをサーバーモードとして動かすのでmode='server'と設定します。

        <interface type='vhostuser'>
                <source type='unix'
                        path='/usr/local/openvswitch/dpdkvhostclient0'
                        mode='server'/>
                <model type='virtio'/>
        </interface>
サービスの再起動

Open vSwitchdサービスを再起動します。

# service openvswitch-switch restart

以上で準備完了です。あとは仮想マシンを再起動して、ゲストOSでIPアドレスを設定することでDPDKポートがアクセス可能になります。通信できない場合、またはエラーが出た場合はovs-vswitchd.logを確認してください。

今回取り上げた手順で、CentOS 7 + OVS/DPDK/KVMの構成で稼働していた環境もvHost User Clientモードに切り替えることができたことを最後に付け加えておきます。

作業後のovs-vsctl showコマンドの実行結果

実行結果から、これまでとは異なるモードである「dpdkvhostuserclient」で動いていることがわかります。

# ovs-vsctl show
51bf3a85-d776-47a7-b9cb-2da68f465b3b
    Bridge "ovsbr1"
        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
        Port "dpdkvhostclient1"
            Interface "dpdkvhostclient1"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/usr/local/openvswitch/dpdkvhostclient1"}
        Port "dpdkvhostclient0"
            Interface "dpdkvhostclient0"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/usr/local/openvswitch/dpdkvhostclient0"}
        Port "dpdkvhostclient2"
            Interface "dpdkvhostclient2"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/usr/local/openvswitch/dpdkvhostclient2"}
        Port "dpdkvhostclient3"
            Interface "dpdkvhostclient3"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/usr/local/openvswitch/dpdkvhostclient3"}
        Port "ovsbr1"
            Interface "ovsbr1"
                type: internal
    ovs_version: "2.6.1"

Ubuntu Xenial (16.04) でOpen vSwitch+DPDKな環境を作る(QEMUアップデート編)

以前、UbuntuでOpen vSwitch+DPDKを導入してKVMで利用する手順をここで書かせていただきました。

tech.virtualtech.jp

tech.virtualtech.jp

現在Ubuntu 16.04ではOcataリポジトリーを有効にすると、標準パッケージよりも新しいQEMU-KVMパッケージがインストールできるようになります。

~$ apt list -a qemu-kvm
Listing... Done
qemu-kvm/xenial-updates 1:2.8+dfsg-3ubuntu2.3~cloud0 amd64
qemu-kvm/xenial-updates,xenial-security 1:2.5+dfsg-5ubuntu10.14 amd64
qemu-kvm/xenial 1:2.5+dfsg-5ubuntu10 amd64

当然新しいものを選択すると思うのですが、実際に従来のバージョンからアップグレードする場合および新規インストールする際にそれぞれ注意することがあったので、ここにまとめようと思います。

アップグレードする場合

DPDKとOpenvSwitch、KVM環境をNewton版パッケージを使って構築して、Ocata版のパッケージに更新したいと思った場合、通常はこのように実行すると思います。

# add-apt-repository cloud-archive:ocata
# apt update
# apt upgrade && reboot
...
# add-apt-repository -r cloud-archive:newton  #Newtonリポジトリーを無効化

ああ簡単、よかったよかった…などと思っていると、次のようなエラーになりOVS+DPDKがうまく動いていないことがわかります。

~# ovs-vsctl show
2910fa6f-1c8b-4e8d-b321-bf36a65509ba
    Bridge "ovsbr0"
        Port "vhost-user1"
            Interface "vhost-user1"
                type: dpdkvhostuser
                error: "could not open network device vhost-user1 (Address family not supported by protocol)"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vhost-user2"
            Interface "vhost-user2"
                type: dpdkvhostuser
                error: "could not open network device vhost-user2 (Address family not supported by protocol)"
        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
                error: "could not open network device dpdk0 (Address family not supported by protocol)"
    ovs_version: "2.6.1"

とりあえずUbuntuでDPDKを使っている環境でアップグレードするときは、apt upgradeした後、update-alternatives --set ovs-vswitchd /usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdkコマンドを実行してDPDK enableモードでOVSを実行する設定を改めて行なったあと、openvswitch-switchサービスを再起動しなさいってことみたいです。

DPDKが正常に動くようになったから早速VMを起動しようとすると、次のようなログが出力されてVMが起動できない問題に出くわします。

仮想マシンの開始中にエラーが発生しました: unsupported configuration: Shared memory mapping is supported only with hugepages
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1035, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: unsupported configuration: Shared memory mapping is supported only with hugepages

これはVirt-Managerを使って起動しようとした場合のログですが、virshコマンドでVMを起動してもだいたい同じようなエラーが出て起動しません。hugepagesの書き方がQEMUのバージョンの更新(2.5から2.8)によって変更されたようです。記述の仕方はこちらにまとまっています。

libvirt.org

この「MemoryBacking」というところが今回重要です。HugePagesとして確保したメモリーをどこのノードからVMに割り当てるのか厳密に書く必要があるようです。実際の例で説明すると、従来は次のように記述するだけでした。

<memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <memoryBacking>
    <hugepages/>
  </memoryBacking>

これで良きに計らってくれていたのですが、QEMU 2.8では次のように記述する必要がありました。

  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <memoryBacking>
    <hugepages>
      <page size='2048' unit='KiB' nodeset='0'/>
    </hugepages>
    <nosharepages/>
  </memoryBacking>

システムで1GのHugePagesを確保している場合は2Mではなく、1Gを割り当てることもできます。以上の設定変更でVMが正常起動し、ネットワークはvhostuserで提供できるようになります。

nodeはNuma Nodeを指定します。numactl -Hコマンドで確認できますので、その出力結果をもとにどのノードからメモリーを確保するか指定します。

Ubuntu XenialでOpen vSwitch+DPDKを新規セットアップする場合

基本的には前編後編の流れでセットアップすれば構いません。新しいQEMUを使いたい場合はOcata以降のリポジトリーを有効にしてDPDK、OVS、KVM環境を構築します。

# add-apt-repository cloud-archive:ocata
# apt update

あとはVMの設定を前で説明したようにHugePagesの設定でpage size、nodeをきちんと指定します。それ以外は前編、後編の流れでOpen vSwitch+DPDK+Linux KVM環境を導入できます。

HPサーバーのGen8以降用ディスクトレイのパチモンをeBayで買う

久しぶりにサーバーネタは、HDDトレイのパチモン(偽造品)を買って試すお話です。はじめに言うとトレイは一応使えましたが、言わずもがな使用は自己責任となります。

背景

長らく弊社の検証サーバー機材として活躍してきたHP ProLiant G6世代のサーバーが、iLO2のJava Appletリモートコンソールが使用不能になるなどしてOSやブラウザの進歩に追いつけなくなり、リプレースの対象になってきました。使う分にはスペック的に悪くないのでやや惜しいですね。現在は、代わりになるサーバーとして同じくHPEサーバーのGen8・Gen9世代や、Dell R620をオークションで調達しています。

Gen8世代以降のサーバーではハードディスクのトレイ形状が変更になったため、サーバーのリプレースに合わせてディスクトレイもそれなりにたくさん必要になります。オークションの中古サーバーは大抵はディスクがついておらず、ディスクトレイのためにまだ使えるディスクごと買い換えるのも惜しいので、eBayからディスクトレイを調達しました。

買い方

eBayで[hp gen8 2.5 caddy]などのように検索するとたくさんアイテムが出てきます。トレイではなくキャディーが正しい?ようです。日本への発送に対応している商品に絞込み、価格+送料が低い順でソートして、適当なものをセレクトします。

パチモンと判別する方法は比較的簡単で、外見的にはトレイのサイドにHPロゴがあるかないかで見分けられました。また、商品によってはGen8以降のトレイの特徴とも言えるLEDが省略された分安いものもあります。潔いですね。今回はLEDつきのトレイを10個ほど調達しました。

比較

左がパチモン、右が正規品です。上から見る分には大きく変わりません。

f:id:virtualtech:20170607211924j:plain:w450

簡単に見分けられるサイド。HPロゴがないことがわかります。

f:id:virtualtech:20170608170614j:plain:w450

真上から。金属加工がいまいちなのか、沿ってしまっていますが誤差ではあります。金属加工は取っ手の付近にあるバネバネしたところもふわふわと浮いていて、折が足りない印象ですね。

f:id:virtualtech:20170608145916j:plain:w450

正面。上がパチモンです。ランプの窓が少し違う気もします。取っ手は金属製でさわり心地もふつうです。

f:id:virtualtech:20170608145504j:plain:w450

LEDの端子。端子のパターンが丸と四角で異なっています。丸くても四角くても利用上わかりませんが。

f:id:virtualtech:20170608145756j:plain:w450

地味につらいのが付属のネジ。HPサーバーでは馴染み深いトルクスネジなのですが、T15でもT10でもなく、何故かT9です。しかもセンターに突起があるのでドライバーを選びそうです。できればネジは別途調達したいですね。

f:id:virtualtech:20170609092753j:plain:w450

動作チェック

さて、これをサーバーに差し込んで起動させてみましょう。Smart Arrayがスキャンした段階で、1709で始まるメッセージが出力されました。調べてをみると、偽造品であることが見事にバレていました。正規品かどうか判別するチップが中に入っているようです。

f:id:virtualtech:20170608170704j:plain:w450

1709-Slot # Drive Array - One or more attached drives could not be authenticated as a genuine HP drive. Smart Array will not control the LEDs to these drives. Please run HP Smart Storage Administrator (HP SSA) or ACU to learn which drives could not be validated as genuine.

( http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=7481826&docId=emr_na-c04597377&docLocale=en_US より)

メッセージ通りなら、LEDが制御されないとのことですが、起動後もアクセスランプがくるくる回るように点灯していました。他のステータス表示に支障があるのかもしれません。透け具合が正規品と違うので、写真写りもイマイチですね。

f:id:virtualtech:20170608170846j:plain:w450

iLOではDegradedという扱いにされてしまっていたため、使用中はサーバーのアラートランプが点滅を続けていました。別の部位がDegradedになったときには不便かもしれません。

f:id:virtualtech:20170608170314j:plain:w450

まとめ

見た目以上に、サーバーお墨付きのパチモンディスクトレイになってしまいましたが、一応使えることが確認できました。エラーを無視して使うことになりそうです。非純正ディスクはセンサーやベンダー独自のステータス取得等ができないなど、ベンダー的には使ってほしくないと言うのはなんとなくわかるのですが、検証が主な用途な弊社的には不自由でやや不便といった感じです。

容量ラベルを貼る部分にはペンギンさんシールを貼り付けて、識別しやすいようにしておきました。次にトレイが不足したらLED省略版を試してみたいです。

おまけ

ちなみに、パチモントレイは今回のものに限らず、旧世代のHPサーバーやDellサーバー向けのトレイもたくさん出回っています。下の写真はDellのトレイの場合ですが、レバーが正規品よりもガバって開いたり、レバーをおこすボタンの色が薄かったりします。

f:id:virtualtech:20170609093800j:plain:w450

Canonical Ubuntu MAAS 2.2.0がリリースされた

2017年5月末にMAAS 2.2がリリースされたので、早速試してみました。

Canonical Ubuntu MAAS 2.2は現在MAAS Stable PPAで公開されており、Ubuntu 16.04.x Serverで利用するには次のようにリポジトリーを有効化する必要があります。

$ sudo add-apt-repository ppa:maas/stable
$ sudo apt update
$ sudo apt upgrade
$ sudo apt install maas  #All-in-Oneインストール

インストール方法についてはドキュメントが公開されています。

MAAS 2.2では様々な機能改修、機能追加が行われていますが、特に便利だったのがPodsと言う新機能でqemu-kvmをサポートしたことが挙げられると思います。

Pod typeとしてvirshを選択、Virsh Address qemu+sshなアドレスを設定して、「Save pod」をクリックで追加されます。このあとデプロイまでに必要な処理は自動的に行われます。すごい。

f:id:virtualtech:20170607102903p:plain

これまでもMAASでKVM仮想マシンを仮想ノードとして管理することは可能でしたが、物理マシンと同列に仮想マシンを管理するだけの機能しか有していませんでした。Podsでqemu-kvmと連携すると、登録した仮想化ホスト上の仮想マシンをMAASに追加するところからデプロイできる状態までの処理を自動で行ってくれるようになります。

f:id:virtualtech:20170607102950p:plain

また、MAAS DashboardやMAAS API経由で関連づけた仮想ホストに仮想マシンを作ってMAASに仮想ホストとして登録することもできるようになったとのことです。

f:id:virtualtech:20170607103016p:plain

標準でデプロイをサポートするOSはUbuntu 12.04LTS,14,04LTS,16.04LTSのほか、16.10,17.04,17.10(devel)のほか、引き続きCentOSの6と7のデプロイをサポートしています。自宅の仮想サーバーの管理とか、検証環境や本番環境のOSのセットアップに活用できそうですね。

なお、Ubuntu 16.04の標準リポジトリーのMAASパッケージも2.1系の最新版である2.1.5に更新されています。こちらはバグ修正が主のようです。

VMware ESXiやWorkstationとFusionに非常に深刻な脆弱性、アップデートパッチが公開される

以下のNEWSGAIA社のニュースサイト「Security NEXT」による報道について、調べてみました。

www.security-next.com

この問題はCVE-2017-4902, CVE-2017-4903, CVE-2017-4904, CVE-2017-4905で報告されている脆弱性で、修正プログラムは2017年03月28日にVMwareより提供されています。

オフィシャルのアドバイザリーはこちらで公開されています。

www.vmware.com

対象の修正プログラムは以下の通りです。

ESXi5.5以前の製品に対するパッチは提供されません。以前のバージョンを利用しているユーザーは直ちにメンテナンスされているバージョンへの更新を検討すべきです。

ESXiのパッチの詳細は次のURLから確認、ダウンロード可能です。

https://my.vmware.com/group/vmware/patch#search

本件や仮想化についてのお問い合わせはこちらまでお願いします。ご要望に合わせて見積もりさせていただきます。