VMCとかESXiでのパケットキャプチャ
こんばんわ。
ネットワーク安定してますか。
困ったときに使える小技として、パケットキャプチャの手順を（己のために）記しておきます。
■VMC側
VMC側は管理コンソールから「Port Mirroring」を使います。
Sourceでパケットをミラーする「Segment Port」（NIC）を選択します。
（パケットを解析したい元の仮想マシンを選択します。）
NICが複数ある場合は、「View Detail」から接続されたセグメント情報を見れるので、そこからミラーしたいNICを判別します。
つづいてDestination側。こちらは、例えばWiresharkなどをインストールしたWindowsサーバを指定します。
↑で設定したミラートラフィックがこちらに流れてきます。
Destination側は、グループでの指定になるので、グループが内場合は赤枠から作成します。
こんな感じで、Wiresharkサーバ側のIPアドレスを入れます。
グループを作ったら、先程のDestination設定で、そのグループを選択しApplyとすれば、トラフィックがミラーリングされます。
あとはDestination側のサーバでWireshark等を起動すればパケットが見れるはずです！
■オンプレESXi側
オンプレミス側は、NSX Autonomous EdgeやHCX NET-EXTが稼働しているESXiにSSHで接続し、コマンドを実行することでパケットキャプチャが可能です。
最終的に実施するコマンドはコレ
# pktcap-uw --switchport [NICのPort ID] --ip [フィルタしたIPアドレス] --dir 2 -o "/vmfs/volumes/datastore/[保存先]/xxxxxxxxxx.pcap"
dir 2というのは双方向を意味しています。
より詳細のオプションはこちらを参照
NICのPort IDの判別のためのコマンドはコレ
# net-stats -l| grep [仮想マシン名]
複数NICがあるマシンでは、複数の表示がありますので、MACアドレスでどっちがどっちか判別しましょう
PortNum Type SubType SwitchName MACAddress ClientName
67108935 5 7 vDS01 00:50:56:00:00:15 wintest
67108936 5 7 vDS01 00:50:56:00:00:01 wintest
（1行目がパケットキャプチャで指定するID）
ちなみに、取得したパケットキャプチャはWiresharkでも見れますし、簡易的に以下コマンドでもデコードできます。
# tcpdump-uw -r [ファイル名]
これで取得したパケットキャプチャをWiresharkなどで開いてて、どんなパケットが流れているか、はたまたロストしているか解析するわけですね。
なにかのお役に立てれば。
Nested ESXi on VMware Cloud on AWS
こんばんわ
今日は、VMC on AWS上にNested ESXiを構築してみました。
Nested ESXiとは、ESXi上にESXiを仮想化して稼働させるヤツです。
ネスト環境とかネストESXiとかも呼ばれてる気がします。
ちなみに今回の検証は完全にVMwareサポートからは外れる構成になるので、そこだけご注意を。
で、
VMC on AWS上にNested ESXiは、正攻法では構築出来ません。
これはVMCというよりvSANの仕様です。
vSAN環境でNested ESXiをインストールしていこうとすると、、インストールディスクを指定するところでこんなエラーで失敗するようです。
まぁ、オンプレvSAN環境だと、こんなコマンドをESXiで発行すればいけちゃうのですが。
esxcli system settings advanced set -o /VSAN/FakeSCSIReservations -i 1
ただ、VMC環境の場合、ESXiにはSSHログイン出来ないので当然↑ のコマンドも発行できません。そして通常のVMCでは、vSAN以外のデータストアは使えないのでした。。
そこで、
今回試したのは、Veeam Backup&Replication というソフトによるバックアップ/リストア方式です。
流れで言うと、オンプレミスでNested ESXiを構築し、それをバックアップしてVMCに持っていき、VMC側でリストアする、という感じです。
（オンプレにNested構築できる環境あるなら、VMCでNestedする意味ってありますか？はい、あります。）
＜イメージ＞
やってみた、
ら、
とくに変なこともせずに起動できました。
ちなみに、今回はESXi 5.1(無印)をネストしました。
ただ、元々持っていたデータストアは使えなくなってましたし、
ディスクを追加してもデータストアとしてのマウントはできませんでした。
なので、テキトーなLinuxサーバでNFSサーバとiSCSIターゲットをインストールして、Nested ESXiからマウントしてみたら、、、
問題なく出来ましたY。👇
今や懐かしいvSphere Clientですね。5.1なので。
（途中vSphere Clientのバグで、日本語UIでのiSCSIデータストア作成ができず焦りました。。起動オプションで-locale en_US を指定したら回避できるアレでした。）
左側のインベントリ見ていただければわかると思いますが、仮想マシンも問題なく作成できました！
ということで、今回はVMCでも（頑張れば）Nested ESXiを稼働させることができる、ということを紹介させていただきました。
Veeam のレプリケーション機能とかOVAでもVMCに移行できそうですが、どうなんでしょう？時間があれば試してみたいと思います！
2021/2/15 追記
OVFエクスポート/インポートでもNested ESXiを稼働できました！
違いとしては、、
・ネットワークアダプタが正常に認識されず、新規で追加したら疎通とれました
・データストアはそのまま使えました
（Nestedにもともとあった仮想マシンは起動NG。ISOファイルなどはそのまま使用可能）
仮想マシンは、再インストールでこのデータストア上で稼働できましたね。
あと、注意点を忘れていましたが、、、
VMCでは、仮想スイッチのプロミスキャスモード（無差別転送）を設定できないので、Nested ESXi上の仮想マシンは外部には出れません。。
検証目的としては、Nested ESXi上の仮想マシン同士で疎通する場合のみとなりますね。。。
これは現時点回避できないので、使用シーンはかなり限られますが、仕方ありません。
ではでは。
VMCのENIのスループットを実測してみた
こんばんわ
今日は、VMC on AWSとConnected VPCとのスループットを検証する機会がありましたので、紹介したいと思います。
構成イメージはこんな感じです。
<VMC構成>
リージョン/AZ：東京/ap-northeast-1a
SDDCバージョン：1.12
ESXiホスト：i3.metal 3ノード
VM：Windows Server2016 × 3台（各ホストに分散）
＜AWS構成＞
EC2：Windows Server 2016(m5.xlarge) × 1台
＜測定方法＞
ツール：iperf-3.1.3
EC2をサーバーモードで起動し、VMCのVM3台から同時にiperfを実行
結果の前に、、、、
そもそもVMCは、いわゆるAWSインフラストラクチャ上に構築されたサービスです。
ENI(Elastic Network Interface)と記載している部分について、VMCの場合VMware Cloud ENIと呼ばれたりしますが、ENI自体はAWSのコンポーネントになります。
つまり、ENIは、ESXi ホスト（厳密にはベアメタルの ENA(Elastic Network Adapter) ）に対して構成されるコンポーネントです。
↑のように、実態としてはAWSのi3.metalインスタンスのENAであり、AWSの公表値では、ネットワークパフォーマンスは25Gbpsと記載されています。
※ただし、AWS側の仕様によりシングルフロー通信は5Gbpsとなります。
ちなみに、ENIの数は1クラスタあたり17個作成されます。
これは、1クラスタあたりMAXノード 16台(vSAN制約) + メンテナンス用の1つ、です。
また、VMC側の観点では、i3.metalインスタンスをNSXによって仮想化したネットワークとなっているので、T0-Routerを含めたネットワーク帯域は、同じく25Gbpsで構成されています(各VMのNICは10Gbpsです)。
前置きが長くなりましたが、試してみた結果を以下に。
まず、1台のみに対して実施
ウィンドウサイズを変更すると、初回1秒だけ5Gbpsくらいのスループットが出ますが、以降は1Gbps前後に収まります。
3台同時実施
およそ、1台あたり800~900Mbpsのスループットとなりました。
・・・・・・なるほど。
（どこかボトルネックが別にあるかも・・・？）
今回はちょ～～っと軽い気持ちで試してみたのですが、色々試すには時間がない！ということで、続きの検証は次回以降に持ち越したいと思います。
おそらくVM数を増やせばそのぶんスループットは上がるものだと思います。
あとは、スペックとかOS設定とか仮想NICとか、EC2側の構成とか色々ありますが、なかなかどうしてパフォーマンス検証というのは、往々にして深みにハマることがありますよね。。。
という言い訳を残しつつ今回はオサラバさせていただきます！ﾄﾞﾛﾝ
※追記
どうやらボトルネックは、EC2のスループットだったようです。
上記の通り、EC2はm5.xlarge(Network Perfomance:Up to 10 Gigabit)でしたが、、、この「Up to」はいわゆるバーストした際の最大スループットでございます。
・・・・じゃあ、ベーススループットはナンボなの？
という話ですが、AWS公式ではネットワークスループットに関してはベース値の記載がない！のです。
（EBSとかは詳細にバーストの仕組みとかベーススループットとかが記載されてるんですが・・・）
で、色々と検証してみたら、m5.xlargeはベースが1Gbps なのではなかろうか、、という結論にいたりました。
X-vCenter-vMotionツールの紹介
ｺﾝﾊﾞﾝﾜｰｰｰ
今回は、Flingsにて開発されている クロス vCenter vMotionのツールを紹介したいと思います。
このツールですが、VMware Cloud on AWSにも対応しています。
これまでVMware Cloud on AWS へ vMotionする方法は大きく２つありました。
- ハイブリッドリンクモード（HLM）を使用して、オンプレvCenterとクラウドvCenterをリンクさせる方法
- PowerCLIを使用する方法（HLMは不要）
通常、VMware Cloud on AWSを使用する際には、1. のハイブリッドリンクモードを使用することが多いと思いますが、何かしらの制約事項がある際は、このツールを使うことで簡単にGUIでvMotionができちゃいます。
もちろん停止中のマシンも移行や、複製もできちゃいますよ。
必要なのは、このツールとJava Runtime Environmentです。
このツールはvCenterのプラグインとして動作させることもできますし、スタンドアロンのツールとして動作させることも可能です。
ここでは、簡単に、スタンドアロンで使用する方法を紹介します。
使用イメージはこんな感じです。
ますjarファイルを開きます。
で、Webブラウザでアクセスし、
まずは、Registerというところから、vCenterを登録します。
で、移行するそれぞれのvCenterを登録します。
VMC側とオンプレミス側両方を登録すると、こんな感じです。
で、Migrateというタブに移って、
GUIでプルダウン式にそれぞれの項目を埋めて「Submit」を押せば処理が開始されます！
ちなみに、Relocate→再配置、Clone→複製です。
テスト的に実施する場合は、Cloneのほうがオススメです！
また、複数のマシンを選択することもできますよ。
簡単に使用できるので、ぜひ一度お試しアレ★
ただし、Flingsのツールはあくまでプレビューソフトなので、以下規約にご注意のうえご使用ください。本番環境での使用については責任取れませんのでアシカラズ・・・
https://flings.vmware.com/cross-vcenter-workload-migration-utility/license
ただ、このツールはvSphere 7.0 U1Cからは公式ツールとして組み込まれるようです！
ますます便利になりますね。
本日はこのへんで。
vSphere on パブリッククラウドのアレコレ
コンニチは
VMware Cloud on AWS のリリースを皮切りに、他パブリッククラウドでのVMware vSphere環境（VMware Cloud Foundation）の提供が色々と始まってきましたのでなんとなーくまとめてみます。
①Azure VMware Solutions（AVS）
②Google Cloud VMware Engine（GCVE）
③Oracle Cloud VMware Solutions（OCVS）
④IBM Cloud for VMware Solutions（IC4V）
と、AWSと合わせると全部で５つのサービスが提供されています。
また、2020/12月時点ですべてのサービスが日本リージョンで使用可能となっています。
大きな特徴はそれぞれ共通で（あくまでVMware Cloud Foundationなので。）VMC on AWSと同様に、vSAN,NSX,HCX等のVMwareコンポーネントで構成されます。
あえて、特徴的な点を挙げるとすれば、、、OCVSに関してはフルマネージドサービスではないようです。
つまり、他のサービスでは、クラウド側で自動的にメンテナンスパッチ対応などを行ってくれますが、OCVSではVMware環境に対するパッチ適用などはユーザー自身が行う
必要があります。
これがメリットになるかデメリットになるか、はユーザー次第なのかなぁ。どうなんでしょ。
ちなみに、VMware Cloud on AWSでは、インフラレイヤーの管理はVMwareが実施する形になります。
ちなみに、AVSの場合はMicrosoft、GCVSの場合はGoogleが、サービスの監視・管理を実施します。
あとは、OCVSだと東京と大阪の両リージョンが使えるのも今は差別化の要素となりますね。
2021年にはVMware Cloud on AWSも大阪リージョンがリリースされる、という話もあるのでなんともですが。
あと、OCVSでは、Oracle Databaseのライセンスコストが下がるとか下がらないとか(？)
実は実際に使ったことはないのと、ライセンス関連については規約も色々と変わったりするのでここで名言することは避けておきたいと思います。。。。
いずれにしても、これまでAWS以外のパブリッククラウドを使用していたユーザーにとっては、このように、現在使用しているクラウドでもVMware Cloud Foundationが使えるようになってますます便利になるんではないでしょうか！
では、簡単な紹介だけでしたが今回はこのへんで。
Flash Playerのサポート終了に関して
こんにちは
みなさんご存知の通り、Adobe Flash Playerが2020/12月末でサポート終了となります。
vSphere製品には、いくつかFlashを使用するものがありますので、ちょっと確認しておきたいと思います。
ちなみに、このサポート終了ですが、「サポート終了でも使える」ではなく「強制的に使えなくなる」というものなのでご注意を。
これはオフラインでも問答無用でブロックされます。
ちなみに、2021/1/11が、そのXデーです。
VMwareも、VMware Flash End of Life and Supportability というKBを出していますので、みなさんも確認しときましょう！
個人的にちょっと困るのが、Horizon Administratorですねえ。
Horizon 7は、7.13以下のバージョンのジェネラルサポートが、2021/3/22 となっています。
この中でHTML版のHorizon Consoleが使えないのが、7.8まで。で、手元に7.4を使用している環境があるので、本来であれば、Horizonをバージョンアップすべきなんですが、、、、取り急ぎ、上記KBの対処で乗り切ろうと思います。
ちなみに、Horizon Console自体は7.8で実装されていますが、機能追加/修正等の兼ね合いか、7.10以上が推奨となっています。
※以下の方法でのFlash利用は、VMwareはサポートしないので自己責任でお願いします！
KBに従って、、、以下のフォルダを作成し、
mms.cfgというファイルを作り、以下のように記述します。
EOLUninstallDisable = 1
EnableAllowList = 1
AllowListRootMovieOnly = 1
AllowListUrlPattern = https://localhost/admin/
このAllowListUrlPattern というのが、Flashを許可する宛先URLになります。
Horizon Administratorの場合、/admin/を忘れないようにしましょう。
また、コネクションサーバから自分（localhost）のHorizon Administratorを見る場合は、上記の書き方になりますが、これはあくまでクライアント設定になるので、別のマシンからHorizon Administratorにアクセスする際は、クライアント側全てに設定が必要です。その際のURLは、実際のHorizon AdministratorのFQDNにして下さいね。
最後にAdobe社の詳細な情報も紹介しておきます。
ではでは。
VMware Odysseyって何？
こんにちわ
来る11/10～11/12 にVMworld 2020が開催されます！
今年はCOVID-19のせいで、オンライン開催になりますね。
本当COVIDは早く滅されないかなぁ。。ｱﾏﾋﾞｴｪ------（=人=）
と、そのVMworld 2020の中で、VMware Odysseyなるプログラムが開催されます。
2019のvForumではチーム対向でだったのが、今年は個人種目になるみたいです。
ということで、Hands-On Labを通してVMware製品を触りながら、与えられた課題に対して誰が最も早く正解に辿り着くか！？を競う、とてもユニークなプログラムです。
楽しみですね！インターネットとブラウザがあれば誰でも参加できるので、是非景品のハンモックをGETしましょう！
でわ、当日楽しみましょう！
VMware Cloud Disaster Recovery 発表！
こんちわ
このたび、VMware Cloud の新たなDRaaSサービスである、「VMware Cloud Disaster Recovery」が発表されたので紹介したいと思います。
簡単に言うと、「オンプレミスのvSphere環境のバックアップをVMware Cloudに保管し、DR発動時にVMware Cloud on AWSで復元させる」ことができるサービスになります。
VMをそのまま稼働できる点、オンデマンドで稼働できる点等のVMware Cloud on AWSのメリットを活かしたDRサービスと言えますね！
まだ日本リージョンはリリースされていないですが、今後に期待です！
これまで、VMwareのレプリケーションツールといえば、Site Recovery Managarがありました。VMC on AWS でも VMware Site Recoveryという名称で提供されてましたが、簡単に比較を以下に記載します。
という感じです。
従来のVMware Site Recoveryは、Hot DRaaS
新しいVMware Cloud Disaster Recoveryは、Warm DRaaS
となりますので、これまでVMware Site Recoveryは高価のために敬遠していたユーザー様にとっては、最良の選択肢になりそうですね。
これまでは、上記のような用途だと、3rd Partyのバックアップソフトを使用したDRソリューションがメインでしたが、新たな選択肢として是非ご検討ください！
ではでは。
VMware Cloud on AWS でのvCenterアラートとLog Insight Cloud
こんぼんわ
今日は、VMware Cloud on AWSでのvCenterアラートについて紹介したいと思います。
早速ですが、VMCのvCenterでは従来のvCenterアラートのSNMP通知やメール通知ができません！
厳密にいうと、メールは飛ばせるのですが、👇の画面例の通り、メール送信者が「空」で、かつ編集ができないようになっているのです。
メール送信者が空なので普通のメールサーバだと受信できないorスパムとかだと判定されちゃうっていう塩梅です。
ちなみに、vCenterアラート自体は作成はできるのですが、すでにあるものを編集したりはできません。
VMC on AWSの場合、ESXiとかvCenterとかNSXはVMwareが管理するので、あまり監視については気にしなくていいんですが、
ちょっと気をつけないといけないのが、VMC on AWSの機能の1つであるEDRS（Elastic DRS）という機能です。
EDRSって何？
簡単に説明すると、「リソースが足りなくなってきたら自動でノードを追加/削除してくれる」機能です。
（・・・まぁ削除に関してはあってないようなものですが）
イメージ👇こんな感じです。
大変素晴らしい機能なんですが、1つ大きな問題が・・・・
「ノード増えたら、その分ライセンス費用かかっちゃうじゃん」っていうアレです。
なので、できる限りEDRSを発動させたくない、という意見をよく耳にします。
あと、2ノード構成の場合、一度3ノードに拡張されたら二度と2ノードに戻れない、というのも注意点です。
で、EDRSはデフォルトで、vSANデータストアの使用率が75%を超えると発動します。
そして、この閾値は変更することができず、無効化することもできません。
（このあたりはvSANの仕様によるもので、vSANでは常に25%のスラックスペースを確保することが推奨されているのです。）
デフォルトだと、この拡張ポリシーのみが有効で、閾値を下回っても削除はされません。
（CPUやメモリのEDRSポリシーだと縮小ポリシーがありますが、縮小するための閾値が相当厳しいので、ほぼほぼ発動しないのではないかなぁ、と思います。ストレージ使用率が20%以下、とかが目安です。）
「じゃーデータストア使用率を監視して、閾値になったらアラート通知すればいいじゃん」と思うんですが、冒頭の通り、vCenterからはメールが飛ばせないワケです。
Log Insight Cloud
簡単にメールを通知できる仕組みとして、
VMware vRealize Log Insight Cloud（vRLIC）を使用する方法を紹介します。
vRLICは、VMware Cloud on AWSを購入すると、無償で一部の機能を使用することができます。
https://cloud.vmware.com/jp/log-insight-cloud/pricing
有償版との違いとしては、以下くらいです。
・ログの保管日数が、7日間（有償版30日間）
・コンテンツパックの一部が使えない
vRLICには、VMCのvCenter含めたログが自動で転送されており、ログを簡単に検索したり閲覧することができるサービスです。
そして、vRLIC自体は、ログ管理・監視ツールですが、メール送信が可能なサービスでもあります。
やり方は、
- vCenter側でvCenterアラームを作成する
（例えば、データストア使用率が60%を越えたらwarningを出す） - vRLIC側でAlert Definitionsを作成する
このときに、クエリでvCenterアラーム名などを抽出するようにします。
実際の設定画面例だとこんな感じです。
vCenter側では、「WorkloadDatastore usage ~~~~~」という名前のアラーム定義を作っていたので、その用語とwarning = yellowを組み合わせたクエリを作成し、Notificationに指定した宛先にメール通知を設定しています。
と、こんな感じで簡単かつ無償でアラートのメール発報システムを構築することができます！
また、vRLICのログ保管日数は無償版7日間と書きましたが、ログをまた別のsyslogサーバ等に転送することは可能です。
そのやり方はまた次回にでも！
あと、上の画像にチラッと見えますね。Log Archival（BETA）の文字が。
これは、VMware管理のS3にログをアーカイブしてくれる、という機能です。現時点、自分のS3バケットなどに保管することはできません、、、今後に期待！
ということで、今回は。このへんで。
DEWADEWA
