自然の赴くままに・そのときの 気分次第で・なんとなく

興味を持ったことを、なんとなく気の向くまま書いています。

VMware 製品のライセンスモデル販売終了のアナウンスが KB96168 でありました

※ライセンスに関しての情報公開先が変わっていますので、こちらの記事ではなく以下のリンクの記事を参照ください。

imaisato.hatenablog.jp

こちらの記事は「過去情報」としてそのまま存置します。

-----

Broadcom によって買収された VMware ですが、いよいよ永続ライセンス(パーペチュアルライセンス)の販売終了が KBアナウンスされました。

kb.vmware.com

どのプロダクトの永続ライセンスが終了したの?

1月18日現在で、以下のプロダクトの永続ライセンスの販売が終了しました。

製品 (すべてのエディションと価格設定基準)

VMware vSphere Enterprise Plus
VMware vSphere+
VMware vSphere Standard (excluding subscription)
VMware vSphere ROBO
VMware vSphere Scale Out
VMware vSphere Desktop
VMware vSphere Acceleration Kits
VMware vSphere Essentials Kit
VMware vSphere Essentials Plus Kit (excluding new subscription offering)
VMware vSphere Starter/Foundation
VMware vSphere with Operations Management
VMware vSphere Basic
VMware vSphere Advanced
VMware vSphere Storage Appliance
VMware vSphere Hypervisor
VMware Cloud Foundation (excluding new VCF subscription offering)
VMware Cloud Foundation for VDI
VMware Cloud Foundation for ROBO
VMware SDDC Manager
VMware vCenter Standard
VMware vCenter Foundation
VMware vSAN
VMware vSAN ROBO
VMware vSAN Desktop
VMware HCI Kit
VMware Site Recovery Manager
VMware Cloud Editions/ Cloud Packs
VMware vCloud Suite
VMware Aria Suite (formerly vRealize Suite)
VMware Aria Universal Suite (formerly vRealize Cloud Universal)
VMware Aria Suite Term
VMware Aria Operations for Networks (formerly vRealize Network Insight)
VMware Aria Operations for Networks Universal (formerly vRealize Network Insight Universal)
VMware vRealize Network Insight ROBO
VMware Aria Operations for Logs (formerly vRealize Log Insight)
VMware vRealize Operations Application Monitoring Add-On
VMware Aria Operations
VMware Aria Automation
VMware Aria Automation for Secure Hosts add-on (formerly SaltStack SecOps)
VMware vRealize Automation SaltStack SecOps add-on
VMware Aria Operations for Integrations (formerly vRealize True Visibility Suite)
VMware Cloud Director
Cloud Director Service
VMware NSX
VMware NSX for Desktop
VMware NSX ROBO
VMware NSX Distributed Firewall
VMware NSX Gateway Firewall
VMware NSX Threat Prevention to Distributed Firewall
VMware NSX Threat Prevention to Gateway Firewall
VMware NSX Advanced Threat Prevention to Distributed Firewall
VMware NSX Advanced Threat Prevention to Gateway Firewall
VMware NSX Advanced Load Balancer (excluding Subscription, SaaS)
VMware Container Networking Enterprise with Antrea
VMware HCX
VMware HCX+

これらの製品については1月15日以降見積りをしていたとしてもこれからは全て VMware 側で拒否されるため、1月15日前の見積りでは購入が出来なくなります。もちろん1月15日以降は見積りもできません。

ここで気になるのが一つ、無償で使えていた「VMware vSphere Hypervisor」も EOA になります。今までは vCenter Server 使わなくてよくて、でも仮想化環境使いたいなというときにこの「VMware vSphere Hypervisor」が便利だったのですが、このライセンスが終了になるので永続的に使い続けることが出来なくなります。評価版も期間が決まっていてかつ同じアカウントでは1回しかダウンロードできないので、家ラボとかちょっと検証とかに使うことができなくなるのが残念です。

ライセンス販売終了によるユーザーへの影響は?

VMware では以下のようなソリューションを持って代替すると書かれています。
「2023 年 12 月 11 日に発表されたとおり、VMware は、ポートフォリオを合理化および簡素化し、永久ライセンスからサブスクリプション モデルへ移行するという過去 2 年間の取り組みにおいて、新たなマイルストーンに到達しました。 当社は、ポートフォリオを簡素化し、当社の最高のテクノロジーである VMware Cloud Foundation と VMware vSphere Foundation に重点を置いたいくつかのオファーと、オプションの高度なアドオン オファーを提供しました。

以下の製品は提供終了 (EOA) となっています。 特に明記されていない限り、永久、サポートおよびサブスクリプション (SnS)、SaaS/ホスト型、サブスクリプションを含むすべてのライセンス オプション、および各製品のすべてのエディション、スイート、および価格設定基準がこの発表に含まれています。 これらの製品は現在購入できません。 将来的にはリニューアルの際に、お客様のニーズに合わせた最適なサブスクリプション商品をご提供させていただきます。」

つまり、サブスクリプションを買い直してねという形になります。

また VMware vSphere に関しては、サブスクリプション型で以下のプロダクトが販売されます。それ以外の例えば VMware vSphere Essentials などは販売されないので、使用しているプロダクトが廃止になってしまった場合は、下記のどれかに移行する必要があります。

VMware Cloud Foundation はハイブリッドクラウドを構成したいユーザー向けで大規模環境に適するとしており、それ以外の中小規模環境については VMware vSphere Foundation、そしてシンプルな機能だけなら VMware vSphere Standard で、小規模なら VMware vSphere Essentials Plus Kit をサブスクリプションタイプで使ってねということのようです。vSAN や NSX を使う必要ある場合は「Foundation」の 2つのどちらかが必須になるので、今の環境がどのように使われているかによって移行先を考える必要があります。

直ぐにライセンスを変えなければダメ?

今まで購入しているパーペチュアルライセンスはユーザー所有のものなので、これからもずっと使用し続けることが出来ます。ただし 2023年12月11日以降パーペチュアルライセンスとそれのサポートの販売およびSnS更新は終了しているので、今利用しているサポートの期間終了までしか実質は使えないと考えるのが妥当です。この KB 96168 でも
「既存のお客様で、上記の提供終了製品を購入されているが、更新の準備ができていない場合は、現時点では直ちに対応する必要はなく、VMwareサポート契約の期間中、引き続きアクティブ サポートを提供します。 将来的には、更新時に新しいサブスクリプションの提供や、ニーズに最適な高度なアドオンのオプションを利用できるようになります。」

と書かれている通り、現行の SnS 契約終了までの間にサブスクリプションに切り替える準備をしてくれと書かれています。そして
「これに関する詳細については、VMware アカウント チームおよび営業担当者にお問い合わせください。」
とあるので、VMware と相談しながら適切なサブスクリプションへの移行パスを見つけてくれということのようです。そのためのインセンティブやアップグレード価格も用逸しているとのことなので、慌てずにまずは BroadcomVMware 営業に確認するのが先決・・・ですね。

気になる VMware Cloud on AWS の行方は?

今回の VMwareBroadcom に買収されることにより、今までは VMwareAWS が販売していた VMware Cloud on AWS の動向が気になります。個人的には VMware 側で VMware Cloud on AWS の販売は止めるのではないかなと感じています。つまり Microsoft Azure VMware Solution や Google Cloud VMware Engine のように、クラウドサービスプロバイダー(CSP)側だけで販売する形になっていくような気がします。または Oracle Cloud VMware Solution のようにアンマネージドでユーザーが管理する形態になる可能性も考えられます。
ただ、本当に VMware Cloud on AWSVMware が売らなくなって管理そのほかの形が変わることになった場合、何らかの手間がユーザーに発生する可能性も考えられるので、今後の動向が気になるところです。

サブスクリプションに変わるプロダクトは?

以下のプロダクトがサブスクリプションモデルに変ります。

このライセンスの変更に伴う販売終了の情報はまだ英語でしか出ていないので、日本語での情報が出てくるの間はこの英語の KB 96168 を時々見ていく必要がありますね。

サブスクリプションの購入先は?

VMwareBroadcom に買収される前のライセンス購入先は、ハードウエアに添付されていてハードウエアに紐づいている OEM「バンドル」、ハードウエアと一緒に買えるけれどハードウエアには紐づかない OEM「アンバンドル」、ネットワールド、SB C&S、ダイワボウの3社のディストリビューター経由、または VMware の Partner Program に参加していてライセンスを販売できるレベルのパートナー会社がありましたが、このパートナー関連の仕組みが 2月5日より Broadcom の Partner Program に切り替わり、それまでの VMware Partner は2月4日で一度パートナーとしての立場が消滅することになっています。そして新しい Broadcom の Partner Program にはどの会社が参加できるのかは今後決まってくることなので、今まで永続ライセンスを購入していた会社が2月5日以降も永続ライセンスから変わった VMwareサブスクリプションを継続販売できるとは限らないのではないかと感じています。この辺りまだまだ情報が少ないので、心配な場合は確認されることをお勧めします。

VMware Workstation Player 17 の中身を見る : ゲスト OS 識別 2023年編

本記事は、「vExperts Advent Calendar 2023」の最終日用として書いた記事です。
202年の年の瀬も迫ってきていろいろと忙しくなる時期ですが、そんなときに限って好きなことや興味を持ったことをいろいろと調べ Dive deep したりしてしまいます。

昨年は

imaisato.hatenablog.jp

 

一昨年は

imaisato.hatenablog.jp

こんなことを、その前の年は

imaisato.hatenablog.jp

なことをやっていました。しかし残念なことに今年は vExpert Desktop Hypervisor が無くなってしまっていたので、ブログの更新もモチベーション下がってやる元気なくなってしまったのと、鉄道趣味の方に全力投球をしていたためほぼこちらのブログの更新も止まってしまっていました。ということで、今年の Advent calendar 用に VMware Workstation 17 Player の中身を見るというテーマで記事を書いてみます。

VMware Workstation 17 Player とは

VMware Workstation 17 Player とは、有償で利用でき VMware Workstation 17 Pro のサブセットで、1つの仮想マシンだけを動かすことのできる無償のデスクトップハイパーバイザーです。

VMware Workstation 17 Player

この記事執筆の時点の最新版は Build 22631.2715 で、以下のページからダウンロードができます。

www.vmware.com

VMware Workstation Player は2つのライセンス形態があり、商用以外での利用および個人利用の場合は無償バージョンを利用することができます。また学校の場合の生徒や学生そして非営利組織も無償で利用することが出来るものです。

それに対して企業や営利団体など商業組織で利用する場合は、別途商用ライセンスの購入が必要になります。なので会社で仕事をしているときに「仮想環境使いたいなぁ。そうだ、VMware Workstation Player を入れて使おう!」は個人利用ではなく業務利用になるので、別途有償ライセンスを購入する必要があります。

VMware Workstation 17 Player の中身を見る」とは

私自身 VMware 創業時から VMware Workstation を使い続けていて、新しいバージョンが出るたびにいろいろな機能が追加されていくということと、それに伴って vmx ファイルに記述されるパラメーターが増えているのがずっと気になっていました。これ、プログラムの中でどのように読み取っているのかなと。また、それぞれのパラメーターの設定はどんなのがあるのかなということも気になっていて、いろいろな情報をあさってみたのですがなかなか細かく書かれてるものにたどり着けません。いくつかの情報は以下のようなサイトに書かれているのですが最新のものは見当たらない。

昨年の春に IT 仕事はいったん引退した時点で暇な時間ができたので VMware Workstation 17 Pro の vmx ファイルを紐解き前回のブログの記事(VMware Workstation Pro 17 の中身を見る : ゲスト OS 識別編)を描いたのですが、それから 1年たって VMware Workstation 17 でサポートされているまたはサポート予定のゲスト OS がどのように変わったかを調べてみることにしました。今回は前回と異なり VMware Workstation 17 Pro ではなく VMware Workstation 17 Player を調べています。同じものでないと比較にならないということもあるのですが、VMware Workstation Pro 17 の再インストールが面倒だったということでご容赦を。

VMware Workstation Player 17 でゲスト OS を識別するには

VMware Workstation Player 17 の vmx ファイルには「guestOS」というパラメータがあります。これには以下のように = の後ろに仮想マシンで動作させるゲスト OS を記述します。例えば Windows 10 の場合は

guestOS = "windows9-64"

Windows 11 の場合は

guestOS = "windows11-64"

のように記述されます。
このゲスト OS は仮想マシンを作成する際に「ゲスト OS の選択」で適切なものを選択されるだけで自動的に設定されます。下記キャプチャは Windows で選択できるゲスト OS になります。

ゲスト OS の選択: バージョン

そして、この「ゲスト OS の選択」は上記のように適当なものを選んでも仮想マシンを作成することが出来、また起動することもできてしまいます。これ、何の役に立っているのと疑問に思ったりしながら「Windows 11 無いけれど Windows 10で作っちゃえ」とかやっていたと思います。しかし、VMware Workstation Player 17 の内部ではこの設定を読み取って設定された ゲスト OS 特有の機能がある場合はそれを動かすようになっています。
このゲスト OS の文字列をいちいちプログラムの中で評価していたらそれは大変なので実際には 16進のGuest OS IDが割り当てられています。VMware Workstation Player 17 に設定されているコードは以下の通りです。そして一番右の列に記載しているのは、前回の VMware Workstation Pro 17 の中身を見る : ゲスト OS 識別編 で調べたゲスト OS との差分で「存在しない」ものが新しく変わったものになります。ただここで注意しなければならないのは、前回の VMware Workstation Pro 17 では 236のゲスト OS だったのが、今回の VMware Workstation Player 17 では 256 になっているので単純に「ゲスト OS が追加された」ということではなく、あるけれどGuest OS IDが変わっているものが多数ありました。このGuest OS IDは元々アプリ内部での利用前提なので、Guest OS パラメータさえ正しく設定されていればGuest OS IDはアプリが識別できれば良いという感じのようです。つまり vmx に設定されたGuest OS パラメータは正しい値で前回と今回は同じになっているのにGuest OS IDが違うということは、Guest OS パラメータからコードを紐づけているということが推測できます。詳細は下表を見ていただくと理解できるかと思います。

今回 (Workstation Player 17) 前回 (Workstation Pro 17) 前回との差異
Guest OS ID guestOS パラメーター Guest OS ID guestOS パラメーター ID違い 名称違い
0x5030 almaLinux-64 0x5030 almaLinux-64 同じ 同じ
0x508C amazonlinux2-64 0x5083 amazonlinux2-64 異なる 同じ
0x508D amazonlinux3-64 0x5084 amazonlinux3-64 異なる 同じ
0x5031 arm-almaLinux-64 0x5031 arm-almaLinux-64 同じ 同じ
0x5093 arm-CRXPod1-64     追加 追加
0x508F arm-CRXSys1-64     追加 追加
0x5091 arm-CRXSys2-64     追加 追加
0x5040 arm-debian10-64 0x503D arm-debian10-64 異なる 同じ
0x5040 arm-debian11-64 0x503D arm-debian11-64 異なる 同じ
0x5040 arm-debian12-64 0x503D arm-debian12-64 異なる 同じ
0x5040 arm-debian13-64     追加 追加
0x5031 arm-Fedora-64 0x5031 arm-Fedora-64 同じ 同じ
0x504F arm-freeBSD13-64 0x504A arm-freeBSD13-64 異なる 同じ
0x5052 arm-freeBSD14-64 0x504D arm-freeBSD14-64 異なる 同じ
0x5055 arm-freeBSD15-64     追加 追加
0x503A arm-other-64 0x5037 arm-other-64 異なる 同じ
0x5031 arm-other5xlinux-64 0x5031 arm-other5xlinux-64 同じ 同じ
0x5034 arm-other6xlinux-64 0x5034 arm-other6xlinux-64 同じ 同じ
0x5037 arm-other7xlinux-64     追加 追加
0x5046 arm-rhel10-64     追加 追加
0x5044 arm-rhel9-64 0x5041 arm-rhel9-64 異なる 同じ
0x5031 arm-rockyLinux-64 0x5031 arm-rockyLinux-64 同じ 同じ
0x5031 arm-ubuntu-64 0x5031 arm-ubuntu-64 同じ 同じ
0x5078 arm-vmkernel7 0x5070 arm-vmkernel7 異なる 同じ
0x507A arm-vmkernel8 0x5072 arm-vmkernel8 異なる 同じ
0x507C arm-vmware-photon-64 0x5074 arm-vmware-photon-64 異なる 同じ
0x5016 arm-windows10-64 0x5016 arm-windows10-64 同じ 同じ
0x5018 arm-windows11-64 0x5018 arm-windows11-64 同じ 同じ
0x501A arm-windows12-64 0x501A arm-windows12-64 同じ 同じ
0x5029 asianux3 0x5029 asianux3 同じ 同じ
0x502A asianux3-64 0x502A asianux3-64 同じ 同じ
0x5029 asianux4 0x5029 asianux4 同じ 同じ
0x502A asianux4-64 0x502A asianux4-64 同じ 同じ
0x502C asianux5-64 0x502C asianux5-64 同じ 同じ
0x502C asianux7-64 0x502C asianux7-64 同じ 同じ
0x502C asianux8-64 0x502C asianux8-64 同じ 同じ
0x5030 asianux9-64 0x5030 asianux9-64 同じ 同じ
0x5085 centos 0x507C centos 異なる 同じ
0x5086 centos-64 0x507D centos-64 異なる 同じ
0x5087 centos6 0x507E centos6 異なる 同じ
0x5088 centos6-64 0x507F centos6-64 異なる 同じ
0x5089 centos7-64 0x5080 centos7-64 異なる 同じ
0x508A centos8-64 0x5081 centos8-64 異なる 同じ
0x508B centos9-64 0x5082 centos9-64 異なる 同じ
0x502C coreos-64 0x502C coreos-64 同じ 同じ
0x5092 CRXPod1-64 0x5086 CRXPod1-64 異なる 同じ
0x508E CRXSys1-64 0x5085 CRXSys1-64 異なる 同じ
0x5090 CRXSys2-64     追加 追加
0x505C darwin 0x5054 darwin 異なる 同じ
0x505D darwin-64 0x5055 darwin-64 異なる 同じ
0x505E darwin10 0x5056 darwin10 異なる 同じ
0x505F darwin10-64 0x5057 darwin10-64 異なる 同じ
0x5060 darwin11 0x5058 darwin11 異なる 同じ
0x5061 darwin11-64 0x5059 darwin11-64 異なる 同じ
0x5062 darwin12-64 0x505A darwin12-64 異なる 同じ
0x5063 darwin13-64 0x505B darwin13-64 異なる 同じ
0x5064 darwin14-64 0x505C darwin14-64 異なる 同じ
0x5065 darwin15-64 0x505D darwin15-64 異なる 同じ
0x5066 darwin16-64 0x505E darwin16-64 異なる 同じ
0x5067 darwin17-64 0x505F darwin17-64 異なる 同じ
0x5068 darwin18-64 0x5060 darwin18-64 異なる 同じ
0x5069 darwin19-64 0x5061 darwin19-64 異なる 同じ
0x506A darwin20-64 0x5062 darwin20-64 異なる 同じ
0x506B darwin21-64 0x5063 darwin21-64 異なる 同じ
0x506C darwin22-64 0x5064 darwin22-64 異なる 同じ
0x506D darwin23-64 0x5065 darwin23-64 異なる 同じ
0x503E debian10 0x503B debian10 異なる 同じ
0x503F debian10-64 0x503C debian10-64 異なる 同じ
0x503E debian11 0x503B debian11 異なる 同じ
0x503F debian11-64 0x503C debian11-64 異なる 同じ
0x503E debian12 0x503B debian12 異なる 同じ
0x503F debian12-64 0x503C debian12-64 異なる 同じ
0x503E debian13     追加 追加
0x503F debian13-64     追加 追加
0x503E debian4 0x503B debian4 異なる 同じ
0x503F debian4-64 0x503C debian4-64 異なる 同じ
0x503E debian5 0x503B debian5 異なる 同じ
0x503F debian5-64 0x503C debian5-64 異なる 同じ
0x503E debian6 0x503B debian6 異なる 同じ
0x503F debian6-64 0x503C debian6-64 異なる 同じ
0x503E debian7 0x503B debian7 異なる 同じ
0x503F debian7-64 0x503C debian7-64 異なる 同じ
0x503E debian8 0x503B debian8 異なる 同じ
0x503F debian8-64 0x503C debian8-64 異なる 同じ
0x503E debian9 0x503B debian9 異なる 同じ
0x503F debian9-64 0x503C debian9-64 異なる 同じ
0x5001 dos     追加 追加
0x5023 eComStation 0x5023 eComStation 同じ 同じ
0x5024 eComStation2 0x5024 eComStation2 同じ 同じ
0x5029 Fedora 0x5029 Fedora 同じ 同じ
0x502A Fedora-64 0x502A Fedora-64 同じ 同じ
0x5030 flatcar-64 0x5030 flatcar-64 同じ 同じ
0x5047 freeBSD 0x5042 freeBSD 異なる 同じ
0x5048 freeBSD-64 0x5043 freeBSD-64 異なる 同じ
0x5049 freeBSD11 0x5044 freeBSD11 異なる 同じ
0x504A freeBSD11-64 0x5045 freeBSD11-64 異なる 同じ
0x504B freeBSD12 0x5046 freeBSD12 異なる 同じ
0x504C freeBSD12-64 0x5047 freeBSD12-64 異なる 同じ
0x504D freeBSD13 0x5048 freeBSD13 異なる 同じ
0x504E freeBSD13-64 0x5049 freeBSD13-64 異なる 同じ
0x5050 freeBSD14 0x504B freeBSD14 異なる 同じ
0x5051 freeBSD14-64 0x504C freeBSD14-64 異なる 同じ
0x5053 freeBSD15     追加 追加
0x5054 freeBSD15-64     追加 追加
0x5025 linux 0x5025 linux 同じ 同じ
0x5094 linuxMint-64 0x5087 linuxMint-64 異なる 同じ
0x500C longhorn 0x500C longhorn 同じ 同じ
0x500D longhorn-64 0x500D longhorn-64 同じ 同じ
0x5029 mandrake 0x5029 mandrake 同じ 同じ
0x502A mandrake-64 0x502A mandrake-64 同じ 同じ
0x5029 mandriva 0x5029 mandriva 同じ 同じ
0x502A mandriva-64 0x502A mandriva-64 同じ 同じ
0x5070 netware4 0x5068 netware4 異なる 同じ
0x5071 netware5 0x5069 netware5 異なる 同じ
0x5072 netware6 0x506A netware6 異なる 同じ
0x5029 nld9 0x5029 nld9 同じ 同じ
0x5006 nt4 0x5006 nt4 同じ 同じ
0x5029 oes 0x5029 oes 同じ 同じ
0x506E openserver5 0x5066 openserver5 異なる 同じ
0x506E openserver6 0x5066 openserver6 異なる 同じ
0x5029 opensuse 0x5029 opensuse 同じ 同じ
0x502A opensuse-64 0x502A opensuse-64 同じ 同じ
0x507D oraclelinux 0x5075 oraclelinux 異なる 同じ
0x507E oraclelinux-64 0x5076 oraclelinux-64 異なる 同じ
0x5084 oraclelinux10-64     追加 追加
0x507F oraclelinux6 0x5077 oraclelinux6 異なる 同じ
0x5080 oraclelinux6-64 0x5078 oraclelinux6-64 異なる 同じ
0x5081 oraclelinux7-64 0x5079 oraclelinux7-64 異なる 同じ
0x5082 oraclelinux8-64 0x507A oraclelinux8-64 異なる 同じ
0x5083 oraclelinux9-64 0x507B oraclelinux9-64 異なる 同じ
0x5022 os2 0x5022 os2 同じ 同じ
0x5022 os2experimental 0x5022 os2experimental 同じ 同じ
0x5038 other 0x5035 other 異なる 同じ
0x5039 other-64 0x5036 other-64 異なる 同じ
0x5027 other24xlinux 0x5027 other24xlinux 同じ 同じ
0x5028 other24xlinux-64 0x5028 other24xlinux-64 同じ 同じ
0x5029 other26xlinux 0x5029 other26xlinux 同じ 同じ
0x502A other26xlinux-64 0x502A other26xlinux-64 同じ 同じ
0x502B other3xlinux 0x502B other3xlinux 同じ 同じ
0x502C other3xlinux-64 0x502C other3xlinux-64 同じ 同じ
0x502D other4xlinux 0x502D other4xlinux 同じ 同じ
0x502E other4xlinux-64 0x502E other4xlinux-64 同じ 同じ
0x502F other5xlinux 0x502F other5xlinux 同じ 同じ
0x5030 other5xlinux-64 0x5030 other5xlinux-64 同じ 同じ
0x5032 other6xlinux 0x5032 other6xlinux 同じ 同じ
0x5033 other6xlinux-64 0x5033 other6xlinux-64 同じ 同じ
0x5035 other7xlinux     追加 追加
0x5036 other7xlinux-64     追加 追加
0x5025 otherlinux 0x5035 otherlinux 異なる 同じ
0x5026 otherlinux-64 0x5036 otherlinux-64 異なる 同じ
0x5029 redhat 0x5029 redhat 同じ 同じ
0x5045 rhel10-64     追加 追加
0x5027 rhel2 0x5027 rhel2 同じ 同じ
0x5027 rhel3 0x5027 rhel3 同じ 同じ
0x5028 rhel3-64 0x5028 rhel3-64 同じ 同じ
0x5029 rhel4 0x5029 rhel4 同じ 同じ
0x502A rhel4-64 0x502A rhel4-64 同じ 同じ
0x5029 rhel5 0x5029 rhel5 同じ 同じ
0x502A rhel5-64 0x502A rhel5-64 同じ 同じ
0x5041 rhel6 0x503E rhel6 異なる 同じ
0x5042 rhel6-64 0x503F rhel6-64 異なる 同じ
0x5041 rhel7 0x503E rhel7 異なる 同じ
0x5042 rhel7-64 0x503F rhel7-64 異なる 同じ
0x5042 rhel8-64 0x503F rhel8-64 異なる 同じ
0x5043 rhel9-64 0x5040 rhel9-64 異なる 同じ
0x5030 rockyLinux-64 0x5030 rockyLinux-64 同じ 同じ
0x5027 sjds 0x5027 sjds 同じ 同じ
0x5029 sles 0x5029 sles 同じ 同じ
0x502A sles-64 0x502A sles-64 同じ 同じ
0x5029 sles10 0x5029 sles10 同じ 同じ
0x502A sles10-64 0x502A sles10-64 同じ 同じ
0x5029 sles11 0x5029 sles11 同じ 同じ
0x502A sles11-64 0x502A sles11-64 同じ 同じ
0x5029 sles12 0x5029 sles12 同じ 同じ
0x502A sles12-64 0x502A sles12-64 同じ 同じ
0x502C sles15-64 0x502C sles15-64 同じ 同じ
0x5030 sles16-64 0x5030 sles16-64 同じ 同じ
0x5059 solaris10 0x5051 solaris10 異なる 同じ
0x505A solaris10-64     追加 追加
0x505B solaris11-64 0x5053 solaris11-64 異なる 同じ
0x5056 solaris6 0x504E solaris6 異なる 同じ
0x5056 solaris7 0x504E solaris7 異なる 同じ
0x5057 solaris8 0x504F solaris8 異なる 同じ
0x5058 solaris9 0x5050 solaris9 異なる 同じ
0x5029 suse 0x5029 suse 同じ 同じ
0x502A suse-64 0x502A suse-64 同じ 同じ
0x5029 turbolinux 0x5029 turbolinux 同じ 同じ
0x502A turbolinux-64 0x502A turbolinux-64 同じ 同じ
0x503B ubuntu 0x5038 ubuntu 異なる 同じ
0x502A ubuntu-64 0x502A ubuntu-64 同じ 同じ
0x506F unixware7 0x5067 unixware7 異なる 同じ
0x5073 vmkernel 0x506B vmkernel 異なる 同じ
0x5074 vmkernel5 0x506C vmkernel5 異なる 同じ
0x5075 vmkernel6 0x506D vmkernel6 異なる 同じ
0x5076 vmkernel65 0x506E vmkernel65 異なる 同じ
0x5077 vmkernel7 0x506F vmkernel7 異なる 同じ
0x5079 vmkernel8 0x5071 vmkernel8 異なる 同じ
0x507B vmware-photon-64 0x5073 vmware-photon-64 異なる 同じ
0x5008 whistler 0x5008 whistler 同じ 同じ
0x5007 win2000 0x5007 win2000 同じ 同じ
0x5007 win2000AdvServ 0x5007 win2000AdvServ 同じ 同じ
0x5007 win2000Pro 0x5007 win2000Pro 同じ 同じ
0x5007 win2000Serv 0x5007 win2000Serv 同じ 同じ
0x5002 win31     追加 追加
0x5003 win95     追加 追加
0x5004 win98 0x5004 win98 同じ 同じ
0x5017 windows11-64 0x5017 windows11-64 同じ 同じ
0x5019 windows12-64 0x5019 windows12-64 同じ 同じ
0x501E windows2019srv-64 0x501E windows2019srv-64 同じ 同じ
0x501F windows2019srvNext-64 0x501F windows2019srvNext-64 同じ 同じ
0x5020 windows2022srvNext-64 0x5020 windows2022srvNext-64 同じ 同じ
0x5010 windows7 0x5010 windows7 同じ 同じ
0x5011 windows7-64 0x5011 windows7-64 同じ 同じ
0x501B windows7srv-64 0x501B windows7srv-64 同じ 同じ
0x5012 windows8 0x5012 windows8 同じ 同じ
0x5013 windows8-64 0x5013 windows8-64 同じ 同じ
0x501C windows8srv-64 0x501C windows8srv-64 同じ 同じ
0x5014 windows9 0x5014 windows9 同じ 同じ
0x5015 windows9-64 0x5015 windows9-64 同じ 同じ
0x501D windows9srv-64 0x501D windows9srv-64 同じ 同じ
0x5021 winHyperV 0x5021 winHyperV 同じ 同じ
0x5005 winMe 0x5005 winMe 同じ 同じ
0x500A winNetBusiness 0x500A winNetBusiness 同じ 同じ
0x500A winNetDatacenter 0x500A winNetDatacenter 同じ 同じ
0x500B winNetDatacenter-64 0x500B winNetDatacenter-64 同じ 同じ
0x500A winNetEnterprise 0x500A winNetEnterprise 同じ 同じ
0x500B winNetEnterprise-64 0x500B winNetEnterprise-64 同じ 同じ
0x500A winNetStandard 0x500A winNetStandard 同じ 同じ
0x500B winNetStandard-64 0x500B winNetStandard-64 同じ 同じ
0x500A winNetWeb 0x500A winNetWeb 同じ 同じ
0x5006 winNT 0x5006 winNT 同じ 同じ
0x500C winServer2008Cluster-32 0x500C winServer2008Cluster-32 同じ 同じ
0x500D winServer2008Cluster-64 0x500D winServer2008Cluster-64 同じ 同じ
0x500C winServer2008Datacenter-32 0x500C winServer2008Datacenter-32 同じ 同じ
0x500D winServer2008Datacenter-64 0x500D winServer2008Datacenter-64 同じ 同じ
0x500C winServer2008DatacenterCore-32 0x500C winServer2008DatacenterCore-32 同じ 同じ
0x500D winServer2008DatacenterCore-64 0x500D winServer2008DatacenterCore-64 同じ 同じ
0x500C winServer2008Enterprise-32 0x500C winServer2008Enterprise-32 同じ 同じ
0x500D winServer2008Enterprise-64 0x500D winServer2008Enterprise-64 同じ 同じ
0x500C winServer2008EnterpriseCore-32 0x500C winServer2008EnterpriseCore-32 同じ 同じ
0x500D winServer2008EnterpriseCore-64 0x500D winServer2008EnterpriseCore-64 同じ 同じ
0x500C winServer2008SmallBusiness-32 0x500C winServer2008SmallBusiness-32 同じ 同じ
0x500D winServer2008SmallBusiness-64 0x500D winServer2008SmallBusiness-64 同じ 同じ
0x500C winServer2008SmallBusinessPremium-32 0x500C winServer2008SmallBusinessPremium-32 同じ 同じ
0x500D winServer2008SmallBusinessPremium-64 0x500D winServer2008SmallBusinessPremium-64 同じ 同じ
0x500C winServer2008Standard-32 0x500C winServer2008Standard-32 同じ 同じ
0x500D winServer2008Standard-64 0x500D winServer2008Standard-64 同じ 同じ
0x500C winServer2008StandardCore-32 0x500C winServer2008StandardCore-32 同じ 同じ
0x500D winServer2008StandardCore-64 0x500D winServer2008StandardCore-64 同じ 同じ
0x500C winServer2008Web-32 0x500C winServer2008Web-32 同じ 同じ
0x500D winServer2008Web-64 0x500D winServer2008Web-64 同じ 同じ
0x500E winVista 0x500E winVista 同じ 同じ
0x500F winVista-64 0x500F winVista-64 同じ 同じ
0x5008 winXPHome 0x5008 winXPHome 同じ 同じ
0x5008 winXPPro 0x5008 winXPPro 同じ 同じ
0x5009 winXPPro-64 0x5009 winXPPro-64 同じ 同じ

この Guest OS ID は対象となるゲスト OS のプロダクトに対して値が割り当てられていますが、実は 1 対 1 になっているようでなっていません。これは現在のバージョンと次の機能追加されたバージョンのように一部変更があった場合に付与されて識別されるようになっていて、例えば 同じな名前でもベースのカーネルが変わったりした場合に識別できるようにしているようです。また逆に別の Guest OS ID が割り当てられているけれど同じとして扱われるものもあります。これから推測しても vmx ファイルに記述される guestOS パラメーターはしっかり意味があるけれど Guest OS IDは処理に利用するために便宜的に付与されているだけというのが見えてきます。そしてゲスト OS 固有の機能を使う仮想マシンを作る際にはメモリ上に読み込まれたこの Guest OS ID を参照し適切な値を設定して処理されるというのがわかってきます。なので Guest OS ID が付与されていないオペレーティングシステムや適切な Guest OS ID を設定していない仮想マシンでは VMware Workstation Player 17 で動かすことは可能ですが、使用しているゲスト OS に対して適切な動作を保証するものではないということになります。

vmx ファイルはどこで読み取られるの?

VMware Workstation Player 17 が起動される最初のプログラムは、フォルダー C:\Program Files (x86)\VMware\VMware Player にある vmplayer.exe です。このプログラムでは VMware Workstation Player 17 自体の起動と各種動作に必要なサブプログラムのコントロールなどを行っています。なので、この vmplayer.exe の中には vmx ファイルにある関する情報は扱いません。vmx ファイルにある情報を扱うのはあくまでもフォルダー C:\Program Files (x86)\VMware\VMware Player\x64 にある vmware-vmx.exe 他が行います。このフォルダー内には仮想マシンを起動する際に使用される ROM、仮想インターフェースの ROM などが含まれており、VMware Workstation Player 17 で仮想マシンを実行する際の重要なファイルが集められています。(Docker などはフォルダー C:\Program Files (x86)\VMware\VMware Player\bin に、kvm は C:\Program Files (x86)\VMware\VMware Player に含まれていたりしますが、これらはメインではなくて後々に追加されたものなのでバラバラなのか、それとも意図してそこに置いてあるのかはわかりません。)

なお、VMware Workstation Pro 17 の起動ファイルは vmware.exe です。それ以外のファイルの配置は VMware Workstation Pro 17 も VMware Workstation Player 17 も同じ場所にあります。

※これら2つはそれぞれ VMware KVM Mode、VMware Workstation Container という別の機能になりますので別においているのだと考えています。

なんで VMware Workstation Pro 17 の実行ファイルは vmware.exe なの?

これは VMware が創業した時に最初に製品化した VMware というプロダクトに付けたファイル名がそのまま残っているからです。手元にその最初のプロダクトもありますが、それもしっかり「vmware.exe」となっていました。なのでその後のデスクトップハイパーバイザーはその新しいバージョンという位置づけなので、そのままの名称を使い「vmware.exe」というファイル名になっているのだろうと思います。そしてそのサブセットとして機能の一部を削除して新たに作成された VMware Workstation Player は「vmplayer.exe」という新しい名前になっているわけです。会社の歴史が見える製品、それがデスクトップハイパーバイザーに残っているというのは面白いですね。
この辺りは以前の記事に書いてありますのでご興味あればご覧ください。

imaisato.hatenablog.jp

VMware Workstation Pro/Player と Fusion の今後は

VMwareBroadcom に買収されて、多くのプロダクトが今後どうなるか気になる状態になりましたが、VMware Workstation Pro/Player そして Fusion については 12月11日に以下の記事が出ました。

blogs.vmware.com

 内容を要約すると、「VMware by Broadcom は、現在から将来にわたってデスクトップ ハイパーバイザー製品とプラットフォームに重点を置き取り組みます。」とのことで、私たちユーザーは、今までと同様に引き続きデスクトップ ハイパーバイザー アプリを購入したり Workstation および Fusion の無償製品である Player を「個人使用無料」のエディションを引き続きダウンロードして使用することができるとありました。これらを常用している私を含めてみなさんはほっと一安心です。

次は年明け、何を書いていくかはこれから考えていきますが、VMware がどのように変化していくかは気になるので、これからもウォッチしていくことになりそうです。

flings が復活!!VMTN 内に新しくオープンしました

10月24日に閉鎖されてしまった flings ですが賦活しました!

新しい fling はどこにできたの?

今回復活した flings は、今までの flings.vmware.com にはありません。今回復活したのは VMware Communities (VMTN) 内のコンテンツとして公開されています。なのでリンクは https://communities.vmware.com/t5/Flings/ct-p/77 となっています。ただし今までの flings.vmware.com にアクセスしてもリダイレクトでここに行くように考慮されているので、新しい flings の URL を知らなくても flings にアクセスが出来るようになりました。

flings トップページ

新しい flings で公開っされているものは?

新しい flings ですが、今までの flings にあったものが全て揃っているということではありません。現時点では以下の 13種しか公開はされていないようです。また各ツール単独のページは存在せず flings のトップページからの Discussion、Documentation、Download のリンクでしかそれぞれに行けないのがとても不便です。

その他、例えば古いバージョンをダウンロードしたくてもそれらもリンクが無い場合はダウンロード出来なくなっています。

ESXi Arm Edition

USB Network Native Driver for ESXi

VMware Event Broker Appliance (VEBA)




HCIBench

VMSS2Core
VMSS2Core

vSphere Diagnostic Tool
vSphere Diagnostic Tool

Community NVMe Driver for ESXi
Community NVMe Driver for ESXi

Community Network Driver for ESXi

Cross vCenter Workload Migration Utility

Solution Designer
S

Virtual Machine Compute Optimizer
Virtual Machine Compute Optimizer

Storage Performance Tester

Unified Access Gateway Deployment Utility

ある意味それなりに需要のあるのだけとりあえず一つの場所からアクセスできるようにした感じのようです。ただ「More Coming Soon ...」ともありますので、今後変っていく可能性はあります。良い形になっていくことを期待したいところです。

More Coming Soon ...

flings に公開されていない他のツールは?

flings にあったツールで今回の flings にも含まれていないけれど個別にホストされていて入手可能なものは以下のものがあります。

今後 flings に加えられるかはわかりませんが、とりあえずは入手できるのは助かるところです。

Broadcom に買収されて消え去ってしまった VMware という会社の資産の一つである flings も、Broadcom の中で徐々に復活していってほしいですね。

VMware 製品のライセンスモデルが変わります

※追記

本記事にあるライセンスモデル変更については、以下の記事に現状を記載しています。

imaisato.hatenablog.jp

-----

Broadcom によって買収された VMware ですが、いよいよプロダクトのライセンスモデルが変わるようです。

ライセンスモデルの変更点は?

VMware として 2023年12月11日に以下のニュースが出ました。

news.vmware.com

何が書かれているのかというと、記事からの抜粋ですが、

  • 製品ポートフォリオの大幅な簡素化により、あらゆる規模のお客様が VMware ソリューションへの投資からより多くの価値を得ることができます。 VMware by Broadcom のすべての部門にわたるポートフォリオの簡素化は、当社のオファーと市場開拓が複雑すぎるという長年にわたる顧客とパートナーからのフィードバックに基づいています。
  • すべての VMware by Broadcom ソリューションのサブスクリプション ライセンスへの移行を完了し、永続ライセンスの販売、永続製品のサポートとサブスクリプション (SnS) の更新、およびハイブリッド購入プログラム/サブスクリプション購入プログラム (HPP/SPP) クレジットの本日開始の終了を伴います (発効日は異なります)。さらに、持ち込みサブスクリプション ライセンス オプションを導入し、VMware Cloud Foundation を実行している VMware 検証済みのハイブリッド クラウド エンドポイントへのライセンスのポータビリティを提供します。

つまり「今までの複雑怪奇な多くのライセンスモデルを一気に捨てて、サブスクリプションモデルにするよ。」そして「今までのパーペチュアルライセンスは更新はできないのでサブスクリプションライセンスを買ってね。」ということのようです。

ライセンスモデルの変更によるユーザーへの影響は?

このライセンスモデルの変更によって、今までのベースの考え方「ライセンスはお客様の所有なので、ずっと使い続けられる」でも「サポートを購入しないと VMware からのサポートが受けられないよ」という形での利用は出来なくなります。そしてサブスクリプション期間=製品利用可能期間になるため、プロダクトのライセンス認証の部分がどのように変わってきているのか次第だと思うのですが、vSphere 自体もだいぶ前からサブスクリプション対応は済んでいるのでライセンスをパーペチュアルからサブスクリプションに変えていくだけで対応できるのではないかなと思います。

なので今までもライセンスとサポートをセットで購入後にサポートを常に更新しているようなユーザーは問題ないと思いますが、システム導入や更新時にはライセンスとサポートを買うけれど、トラブルが殆ど起きないし塩漬けなので次年度以降はサポートは買わなかったようなユーザーや、新しく入れる環境のサポートで入手したアップグレードまたはアップデート、パッチなどを、サポート切れしている環境にも内緒で適用したりしているようなユーザーにはコスト増実際には本来必要なコストに変るという影響は出てくるかと思います。

既存のパーペチュアルライセンスの扱いは?

これからのライセンス購入がサブスクリプション型に変わるだけなので、今まで購入しているパーペチュアルライセンスはこれからもずっと使用し続けることが出来ます。ただし、この記事の発表日の 2023年12月11日以降はパーペチュアルライセンスとそれのサポートの販売およびSnS更新も終了しているので、今利用しているサポートの期間終了までしか実質は使えないと考えるのが妥当です。

既存のパーペチュアルライセンスの追加購入は?

パーペチュアルライセンスの提供終了日がある場合、それまでの間は追加購入が出来ますが、その期間を超えた場合は新規購入は出来なくなります。追加はサブスクリプションを購入するか Term ライセンス(期間ライセンス)を購入する方法しかありません。 

既存環境の SnS 更新がしたいけれど?

パーペチュアルライセンスの SnS 更新は終了してしまっているので、現在のパーペチュアルライセンスの製品を VMware に下取りしてもらいサブスクリプションライセンスに買い直すことが必要です。

ここで面白いのは、下取りとサブスクリプションへの買い直しの際に、パーペチュアルライセンスを全て Broadcom 側に提示する必要は無くて、単にアップグレード価格のインセンティブが適用されるライセンス数はいくつ?みたいな感じでの買い替えになるようで、SnS更新が近い場合は所有しているパーペチュアルライセンス数を棚卸しておいてくださいと記事の中でも書いてあります。

サブスクリプションに変るプロダクトは?

以下のプロダクトがサブスクリプションモデルに変ります。

vSphere を使う製品は網羅されているようですが、ここにリストされていない EUC や Carbon Black 他のプロダクトが今後サブスクリプションモデルに今後変っていくのか、それとも噂されているように切り離されていくのかなど、そのあたりの今後の動向が気になるところです。

VMware という会社が明日無くなることが決定しました

Broadcom による VMware の買収完了へ

先程中国の国家市場規制総局のからの発表で、条件付きで Broadcom による VMware の買収を承認するとの発表がありました。

www.samr.gov.cn

これがインターネットで流れている最初の情報でしたが、それからどんどんいろいろなと頃から記事が出るようになります。次はここ

www.streetinsider.com

その次がここで、

seekingalpha.com

その次がここ、
www.businesswire.com

どんどん記事が出てきます。

www.ft.com

www.bloomberg.com

ここでいよいよ本家の Broadcom の発表がありました。

investors.broadcom.com

この本家の情報を見ると、買収完了は US時間の 11月22日に決定したようです。長かったトンネルもいよいよこれで終わりを迎え、会社としての VMware から Broadcom のソフトウエア部門としての VMware がスタートです。1998年 2月 10日に創業し 25年という歴史を刻んだ VMware の終止符がいよいよやってきました。

追記

VMware からもようやく発表が。

news.vmware.com

 

VMware vSphere ベースのクラウドって、どんなのがあるの?

数年前からクラウド関係の仕事をしていて、今のクラウドコンピューティングは大きく分けて Linux KVM ベースのものと VMware vSphere ベースの 2つに分けられているといっても良さそうだねと思ったのと、その中の VMware vSphere のクラウドサービスプロバイダーはどんなサービスを提供しているのかをちょっと調べてみました。 

VMware Cloud

VMware vSphere ベースのクラウドベンダーはどういうのがあるの?

VMware vSphere ベースのクラウドは自社データセンターの中に展開した vSphere のリソースを切り出し利用者に提供(貸し出す)方式、利用者専有の物理サーバーを用意してそれを利用者に貸し出す方式とあります。そして後者の場合は利用者占有のサーバー自体の管理も一部制限はありますが利用者に開放している方式と、利用者占有のサーバーはクラウドサービスベンダーが管理して、ハイパーバイザー上の環境のあるレベルから利用者に貸し出す方式(マネージドサービスですね)とに分かれています。

vSphere のリソースを切り出し利用者に提供(貸し出す)方式をとっているクラウドサービスベンダーはどこ?

以前は多くのベンダーがこの方式を採用し利用者に提供していましたが、現在はだいぶ少なくなってきています。今この方式をとっている代表的クラウドサービスベンダーは以下の通りです。

などがあります。

これらの特長としては、オンプレミスのようにハードウエアやファシリティーを所有することなく、またクラウドに移行してもクラウドベンダー側で用意する決められた仕様の物理ハードウエアによる無駄などの心配することなく、必要なリソースを必要な時に必要な分だけ利用できる、パブリッククラウドのような柔軟な利用形態になっているところです。これは将来的にクラウドに移りたいけれど vSphere ベースが慣れているのでそのままであれば助かるというような用途に向いています。ただし他の利用者のリソースと共有する環境上で区分けされた自分のリソースを使うわけで、その環境を使う際の仕様に合わせてオンプレミスで動かしてきた仮想マシンの設定などを変える必要も出てきます。この辺りはオンプレミスではなく、そしてリソースを占有しているわけではないので仕方がないところです。

利用者専有の vSphere が動く物理サーバーを用意し貸し出す方式をとっているクラウドサービスベンダーはどこ?

これはメガクラウドと呼ばれる外資クラウドサービスベンダーが提供をしています。上記のvSphere のリソースを切り出し利用者に提供(貸し出す)方式を提供しているクラウドベンダーでも提供している場合があります。

外資クラウドベンダーで提供をしているのは、提供開始の順番で、

などがあります。これらの外資クラウドベンダーは VMware と密に連携しながらサービスを提供しているので、VMware のサイトにもサービスが掲載されています。

同じようなサービスは日本のクラウドサービスベンダーでも提供はしているのですが、vSphere のリソースを切り出し利用者に提供(貸し出す)方式と同じ名称でオプションのような位置づけになっているのが多いようです。例えば

などです。

なお、この専有にはもう一つの形があり、利用者のデータセンターに物理サーバーを配置してしまうサービスというものもあります。これは

意外にVMware vSphere ベースのクラウドは色々なサービスが提供されているというのがわかるかと思います。

今回はあくまでも VMware vSphere ベースのクラウドの「さわり」を書きましたが、次回以降はもう少し深く書いていこうと思います。

 

vExpert 2024の応募が始まっています

Apply to be a vExpert 2023

 

いよいよ今日から 2023年は世界では 1518人、日本では 55人しかいない vExpert の 2024 年度の応募受付が始まりました。締め切りは 2024年1月19日です。

 

 vexpert.vmware.com 

vExpert とは

vExpert のサイトの中、「Program Overview」に書かれている通り、

VMware vExpertプログラムは、VMwareのグローバルなエバンジェリズムおよびアドボカシープログラムです。このプログラムは、VMwareマーケティング リソースをお客様のアドボカシー活動に活用することを目的としています。記事のプロモーション、VMware のグローバル イベントでの露出、共同広告、トラフィック分析、ベータ プログラムや VMware のロードマップへの早期アクセスなどがあります。この賞は、企業ではなく個人を対象としており、期間は1年間です。お客様とパートナー企業の両方の従業員が受賞できます。応募にあたっては、前年度のさまざまなコミュニティ活動に加え、今年度(下半期の応募に限る)の活動も考慮して受賞者を決定します。私たちは、あなたが活動していただけでなく、あなたが選んだ道で今も活動していることを見ています。 

のように、VMware に個人としてどのような貢献活動をしたかによって、vExpert 対象かどうかを判断され、vExpert として適切と評価された人に対しアワードが送られて、翌年 1年間の vExpert としての活動ができるようになります。

vExpert に必要な要件(基準)

サイトの中の「Criteria」に、vExpert に応募できる基準が以下のように書かれています。

vExpertになることに興味があるなら、基準はシンプルです。VMwareの知識を共有し、それをコミュニティに還元してくれるITプロフェッショナルを求めています。
「還元」という言葉は、本業を超えて貢献することと定義されています。自分の知識を共有し、コミュニティに参加する方法はいくつかあります。例えば、ブログ、本の執筆、雑誌への寄稿、Facebookグループでの活動、フォーラム(VMTNやその他のVMware以外のプラットフォーム)、スピーチ、VMUGのリーダーシップ、ビデオなどが挙げられます。VMware Social Media Advocacyは、オリジナルコンテンツではないため、賞の対象にはなりません。

ここで特に重要なのは「本業を超えて貢献することと定義されています」という部分で、仕事で VMware 製品を使っていて、仕事で会社のブログに書いたり本を出したり、外部講演に登壇をしたりだけでは vExperet にはなれません。「VMwareの知識を共有し、それをコミュニティに還元してくれるITプロフェッショナル」であることが必要になり、その行動を応募時に証明しなければなりません。私の場合は会社の仕事は Google Cloud Platform と Microsoft Azure をメインにクラウド関連の業務を行っているので VMware 製品は個人の範疇と社内で時々支援程度になっているので、VMware の知識を還元するためにはそれなりに個人の時間を割いて学習したり検証したりする必要がありました。でも、そういう活動が vExpert になるためには必要だということになります。

vExpert への応募

時期になるとサイトの中の左上、Welcome の下に申請できるリンクが現れます。

vExpert 2023 応募

このバナーをクリックし、次の画面でログインまたは新規応募ならアカウントを作成し、応募ページに移動します。既に vExpert サイトにログインしている場合は、この画面は出ずにプロフィールの確認ページに移ります。

f:id:imaisato:20211208080527p:plain

ログイン/アカウント作成画面

ここからが入力画面になります。より多くのことを記載できるようになりましたので、自己アピールをしっかり書いてください。どのように入力するかは画面右上に「SHOW EXAMPLE APPLICATION」ボタンがありますので、それをクリックして参照しながら書いていきます。

SHOW EXAMPLE APPLICATION

もちろん記入はすべて英語で書くことになります。どのような内容を書くのかというと、vExpert に応募できる「資格」、つまり基準を満たしている証跡を入力していきます。いくつか書く場所があるのでそれぞれに該当する部分だけ記入して行きます。該当しない部分は空白で構いません。

Application Form

最初は「1. Content Creation」、なにかコンテンツを作っている場合はここに記入します。ブログを書いている人はブログの URL を、本を執筆している人はその本がわかることを書きます。YouTube などで動画配信している場合も同様です。ここは昨年までは最大 3つまでしか書けない制限がありましたが、今年はテキストでのフリー入力になっていますので枠を拡大して十分書くことができます。

次に「2. Events and Speaking」、これは個人活動としてイベントのスピーカーとして登壇したりイベントの手伝いをしをした場合にはその役割などを書いていきます。自分が勤務する会社の自社イベントや社内イベントでの登壇は仕事なので評価対象になりません。また、VMware 主催のイベントでお金を出して登壇する場合も評価対象にはなりません。あくまでも個人の活動というのが重要です。ここもテキストでフリー入力になっていますので、活動内容をしっかりアピールしながら記載していきます。

次の「3. Online communities, tools, and resources」、ここはどのオンラインコミュニティに参加して活動したかを記載します。どんな活動をしたかがわかるもの、例えばステータス レベル、ポイント、またはバッジなどがあればそれを記載します。コミュニティーに対するツールを作ったりしていた場合は、そのオンラインツール、リソース、ディレクトリ、またはリポジトリをリストアップし、自分の役割も記入します。

その次の「4. VMware Programs」はVMUG のリーダーシップ、アドバイザリー・ボード、リファレンス・プログラム、カスタマー評議会、VMware Partner Network などの VMware のプログラムで自分が担務した役割を記入する場所で、ほとんどの人は該当しないと思います。

その次の「What other activities in the last year should we take into account?」はアピールの場所です。どのようなことをしてきたのかを追加で記入します。※がついているので必須項目です。

最後の「Reference」は、この活動をするうえで支援してもらった VMware 社員がいれば、そのメールアドレスを記入します。その下の「vExpert Pro」はほとんどの人が関係ないので何もしなくて大丈夫です。

記入ができたらあとは確認をして、SAVEするだけです。これで締め切り後に審査が行われ、2024 年度の vExpert が決まります。今年の締め切りは 2024年1月19日の太平洋時 9時です。遅れないように申請しましょう。
SAVE が問題なく終了すると Application sent! が表示されます。これで申請は終了です。vExpert への申請は、期間内であれば何度も修正することができます。なので、追記したいことや修正したことがあれば、期間内に何度も直していきましょう。精査することで vExpert に認定される可能性は上がっていくと思います。申請した内容の修正や追記したい場合には、再度 APPLICATIONS ARE OPEN から入りなおして内容を直します。

Application sent!



vExpertの証明

vExpert になると以下のような証明書とバッジを受け取れます。証明書はプロファイルで入力する表示名が入ります。下の年号の下の部分ですね。

vExpert 2023 証明書

vExpert のバッジは

 

vExpert 2023

のようなもので、定められた条件のもとに使うことができます。複数年継続して取得している人向けに、年度ではなくてその部分に vExpert を取得した数が★で表示されているバッジもあり、両方を使い分けできます。

vExpert になるメリットは

vExpert になるメリットは「vExpert Program Benefits」に以下のように書かれています。

  1. 2,500 人以上の vExpert とのネットワークを構築できる。
  2. 8 つの VMware 公式ビジネスユニット主導の vExpert サブプログラムに応募できる
  3. プライベート vExpert #Slack チャンネルに招待され参加ができる
  4. VMware CEOが署名した vExpert 証明書がもらえる
  5. vExpertのロゴをカードやウェブサイトなどで1年間使用できる
  6. 様々なVMwareパートナーからの限定ギフトを入手できる機会がある
  7. NFRだけでなく、VMwareパートナーとのプライベートウェビナーへの参加
  8. プライベートベータへのアクセス(ベータチームへの登録が必要)
  9. ホームラボやクラウドプロバイダー向けに、ほとんどの製品の365日間の評価版ライセンスを提供
  10. VMworld の前に行われるブロガー ブリーフィングを通じたプライベート プレローンチ ブリーフィング(製品チームの許可が必要)
  11. 公開されたvExpertオンライン・ディレクトリに名前が掲載される
  12. お客様のソーシャル・チャネル向けに用意されたVMwareおよび仮想化コンテンツへのアクセス
  13. VMworld US および VMworld Europe の両イベントでの毎年の vExpert パーティ
    VMworld US と VMworld EU の両方で vExpert として認められる

このようにいろいろあるのですが、やはり個人として VMware 製品の啓もう活動に必要になるのは個人で使えるライセンスがあること。なので、上のメリットの中の 9. が一番のメリットになるかなと思います。

vExpert の分布は?

日本にいる vExpert はどういう組織に分布しているかが気になるかと思いますので、vExpert 2023 55名の所属を調べてみました。ソースは vExpert サイトにある Directory で、だれでもアクセスして情報を見ることが出来ます。

所属組織 人数
SB C&S Corp. 6
VMware 5
Dell Technologies 5
TechVan Co., Ltd. 4
Amazon Web Services 3
Other 3
Networld Corporation 2
Net One Systems Co.,Ltd. 2
NEC 2
JGC CORPORATION 2
Google Cloud 2
FUJITSU CLOUD TECHNOLOGIES LIMITED 2
Central Tanshi FX Co.,Ltd. 2
TIS Inc. 1
Seijo University 1
Red Hat Japan 1
PagerDuty Japan 1
PASCO CORPORATION 1
NTT DATA Corporation 1
Microsoft Japan 1
Meiji Yasuda System Technology Company Limited 1
Mannari hospital 1
IBM Japan, Ltd. 1
Fuji Electric IT Center Co.,Ltd 1
FUJI SOFT INCORPORATED 1
DMM.com LLC 1
Classmethod, Inc. 1
BIGLOBE Inc. 1
合計 55

昨年度は富士ソフト株式会社がダントツだったのですが、今年は昨年 2位だった SB C&S がダントツでした。そして今日時点ではまだ独立した会社の VMwareVMware の親会社の Dell Technologies, TexhVan と続いています。富士ソフトは人が居なくなってしまったのかトップから一気に 16位に陥落。一昨年誰もいなくなった富士通を思い起こさせます。Other は私もそこに入っていますが所属非公開の人です。

vExpert の話をもっと聞きたいなら=>VMUGへ

vExpert になっている人の多くは VMUG (VMware User Group) に参加している人が多いので、もし vExpert についてもう少し情報が欲しいという場合、まず VMUG に参加しその中にあるコミュニティで聞いてみるのもよいかもしれません。

VMUG 会員には 2つのタイプがあり、一般会員は無料で誰でもなれます。そのため、まずは vExpert の方とコミュニケーションしたいということであれば VMUG の一般会員に入り、Japan VMUG コミュニティに入ることからスタートするのが良いかもしれません。

なお残念ながら vExpert の Criteria に満たない場合は、次年度に向けていろいろ活動をしておくようにしてください。アピールできる活動が増えれば増えるほど、vExpert 受賞が近づいてきます。

 

※一覧表の名寄せを訂正しました。