ブログトップ 記事一覧 ログイン 無料ブログ開設

Simple is Beautiful このページをアンテナに追加 RSSフィード Twitter

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2017/06/07 (水)

[]APIとか言われましても…な人向けの便利機能(UCS ManagerのGUI操作をスクリプトに自動変換)

CiscoはUCSの管理操作をPowerShellから実行するためのPowerToolと呼ばれるCmdletプラグインや、Pythonから実行するためのPython SDKなどを提供している。PowerToolの方はもう正式サポート範囲なのでcisco.comから、Python SDKの方はまだバージョン0.9扱いでコミュニティサイトから入手する形になっている(どちらもDevNet経由でも入手可能)。

PowerToolの方のオブジェクト数を数えてみると2300を超えている。基本的にUCS ManagerのGUI操作でできることは、PowerToolを用いたPowerShellスクリプトでも操作できるといっていい。

f:id:takaochan:20170606163901p:image

でも、だからといってすぐにスクリプトを活用した運用を実践できるかというと、なかなか難しいであろうこともまた事実。ちょっと頑張れば人力処理で片付いてしまう設定変更などをスクリプト化する労力をかけるかどうか迷っているうちにずるずると、といった場面も多いんじゃないかと思う。

そんな場合に便利なのが、GUI操作をスクリプトに変換してくれる機能。もちろん、これだけで運用に必要なスクリプトを準備できるわけではないけれども、GUI操作とスクリプトを結びつけて確認することができるので、スクリプトをどう書けばよいのか参考にすることができるし、まずはパラメータを手作業で修正して使用するだけでも、GUI操作あるあるであるオペミスを削減することもできるだろう。次に変数部分を代入できるようにすれば、立派に自動化の第一歩だし、さらに繰り返し処理で展開や構成変更などをできるようにしてしまえば、オペミスも無ければ無駄なことに時間が取られることもない、ステキな運用が実現できる。

現状、UCS ManagerにはJavaアプレット版とHTML5版がある。方法は違えども、どちらを利用した場合でもGUI操作をスクリプトに変換できる。

Java版の場合はローカルでネイティブアプリ(JavaVM経由ではあるけれど)として動作するので、ログファイルをリアルタイムで監視することによって操作を即スクリプトに変換させることができる。

f:id:takaochan:20170606163902p:image

HTML5版の場合は、ログファイルをローカルに吐き出すことがちょっとむずかしいので、操作ログをXMLとして生成した上で、それを元にスクリプトを生成させるという手順になる。下記のように、HTML5版のUCS Managerにログイン後、Ctrl-Alt-Qを押すと画面上部に[Record XML]というリンクが表示されるので、ログに記録したい操作を開始する前にクリックし、必要な操作を終えたら再度同じ場所にある[Stop XML Recording]というリンクをクリックしてログファイルを出力させればよい。

f:id:takaochan:20170606163903p:image

あとはJava版の場合とほぼおなじ。ただし、リアルタイムでは変換は行えないし、ログファイルを指定する必要がある。

f:id:takaochan:20170606163904p:image

このログファイルからは、PowerShellスクリプトだけでなく、Python SDKを用いてPythonスクリプトに変換することもできる。

f:id:takaochan:20170606163905p:image

まずはこうした機能を使って、何度も繰り返すことが多いGUI操作からスクリプト化してみる、という辺りから始めてみるのはいかがでしょうか?

2017/05/25 (木)

[]ESXiホストにNexus 1000v/AVS の VEM (Virtual Ethernet Module)をアンインストール・インストールする手順

vSphere ESXiホストの分散仮想スイッチを拡張するNexus 1000vやAVS(Application Virtual Switch)では、Kernelモジュールに加えてユーザランドでVEMの管理プロセス(VEM Agent/vemdpa)が動作している。インストールしているバージョンなどはesxcliコマンドで確認することが可能。

[root@esx3:~] esxcli software vib list | grep cisco-vem
cisco-vem-v365-esx             5.2.1.3.2.14.0-6.0.1                   Cisco   PartnerSupported  2017-03-28

ちなみに上記は Cisco ACI のための 拡張分散仮想スイッチである AVS の例となっているので、サポートレベルは PartnerSupported となる。最新のVEMは vSphere 6.5 もサポート。まぁVMwareは将来的にパートナー向けに公開していたAPIを塞ぐらしいが…。

さておき、VEM Agentはvemコマンドを通じて様々なVEMの情報を取得したり管理操作を行ったりすることができるツールで、以下のようにvemコマンドでバージョンやステータスなどを確認することが可能。

[root@esx2:~] vem status

VEM modules are loaded

Switch Name      Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch0         4082        6           128               1500    vmnic2,vmnic3
vSwitch1         4082        3           128               9000    vmnic4,vmnic5
DVS Name         Num Ports   Used Ports  Configured Ports  MTU     Uplinks
VMM-AVS-DC2      1024        18          1024              1500    vmnic1,vmnic0

VEM Agent (vemdpa) is running

stopDpa
VEM SwISCSI PID is
Warn: DPA running host/vim/vimuser/cisco/vem/vemdpa.37515
Warn: DPA running host/vim/vimuser/cisco/vem/vemdpa.37515
watchdog-vemdpa: Terminating watchdog process with PID 37507

このように常時VEM Agentが動作している為、単にesxcliコマンドで削除しようとしても下記のようにエラーとなる。

[root@esx3:~] esxcli software vib remove --vibname cisco-vem-v365-esx
 [LiveInstallationError]
 Error in running rm /tardisks/cisco_ve.v00:
 Return code: 1
 Output: rm: can't remove '/tardisks/cisco_ve.v00': Device or resource busy

 It is not safe to continue. Please reboot the host immediately to discard the unfinished update.
 Please refer to the log file for more details.

よって、VEMのアンインストール操作を行う場合は、仮想マシンの退避と分散仮想スイッチからのホストの削除を行った上で、さらにvem stopコマンドでVEM Agentを停止させる必要がある。VEMをアンインストールしなければならない状況としては、AVSは冒頭で書いたとおりPartnerSupportedのモジュール扱いとなるため、ESXiホストを6.0から6.5にアップグレードする場合などは一旦アンインストールした上で実施する必要がある。

VEMがインストールされたままでESXiを6.0から6.5にアップグレードしようとすると、以下のようなエラーになる。これはISOファイルを使ってアップグレードしようとした場合の例。

f:id:takaochan:20170524174927p:image

VEMはvibファイルとして提供されているので、ESXiホストのアップグレード後に改めてesxcliコマンドでインストールすれば良い。一旦アンインストールしているので、アップグレードではなくインストール。

[root@esx3:~] esxcli software vib install -v "http://x.x.x.x/Cisco/ACI/2.2(2e)/CiscoAVS_3.2-5.2.1.SV3.3.2-pkg/CiscoAVS_3.2-5.2.1.SV3.3.2/CiscoAVS_3.2-5.2.1.SV3.3.2
/cross_cisco-vem-v395-5.2.1.3.3.2.0-6.5.1.vib"
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: Cisco_bootbank_cisco-vem-v395-esx_5.2.1.3.3.2.0-6.5.1
   VIBs Removed:
   VIBs Skipped:

こんな感じで、ESXi 6.5でもちゃんとAVS用のVEMは動作しておりますョ(*´艸`*)

[root@esx2:~] vem version
Running esx version -4564106 x86_64
VEM Version: 5.2.1.3.3.2.0-6.5.1
OpFlex SDK Version: 2.2(2e)
System Version: VMware ESXi 6.5.0 Releasebuild-4564106
ESX Version Update Level: 0

2017/05/15 (月)

[]vSAN 6.6 Configuration Assist

一通り環境チェックをしてくれるので便利でいいんだけれども、vMotionネットワークをvMotion専用のTCP/IPスタックで構成していると失敗ステータスになるのが微妙。ま、そのうち治るんだろうけれども。これはリリースノートにも明記されているので、既知の問題扱い。

http://pubs.vmware.com/Release_Notes/en/vsan/66/vmware-virtual-san-66-release-notes.html

vMotion network connectivity test incorrectly reports ping failures

The vMotion network connectivity test (Cluster > Monitor > vSAN > Health > Network) reports ping failures if the vMotion stack is used for vMotion. The vMotion network connectivity (ping) check only supports vmknics that use the default network stack. The check fails for vmknics using the vMotion network stack. These reports do not indicate a connectivity problem.

Workaround: Configure the vmknic to use the default network stack. You can disable the vMotion ping check using RVC commands. For example: vsan.health.silent_health_check_configure -a vmotionpingsmall

Workaroundがdefaultのネットワークスタックを利用するか、Ping Checkを無効化するかって…オイ(^_^;)。

f:id:takaochan:20170515153517p:image

2017/05/12 (金)

[]Cisco UCS Manager Plug-in for VMware vSphere Web Client

CiscoVMwareと仲良しなのでლ(´ڡ`ლ)、ACIだけでなくUCSのvCenter Pluginもきっちり提供されている。それがこのUCS Manager Plug-in for VMware vSphere Web Client。もちろんこちらも追加コストなどなく利用頂くことが可能。…とはいえ、ここではこのプラグインの全体像の説明とかはしない。1点だけ、自分が気に入ったVIF Path情報をPluginの画面で確認できるところについてだけ。なお、用語重なりが混乱の元凶なのだが、このエントリー内で書くvNICは仮想マシンにとってのネットワークアダプタを意味するvNICではなく、UCSにインストールしたOS/Hypervisorにとってのネットワークアダプタを意味する。イメージ的には世間一般には物理NIC。でもUCSではVICによって論理的に構成された仮想NICなのでvNIC。あーめんど。

UCSではVICを搭載する構成が一般的なので、結果的にVIF/論理インターフェイスを使用することが一般的といえる。UCSにインストールしたOSやHypervisorからはVIFと紐付いたvNICはネットワークアダプタそのものとして認識される。つまり、UCS側でVIFを10個構成すれば、OS/Hypervisorからは10個のvNICを搭載したサーバで動作していると認識される。VICを使う場合、VIFのない構成はない。つまり2ポートの口があるVICで2ポートのネットワークアダプタをOS/Hypervisorが認識している場合であっても、1つのポートに1つのVIFが紐付いているデフォルト構成のまま使っている、というだけの話で、つまり実際にはVIFを使っている。

他のNICベンダーのネットワークアダプタでも論理インターフェイスを構成する機能はあったりするが、おそらくここまで一般的に論理インターフェイスを構成して使用する仕組みを活用しているサーバはUCSだけだろう。なぜなら、論理インターフェイスを活用するためにはサーバ側の構成(=VICの構成)だけでは不十分で、上位スイッチ側も含めて構成して初めて活用できるからだ。ラックサーバタイプのUCSは単体でも使用できるが、ブレードサーバタイプのUCSは必ずFabric Interconnect(FI)と呼ばれるUCSの管理機能(=UCS Manager)を加えた特殊なNexusスイッチをあわせて使用する。UCS ManagerはUCS全体を管理する。つまり、UCSのサーバ部分だけではなく、自身が実行されている環境であるFIも管理している。これによって、VICにVIFを構成すると自動的にFI側も構成されているため、UCSの利用者はサーバとネットワークを意識することなく、シンプルにVIFを構成して利用することができる。つまり、VIFはOS/Hypervisorから見た論理ネットワークアダプタ(=vNIC)であるというだけではなく、論理ネットワークケーブルによって上位スイッチの論理ポートに接続されるまでの全体を意味しているということだ。図示するとこんな感じ。

f:id:takaochan:20170512172931p:image

…説明はここまでにして、vCenterのUCS Plug-inでVIF情報を確認できると何が嬉しいの?という話。

まずはVIFによって構成されているvNIC、つまりはOS/Hypervisorから見たNICについてのプラグインの画面。ここでは6ポートのNICがあるという情報になっているが、これらは当然ながら物理NICが6ポートあるのではなく、VICによってvNICが6ポート構成されているということを意味する。この画面でUCS側で管理名として設定しているvNICの名前とMACアドレスの情報を参照できる。

f:id:takaochan:20170512170636p:image

で、以下がVIFのパス情報を表示するプラグインの画面。この2つの画面によって、VIFがどの経路のポートに紐付いているかがわかる。つまり、仮想マシンと仮想スイッチのアップリンクポートの関係性みたいな、VIFにおけるvNICとパス(=ポート)の紐付けを確認できる。

f:id:takaochan:20170512165557p:image

ちなみに、ESXiホストとして認識している[物理アダプタ]は、UCS的には物理アダプタではない(^_^;)。ここでもMACアドレスは表示されているので、ここを識別子としてUCSとしてのVIFのvNICと、ESXiとしてのvmnicの紐付けを確認することができる。

f:id:takaochan:20170512171511p:image

…ということで、この三段論法によって、UCSにおけるネットワークの流れをvSphere Web Client側だけで確認できて便利だね、ということが、言いたかったこと。vCenterのプラグインはさておき、この仕組自体はUCS登場時からのお家芸。

UCSという製品の特徴はUCS Managerによる統合管理だ!というのはもちろんなのだけれども、それを支えるハードウェア的な仕組みとしてVICがある。このソフトウェアとハードウェアの組合せで実現している仕組みだからこそ、他社の追随を未だに許さない、UCSならではのネットワークの管理性、構成の自由度などを実現しているのだろう。

ちなみに脱線というかオマケだけど、UCSのブレードサーバでVIC 1240を搭載している場合、VICのメザニンカード自体の帯域は全体として40Gbある(内部的には各IOMに対して20GbでPort Channel接続している)。なので、UCSのブレードモデルにESXiをインストールして物理アダプタの項目を見ると、以下のように速度として 20000 Mb / 20Gb と表示される。面白いね。

f:id:takaochan:20170512172624p:image

2017/04/20 (木)

[] vCenter Server Appliance のアップグレード 6.0 -> 6.5

SUSEベースからPhoton OSベースに変わるので、一時的に別IPアドレスで仮想アプライアンスをデプロイしてデータを移行することになるわけだけれども、まぁ色々とハマりどころはある。

が、色々ある中で、何をまずやっておけばいいかといえば、VCSA6.0仮想アプライアンスのrootアカウントのパスワード変更。vSphere 6.5のリリースノートにも下記のように記載があるので、おそらくこれが原因で上手くいかない場合が多く発生しているのではないかと推測している。

-Attempts to upgrade a vCenter Server Appliance or Platform Services Controller appliance with an expired root password fail with a generic message that cites an internal error

During the appliance upgrade, the installer connects to the source appliance to detect its deployment type. If the root password of the source appliance has expired, the installer fails to connect to the source appliance, and the upgrade fails with the error message: Internal error occurs during pre-upgrade checks.

Workaround:

  1. Log in to the Direct Console User Interface of the appliance.
  2. Set a new root password.
  3. Retry the upgrade.

日常操作的にはまったく問題なくrootアカウントでのSSHログインなどはできるので気付きづらいが、vCenterサービスに対するSingle Sign-onとしては有効期限が切れている場合、サービスの制御ができないのでアップグレード処理(Pre-upgrade check)に失敗する。

f:id:takaochan:20170420143703j:image

VCSAのrootパスワードそのものがわからん!もしくはログインすらできん!という場合はKB2069041参照。

この点以外にも、リリースノートに書かれている "Upgrade Issues" の項目はどれもアップグレード作業実施前に目を通しておいて損はない気がする。リリースからこれまでいろいろな人達が踏んできた課題の主な項目そのものだと思われるので。

2017/03/29 (水)

[] RVC (Ruby vSphere Console)にadministratorアカウントでログインできない場合

vSANについて色々どうにかしたい場合に必要になるRVCだが、ログイン時に使用されるドメインはデフォルトドメインとして指定されている対象が使用される。つまり、たとえば rvc administrator@localhost としてログインする場合、デフォルトの設定を使用している場合は administrator@vsphere.local アカウントを意味するということになる。

デフォルトドメインを変更したい場合は、vSphere Web Clientにおいてホームから[管理]-[シングルサインオン]-[構成]配下の[アイディンティティソース]タブを選択し、デフォルトに指定したいドメインを選択して[デフォルトドメインに指定]ボタンをクリックする。設定は即時反映される。

その上で、RVCにログインする。以下はVCSAのローカルShellからログインしている場合の例。

Command> rvc administrator@localhost
Install the "ffi" gem for better tab completion.
WARNING: Nokogiri was built against LibXML version 2.7.6, but has dynamically loaded 2.9.2
password:
0 /
1 localhost/
>

参考KB

Cannot log in to the Ruby vCenter Console using administrator@localhost (2088096)

https://kb.vmware.com/kb/2088096

その他、諸々の環境からRVCに接続したい場合については、以下のBlogが参考になる。

http://www.virten.net/2013/12/getting-started-with-ruby-vsphere-console-rvc/

2017/03/24 (金)

[] Java Web Startのアプリケーション (.jnlp) で unable to launch the application となって起動しない場合の対処方法

備忘録メモ。はやくフロントエンドのJavaは全部HTML5に置き換わればいいのさ。

  • Java Control Panel
    • [General] - [Network Settings]でProxy経由になっている場合は "Direct Connection" にしてみる
    • [General] - [Settings]で[Delete Files]をしてみる
    • [Security] - [Exception Site list]に対象のアドレスを追記してみる
  • 以下のあたりをフォルダごとごっそり消してみる。
    • C:\Users\username\AppData\Local\Sun
    • C:\Users\username\AppData\Local\Oracle
    • C:\Users\username\AppData\LocalLow\Sun
    • C:\Users\username\AppData\Roaming\Oracle

Detailsを表示させた際に以下の例のように (Unknown Source) とかなっている状態の場合は、おそらくこれで改善する。…たぶん。

com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://x.x.x.x/ucsm/unpacked/ccore.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

もちろん、自己責任で。