ESXi上にNutanix CE AHVをインストールした


2019/11/12追記

ce-2019.02.11-stable.img.gzを使って環境を構築したところ、インストーラーにキーボード選択が用意されたので、初期ログインから「install」を実行するだけで良くなった。

インストール後に行う作業もNutanix CE仮想マシン上での「/var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml」 のalias=’pc’をpc-i440fx-rhel7.2.0に変更する作業のみで済んだ


ESXi 6.0基盤上で、Nutanix CEをインストールした。

インストール手順は下記の2つを参考にした
・ネットワールド Nutanix CE を Nested ESXiへインストールする9つのTips
・NTNX ESXi で Nested Nutanix CE を構成してみる。(ce-2018.01.31-stable 対応版)

今回の環境では iSCSIストレージのVMFS上に仮想ディスクをおいたところ、 /sys/block/sd?/queue/rotationalの値は1だけど、Nutanix CE環境起動後に確認してみると、全部SSD認識となっていたので、ここの値変更は実施していない。

また、NTNXのページの方に書かれている「/home/install/phx_iso/phoenix/svm_template/kvm/default.xml」のmachineタイプ変更はやらなくても動いたので実施していない。
pmuの追加も「仮想 CPU のパフォーマンス カウンタの有効化」のチェックをオンにできる環境なので実施していない。

クラスタ作成は、インストーラ上の「Create single-node cluster?」にチェックを入れる手法は使わず、インストール後に手動でclusterコマンドを実行する手法をとった。
ただし、「cluster -s 192.168.1.191 create」というやり方では無く「cluster –dns_servers=192.168.1.100 –ntp_servers=192.168.1.101 -s 192.168.1.191 create」という形でDNSサーバとNTPサーバを指定する手法をとっている。

ただし、この手法の場合、DNSサーバとして追加で「8.8.8.8, 8.8.4.4」、NTPサーバとして「0.pool.ntp.org, 1.pool.ntp.org」も登録されているので、セットアップ完了後必要に応じ削除する必要がある。

詳細については→ Create & Configure Nutanix Cluster via command line を参照

インストール完了後、Nutanix CE仮想マシンにログインし、「/var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml」の値を変更しないと、仮想マシンが正常に起動しません。

通常、仮想マシンを作成すると「machine=’pc’」と設定されています。
NUTANIX AHV 20180425.199環境では、この「pc」というのは「pc-i440fx-rhel7.3.0」のエイリアスになっています。
ESXi上の仮想マシンの場合「pc-i440fx-rhel7.2.0」でないと起動しないので、エイリアスの設定先を変更します。

変更前

<machine name='pc-i440fx-rhel7.3.0' alias='pc' hotplugCpus='yes' maxCpus='240'/>
<machine name='pc-i440fx-rhel7.2.0' hotplugCpus='yes' maxCpus='240'/>

変更後

<machine name='pc-i440fx-rhel7.3.0' hotplugCpus='yes' maxCpus='240'/>
<machine name='pc-i440fx-rhel7.2.0' alias='pc' hotplugCpus='yes' maxCpus='240'/

設定変更後は、全体の再起動を行います。

Hypervisorのホスト名を変える場合は、/etc/hostname と /etc/sysconfig/network のホスト名記載を書き換えます。
参考:CHANGING THE ACROPOLIS HOST NAME

CVMのホスト名を変える場合は、clusterを作った後にCVM上でrootになって「change_cvm_hostname 新ホスト名」を実行します
参考:Change CVM name
change_cvm_hostnameで変えたらPrismで「Rename CVM back to what it was originally. The CVM name is nonconfigurable by the end user.」という警告が・・・
どうやら、いまのバージョンではお薦めではないらしい

Windows Server 2019 Insider Preview 17623から17692にアップデートしたらライセンス認証できていない



テスト環境としてWindows Server 2019 Indiser Preview Build 17623をインストールしている環境が使用期限切れを迎えたので、Windows Server 2019 Indiser Preview Build 17692に更新してみた。

再インストールしろ、ってあったが、CドライブにISOイメージを置いて、その中のsetupを実行してみると、アップデートが完了した。

しかし、ライセンス認証ができていない。
「Windows ライセンス認証 サーバーに到達できません」というエラーとなっている。

“設定”の”ライセンス認証”にある「プロダクトキーを変更します」だと、サーバーに到達できずエラーとなる。
よく見てみるとプロダクトキーの末尾5文字が、元の環境で使用していたものとは異なるものになっている。

コマンドで設定する方法がないか確認してみると「slmgr」コマンドで設定できることを発見。

今回使用しているのはStandard Editionなので、ダウンロードページにある下記記述を元にコマンドを実行

Datacenter Edition 6XBNX-4JQGW-QX6QG-74P76-72V67
Standard Edition MFY9F-XBN2F-TYFMP-CCV49-RMYVH

「slmgr /ipk MFY9F-XBN2F-TYFMP-CCV49-RMYVH」を実行
Microsoft Windows [Version 10.0.17692.1000]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\Administrator>slmgr /ipk MFY9F-XBN2F-TYFMP-CCV49-RMYVH

C:\Users\Administrator>

これで、無事更新できました。

Zentyalを日本語で使う場合の設定手順


Linux(Ubuntu 16.04 LTS)ベースでDHCPサーバ/ファイヤーウォール/NATルータ/ActiveDirectory/Exchange互換サーバなどを提供できるアプライアンス「zentyal」を久々にセットアップ。

(2019/07/02現在だとUbuntu 18.04.1 LTSベースのZental 6.0です。この記事はZental 5.1の時に作成していますが、Zentyal 6.0でも同じでした。)

以前、日本語訳を投稿しておいたおかげで日本語を選択できるようになっていますが、注意点が1つ。
インストール時に日本語を設定してしまうと、firefoxが文字化けし、設定に難儀します。
まずはEnglishでインストールを行った上で、手動でパッケージを追加してから日本語に変更する必要があります。

1. EnglishでZentyalをインストール
2. 初回ログイン
3. シェルを開く
4. Ubuntuの日本語対応をインストール「sudo apt install language-pack-ja firefox-locale-ja」
5. 日本語表示用フォントをインストール「sudo apt install fonts-arphic-uming fonts-takao-pgothic」
6. zentyalの日本語対応をインストール「sudo apt install language-pack-zentyal-ja」
7. zentyalの設定画面で「日本語」を設定する。

文字化け状態の例

文字化け解消後

なお、yahooのページだと「fonts-arphic-uming」だけでも大丈夫だったが、zentyalではさらに「fonts-takao-pgothic」を追加する必要があった。
なお、 xfonts-intl-japanese では文字化けは直らなかった。

ブラウザにログインしなくても使えるiLOリモートコンソール for Windows



HPE ProLiantサーバのリモート管理機能iLOには、ネットワーク経由でモニタ/キーボード/マウス操作を可能にするリモートコンソール機能がついている。
iLO用に専用のIPアドレスを割り当てブラウザからログインすると、Javaか.NETかHTML5でリモートコンソールが使えるようになる。
Javaと.NETではブラウザを表示している端末のローカルにあるISOイメージをProLiantサーバ上のDVD-ROMドライブとして認識させ、ブートさせることができるVirtual Driveという機能もある。

ただ、昨今のブラウザのセキュリティ強化の流れでJava/.NETともに使おうとすると、結構面倒くさい。
なんとかならないのかな、とマニュアルを読み直してみたら、スタンドアローンリモートコンソールなるものを発見。

HPE Lights-Outスタンドアロンリモートコンソール for Windows

このアプリケーションをWindows端末にインストールすることで、ブラウザを起動することなく直接iLOのリモートコンソールを開くことができる、というもの。
.NET Framework 3.5 SP1以降が必要であるようです。

起動してみると、こんな感じで接続先のIPアドレスとユーザ名/パスワードを要求されます。

複数のサーバを開く場合も、もう1個立ち上げるだけでいいので、簡単です。

Backup ExecでHyper-V仮想マシンバックアップ/リストア時にGRT用テンポラリディレクトリは使われるのか?



Backup ExecではHyper-V/vSphereの仮想マシンバックアップを仮想レイヤーの方からバックアップを行った場合、その仮想マシンの上でWindowsが動いている場合は、ファイル単位でのリストアを行えるGRT機能というのをサポートしている。

で・・・Backup Execの設定を見ていくと、全体設定の中に
・Granular Recover Technology
  バックアップ時にBackup Execが一時的にデータを保存するパス C:\TEMP
  リストア時にBackup Execが一時的にデータを保存するパス   C:\TEMP
というものがある。

仮想マシンバックアップ時にC:\TEMPを観察してみたけど、使用している様子が見受けられない。
不思議に思って調べてみた

Veritas Backup Exec 管理者ガイド「Granular Recovery Technology」の「Granular Recovery Technology を使うバックアップ用の推奨デバイス」

ディスクデバイス、重複排除デバイス、およびディスクカートリッジデバイスに送信された GRT 対応のバックアップジョブの暗号化を有効にすると、Backup Exec は詳細バックアップセットを暗号化された形式でディスクに格納しません。GRT 非対応のバックアップソースのバックアップセットのみが暗号化型式で格納されます。 クラウド、OpenStorage、およびテープデバイスに送信されるバックアップジョブのすべてのバックアップセットは、暗号化型式で格納されます。

ファイルサイズの制限があるボリューム上でディスクストレージデバイスを使う必要がある場合、Backup Exec ではステージングの場所が必要です。 Backup Exec はバックアップジョブの実行中に少しのメタデータをステージングの場所に一時的に格納します。 バックアップが終了したら、ステージングの場所からデータを削除します。 ただし、ファイルサイズの制限がないボリューム上のディスクストレージデバイスを宛先として使う場合、ステージングの場所は必要ありません。

ステージングの場所のデフォルトのパスは C:\temp です。

テープ装置などを使っている場合はステージングの場所が必要。
ローカルのNTFSディスクやCIFS共有を使っている場合は、「ファイルサイズの制限に制限がないボリューム」なので、ステージングの場所は不要。

というわけで、今回テストした環境は、CIFS共有をバックアップ保存先としていたため、ステージング領域が不要であった。ということのようでした。