Quantcast
Channel: VMware Communities : All Content - All Communities
Viewing all 178545 articles
Browse latest View live

vCenterに定義されているEventの一覧とEventIDを取得する方法

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

※本記事は前回の続きです。前回の記事はコチラ↓↓↓

vSphereのアラーム定義で一覧にないEventのアラームを定義する方法

 

 

 

さて、前回の記事ではより自由なアラーム定義の方法をご紹介しましたが、そのためにはEventIDが必要だということがわかりました。

厳密にはEventIDでなくともEventDescriptionを設定すればいいのですが、日本語の場合はスペースや句読点など正しく入力するには多少のハードルがありますので好ましくありません。

前回のEventを例にするとEventDescriptionは以下の二つになりますが、それぞれ微妙に半角スペースが用いられており、正しく入力できない懸念があります。

 

"RAM ディスクがいっぱいです。"

"RAM ディスクのファイル テーブルがいっぱいです。"

 

 

したがって、EventIDがわかるのであればEventIDで入力したいところです。

ではどうやってEventIDを調べるのか、というのが本記事の趣旨になります。

 

 

実はEvent自体はvCenter内に定義ファイルと思しきものがあるのでそれを見ればいいのです。

VMwareの公式情報があるわけではないですが、検証機で試したところ以下の場所に定義ファイルと思しきものを見つけることができました。

 

/etc/vmware-vpx/extensions/hostdiag/extension.xml

 

 

ちなみに確認で用いたvCenterのVersionは以下です。

BRANCH:vsphere65ep7

BUILDNUMBER:8815520

CLOUDVM_VERSION:6.5.0.21000

 

このファイルをみるとEventIDやそのDescriptionがまとめられているのがわかります。

ここから目的とするEventを探し出せばよい、ということになります。

このファイルのDescriptionは英語で書かれていますので、対象のEventの英語表記を探して対象のEventIDを取得すればよいのです。

 

「いや、オレは日本語のメッセージから探したいんだ!」

 

という強い意志をお持ち方は、同じくvCenter内にあるEventの日本語訳が定義されている(と思しき)ファイルを見てください。

検証環境のVCSAでは以下のファイルが該当しているようです。

 

/etc/vmware-vpx/extensions/hostdiag/locale/ja/event.vmsg

 

たとえば、今回の例でいうと以下のように書かれていました。

 

esx.problem.visorfs.ramdisk.full.description     = "RAM ディスクがいっぱいです。"

esx.problem.visorfs.ramdisk.full.formatOnVm      = ""

esx.problem.visorfs.ramdisk.full.formatOnHost    = ""

esx.problem.visorfs.ramdisk.full.formatOnComputeResource = ""

esx.problem.visorfs.ramdisk.full.formatOnDatacenter = ""

esx.problem.visorfs.ramdisk.full.fullFormat      = "RAM ディスク「{1}」がいっぱいです。  そのため、ファイル {2} を書き込むことができませんでした。"

 

したがって、対象のEventIDとして、esx.problem.visorfs.ramdisk.full が抽出できます。

同ファイルにはおそらくvCenterの定義Eventのすべてが記載されていると思われますので、そもそもEventDescriptionにすらアタリがついていない場合は、この中から適当なものを探し出すこともできます。

 

 

 

いかがでしたでしょうか?

2回に分けて紹介したアラーム定義の設定によって、いままで通知できなかったEventも通知できるようになりました。

本記事の内容が、VxRailに限らず、VMware環境の運用監視負荷軽減に寄与すれば幸いです。


vSphereのアラーム定義で一覧にないEventのアラームを定義する方法

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

ある特定のEventを検知したいのにアラーム定義の一覧にそのEventがない!

といった経験はないでしょうか?

 

具体的には以下で参照できる一覧のことです。

 

1.PNG

 

 

vCenterにはデフォルトでアラームが定義されていて、多くの場合はそれで問題ない(通知設定は必要)場合が多いと思いますが、

デフォルトにないEventをアラームで検知したい場合などは自分でアラーム定義を追加することが可能です。

その際に検知したいEventを上記リストから選ぶ必要があります。

しかしながら検知したいEventがリストになくて断念、、、といったパターンもあるのではないでしょうか?

 

 

 

 

 

例えばですが、VxRailの過去のVersionでは、/tmpや/varといったESXiのRAMDISK容量が枯渇する不具合がありました(※修正済み)。

シナリオとして、Fixが出る前の段階では暫定対策としてこのEventをすぐに検知して対処したいと考えるのは自然なことです。

この場合、対象となるEventとして、

 

"RAM ディスクがいっぱいです。"

"RAM ディスクのファイル テーブルがいっぱいです。"

 

といったEventがvCenterには存在しますので、これらのEventについてアラームを定義できれば目的は達成されます。

 

しかしながらvSphere web clientから新しいアラーム定義としてこのEvent通知を定義しようにも、上記のEventがリストにないので設定することができません。

このような場合はどうすればよいでしょうか?

 

 

 

 

 

 

実は上記の例のようにすでに設定したいvCenterのEventが明らかになっている場合は対象のEvent IDを直打ちすることで設定が可能になります。

 

何を言っているの?と思われるかもしれませんが、実はアラーム定義の対象Eventはリストから選ぶ必要はないのです。

具体的には以下のようにします。

 

2.PNG

 

お判りでしょうか?本来リストから選ぶべき項目は、実は入力可能になっており、好きなEventを直に設定できます。

上記の例では、

 

esx.problem.visorfs.ramdisk.full  =====> "RAM ディスクがいっぱいです。"

esx.problem.visorfs.ramdisk.inodetable.full =====> "RAM ディスクのファイル テーブルがいっぱいです。"

 

にそれぞれ対応しています。

このように直にEventIDを設定することでリストにないEventのアラーム定義を作成することが可能なのです。

 

ちなみに、一度設定すれば下図のようにEvent IDを自動的にHuman Friendlyな表現に自動的に書き換えてくれるのでわかりやすさも損なわれません。

 

(編集画面)

3.PNG

 

(確認画面)

4.PNG

 

 

いかがでしょうか?これでRAMDISKの枯渇を検知する、といった目的は達成できました。

 

 

 

 

と、、、、ここまで読んでいただいた方の脳裏には一つ(もしくは二つ)の疑問が浮かんでいるかと思います。

 

設定するEvent IDはどうやって調べんねん!?

※筆者は生粋の江戸っ子です

 

 

当然の疑問ですね。続きは次回にします。

 

 

次回記事↓↓↓

 

vCenterに定義されているEventの一覧とEventIDを取得する方法

vSwitchにSTPが不要な理由

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

 

** 知っている人にとっては当たり前の内容です**

 

 

ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。

ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ(vSwitch)につながっています。

vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。

 

1.PNG

図1:ネットワークトポロジ

 

 

vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。

L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol(STP)を設定する必要(最近では必ずしもそうとは言い切れないようですが。。。)があります。

 

ではvSwitchの場合でもSpanning Treeに参加する(ネットワークは専門外なので表現が間違っていたらすみません。。。)必要があるのでしょうか?

表題からもわかるように答えはNoです。

L2ネットワークでBPDUと呼ばれるパケットをやり取りすることでSpanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。

 

ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか?Loopによる問題は発生しないのでしょうか?

 

実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。

その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。

 

たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。

 

下図ではUplink1からBroadcast Packetを受信した際の動作を示しています。

Broadcast Packetは仮想スイッチに接続されるVMに対して転送されますが、uplink2へは転送されません。

 

2.PNG

図2:外部からのBroadcast PacketはほかのUplinkへ転送されない

 

 

またUnknown Unicast(フレームの宛先MACアドレスがMACアドレステーブルにない場合)を外部からUplink経由で受け取った場合、普通の物理L2SWであればFloodingして宛先を探すことになりますが、vSwitchの場合は宛先MACアドレスに一致するVMがいない場合はそのパケットをドロップし、他のUplinkからFloodingすることはありません。

 

このような動作をするはvSwitchがあくまで仮想マシンのための通信であって、その他のNodeとの通信を転送する必要がないためだと思われます。

その結果、STPによりBlockされるポートがないため、帯域を損なうことがありません。

 

言うまでもないことかもしれませんが、ESXi上で稼働するVM起因のBroadcastやUnknown UnicastはちゃんとUplinkへ転送されますのでVMの動作に問題が出ることはありません。

 

3.PNG

図3:仮想マシン(内部)からのBroadcastやUnknown UnicastはUplinkへ転送される

 

 

より詳しく知りたい方は以下の資料が参考になります。

 

参考資料:

Networking for VMware Administrators (書籍)

Best Practices for Virtual Networking(PDF)

 

 

 

Unable to delete datastore

$
0
0

Hi,

 

I am trying to delete the datastore and while deleting it's giving error message has Datastore still in use.

 

We have unmounted from the all the Host and no vm's are running in the datastore.

Disconnect from PCOIP desktop Zero Clients (teradici)

$
0
0

We have a network with about 25 PCOIP devices, these are a mix of Samsung NC240's and eVGA PD06.

 

Randomly, about twice a week all logged in VM's disconnect without warning and won't reconnect for about 20 mins on the Teradici devices. BUT, the VM's are still live and in session if I use a Horizon View client from a windows desktop, I can connect to any of the dropped connections and the session is still in progress, ie. I pickup where the user was dropped.

 

The View Administrator setting for Forcibly Disconnect is set to Never.

 

I initially suspected bad network switches (since the sessions were live but the desktop hardware had disconnected) but I have eliminated that as a possibility since I can still ping printers but not any of the PCOIP desktops.

 

Had anyone experienced anything similar? Or have any idea on trouble shooting and/or resolution would be appreciated.

Error when using Invoke-VMScript

$
0
0

We are trying to use Invoke-VMScript to configure a VM without network connectivity. 

When using Invoke-VMScript cmdlet we get the error "Could not locate "Powershell" script interpreter in any of the expected locations. Probably you do not have enough permissions to execute command within guest." 

We are using the local administrator account on the vm. We’ve tested running the same script on the VM, and it works.

Whats wrong in the script

$
0
0

PowerCLI C:\> Get-VM -Name (Get-Content vmnames.txt) |Select-Object Name,@{N="HardDiskSizeGB"; E={(Get-HardDisk -VM $_ | Measure-Object -Sum CapacityGB).Sum}}

Get-VM : Cannot validate argument on parameter 'Name'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.

At line:1 char:14

+ Get-VM -Name (Get-Content vmnames.txt) |Select-Object Name,@{N="HardD ...

+              ~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidData: (:) [Get-VM], ParameterBindingValidationException

    + FullyQualifiedErrorId : ParameterArgumentValidationError,VMware.VimAutomation.ViCore.Cmdlets.Commands.GetVM

vmotion (change compute, storage and network) script issues

$
0
0

Hello,

 

The purpose of this script is to vMotion all of the VMs in the input CSV ($MigrationCSVPath) to a new cluster, new datastore or datastore cluster, and also change from a virtual switch PG to a distributed switch port group with the same name.

 

I'm having an issue with this script where it doesn't seem to work for every VM. The script will work for some VM's but not for others and I'm not sure why. The input file for the list of VM's to be migrated looks like this:

 

#TYPE Selected.VMware.VimAutomation.ViCore.Impl.V1.Inventory.VirtualMachineImpl

"Name","Id","Folder"

"servername","VirtualMachine-vm-36942","Folder3"

 

The error that I receive is:

Move-VM Object reference not set to an instance of an object.

At C:\MigrateScript.ps1:61 char:5

Move-VM -VM (Get-VM -Id $VM.Id) -destination $DestinationCluster  ..

+ CategoryInfo: NotSpecified: (:) [Move-VM], VimException

+ FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.ViCore.Cmdlets.Commands.MoveVM

 

I suspect it has something to do with the network adapters but haven't been able to determine a solution yet.

 

Param (

    [parameter(Position=0, Mandatory=$true, ValueFromPipelineByPropertyName=$true, HelpMessage='Type vCenter server IP or FQDN you want to connect')]

    [alias('vc')]

    [String]$vCenter,

    [parameter(Position=1, Mandatory=$true, ValueFromPipelineByPropertyName=$true, ValueFromPipeline=$true, HelpMessage='Type Destination Cluster')]

    [alias('c')]

    [String]$DestinationCluster,

    [parameter(Position=2, Mandatory=$true, ValueFromPipelineByPropertyName=$true, HelpMessage='Type name of DS_DSC')]

    [alias('ds')]

    [String]$DestinationDS_DSC,

    [parameter(Position=3, Mandatory=$true, ValueFromPipelineByPropertyName=$true, HelpMessage='Type maximum number of parallel vmotions to allow')]

    [alias('mpv')]

    [String]$MaxParallelvMotion,

    [parameter(Position=4, Mandatory=$true, ValueFromPipelineByPropertyName=$true, HelpMessage='Path to CSV Containing VM Names to Migrate')]

    [alias('mcv')]

    [String]$MigrationCSVPath,

    [parameter(Position=5, Mandatory=$true, ValueFromPipelineByPropertyName=$true, HelpMessage='Type target  virtual switch  name')]

    [alias('dvs')]

    [String]$TargetSwitch

)

Process {

    if ($global:DefaultVIServers.Name -notcontains $vCenter) {

        try {

            Connect-VIServer $vCenter -ErrorAction Stop

        }

        catch {

            Write-Host $($Error[0].Exception) -ForegroundColor Red

            break

        }

    }

    try {

        $ClusterInfo = Get-Cluster $DestinationCluster -ErrorAction Stop

       

        if(Get-Datastore $DestinationDS_DSC){

        $Datastore = Get-Datastore $DestinationDS_DSC

        }

        else{

        $Datastore = Get-DatastoreCluster $DestinationDS_DSC

        }

    }

    catch {

        Write-Host $($Error[0].Exception) -ForegroundColor Red

        break

    }

 

    #CSV requires one column with label "Name".

    $VMsToRelocate = Import-Csv -path $MigrationCSVPath

   

 

    foreach ($VM in $VMsToRelocate)

    {

 

        $networkadapters = Get-NetworkAdapter -VM $VM.Name

        $destinationPortGroup = Get-VDPortgroup  -VDSwitch $TargetSwitch -Name $networkadapters.NetworkName

        $networkadapters | Format-Table -AutoSize

        $destinationPortGroup | Format-Table -AutoSize

 

    Write-Host "Relocating VM:" $VM.Name "to" $DestinationDS_DSC

    Move-VM -VM (Get-VM -Id $VM.Id) -destination $DestinationCluster -NetworkAdapter $networkadapters -PortGroup $destinationPortGroup -datastore $Datastore  -RunAsync

   

    do

 

    {

 

        sleep 5

 

    } while((Get-Task -Status Running | where{$_.Name -eq 'RelocateVM_Task'}).Count -gt $MaxParallelvMotion)

    } #end of foreach


VMware Workstation 15.1 mouse issue with RDP and Windows 10 1903 host

$
0
0

I have a computer that I RDP into that runs the latest version of VMware Workstation (15.1). I just upgraded it from Windows 10 1809 to Windows 10 1903.

There is a defect where anytime the mouse changes inside a VM (like from a pointer to a hand) the mouse jumps slightly, making it very annoying to actually do anything in the VM with a mouse. The guest OS can be anything, Windows OR Linux. I'm also running the latest VMware tools in the guest.

This problem only occurs if the host is running Windows 10 1903 AND you are RDPing into that host. This is guest agnostic.

When I reverted the host back to 1809 the problem went away. The mouse jumping problem seems to be associated with a Windows 10 1903 host running VMware Workstation.

I'm not sure where to report this bug. I tried to buy a support contract for VMware Workstation but you can't buy one if you only hold one license.

Is there a place where I can report this bug? Does anyone have a workaround for it?

Optimization Status is Unknown in vRealize Operations Manager.

$
0
0

I have a vRealize Operations manager server.

And add a vCenter.

 

When I select Home > Workload Optimization on the server websit.

The Optimization Status is Unknown.

Why? what should I do?

1.PNG

Memory and Processor Requirement of vSAN

$
0
0

Hi Friends,

 

What is exact Memory and Processor Requirement of vSAN 6.x ?

 

How much each Host's memory and cpu requirement as an eligibility criteria ?

vMotionできない、、、そんな時。 (その①)

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

仮想化のメリット

 

VMwareの仮想基盤を導入する最も大きなメリットは何でしょうか?

 

私はvMotionだと思います。

 

ハードウェアを抽象化することでソフトウェアとハードウェアを切り離し、仮想マシンの可搬性が実現されました。

物理サーバのメンテナンス時やリソース不足の際に仮想マシンをオンラインで移行することで、ダウンタイムなしでリソース増設や物理交換が可能になります。

 

 

vMotionができない?!

 

しかしながら、日々の運用の中でvMotionができないシチュエーションが存在します。

それはESXiがvCenterから管理不可状態になってしまった場合です。

vMotionはESXi単体の操作ではなく、複数のESXiにまたがる操作となるため、仲介者としてvCenterが必要なります。

したがって、vCenterから管理できなくなったESXi上の仮想マシンはvMotionができなくなってしまいます。

 

このような管理不可状態は、多くの場合ESXiの管理サービス(hostd)の動作不良によって引き起こされます。vSphere Web Clientから確認すると管理不可状態のESXiは”応答なし”もしくは”Not Responding”と表示されます。

応答なしのESXiで稼働する仮想マシンは切断状態(もしくはdisconnected)となりますが、あくまでvCenter目線でのステータスであり、仮想マシンの稼働状態とは関係ないのでご安心ください。

 

1.PNG

 

※hostdの不具合によるNot Respoding事象自体は、あくまでESXiの管理機能の縮退に相当するだけの事象ですので、対象ESXi上で稼働する仮想マシンの稼働には影響がなく、仮想マシンは問題なく稼働を続けられます。

また、vSANクラスタであった場合でもvSANデータオブジェクトへの可用性には影響がありません。

 

hostdサービスの再起動などで事象が改善すれば問題ないのですが、事象によってはどうしてもESXiの再起動が必要となる場合があります。

ESXiを再起動するためには稼働する仮想マシンを退避する必要がありますが、vMotionができないのでそれもできません。

このような場合はどうしたらよいのでしょうか?

 

 

とりあえず対応保留!?

 

結論から言って、vMotionできない状況でESXiの再起動が必要となってしまった場合は、仮想マシンのダウンタイムが避けられません。

 

とはいえ、すでに述べたように(筆者の想定してる)この事象の場合では、仮想マシンの稼働やvSANデータオブジェクトの可用性への影響はなく、ただちの対処が必要必要な状況ではありません。

 

即座に対処する必要がないだけでなく、また即座に対処(仮想マシンの停止)できない場合がほとんどですので、とりあえず対応を保留し、仮想マシンのダウンタイムを調整する、というのはほぼすべてのパターンで採用される暫定対応です。

 

では、実際にダウンタイムの調整が完了し、いざESXiの再起動を実施する場合はどのようにしたらよいでしょうか?

 

以下のパターンが考えられます。

 

① 仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる(ダウンタイム30分~数時間)

② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動(ダウンタイム数分~数十分)

③ 仮想マシンを強制的にPowerOff(Kill)し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

④ 仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

 

 

GuestOS側からShutdownする理由

 

誤解を避けるためにまず用語を確認しておきます。私の記事の中では以下の意味で使用します。

 

Node:ESXiがインストールされた物理サーバ。VxRailの場合はPowerEdgeを使っています。(Quantaもあるけど)

ESXi: VMwareが提供するHypervisor。仮想マシンを作成し、管理し、実行する。ホストとも呼ばれることがある

仮想マシン:VMと略して呼ばれることもある。Hypervisorが提供する仮想ハードウェア。GuestOSを実行できる。

GuestOS:仮想マシン上で実行されるOS。WindowsやLinuxなど。

 

なぜこのタイミングで用語を確認したのかというと、仮想マシンとGuestOSの違いが明確に使い分けられていない場合や、そもそも用語が異なる場合があるからです(仮想OS、仮想ホスト、アプリなど。。。)

 

さて、本題にもどってvMotionができない場合はGuestOS側からShutdownする必要があると説明していますがなぜでしょうか。

 

本記事では主にhostdの不具合によるvMotion不可のケースを想定していますが、hostdが正しく動作していない場合、ESXiのCLIやWebClient GUIといったツールから対象の仮想マシンをShutdownすることができません。(hostdに依存しているため)

 

したがって、そのような場合に安全にGuestOSをShutdownするにはGuestOS側の機能を使うしかありません。

たとえばWindowsOSを稼働させている場合は、WindowsOSにRDPなどでログインしてShutdown操作をすることになります。

Linuxの場合はSSHでログインしてShutdownコマンドにて落とすのが一般的と思います。

 

ではもしRDPやSSHが無効でGuestOS側からShutdownができない状況だったら?

→その場合は強制的に落とすしか手段がありません。(仮想マシンのkill or ESXiごと強制再起動)

 

それなら初めから全部強制的に落とせばいいんじゃないの?と思われる方もいらっしゃるかもしれませんが、たとえばご自身のPCを落とすときに時間短縮になるといって、電源ケーブルを抜いたり、バッテリーを抜いたりして落とす人がいるでしょうか?

そのような無茶をした場合、作業中のファイルが破損してしまう場合がありますので、特殊な場合をのぞき、基本的にはきちんとシャットダウンしてから落とす必要があります。

 

 

本記事ではhostd不具合を前提とした、vMotion不可ケースの対応として、とりあえず静観or対応保留が可能であることと、ESXi再起動をともなう作業のためにはGuestOS側からのShutdownが推奨であることを説明しました。

 

次回からは①~④までの手順を説明していきます。

 

※下記URLから直接それぞれのページへ飛べます。

仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる(ダウンタイム30分~数時間)

仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動(ダウンタイム数分~数十分)

仮想マシンを強制的にPowerOff(Kill)し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

vMotionできない、、、そんな時。 (その②)

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。

 

vMotionできない、、、そんな時。      (その①)

 

 

本記事では前回記事で説明した対処法の一つである、

 

① 仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる(ダウンタイム30分~数時間)

 

について説明します。

 

 

実施方法

 

  1. 仮想マシンのダウンタイムの調整が完了したら、対象ESXi上の仮想マシンをすべてGuestOS側からShutdownしてください。
    • 具体的なShutdown手順や対象の仮想マシンを管理している担当者もしくは構築ベンダやOSベンダにご相談ください。
    • 安全にShutdownできないVMがある場合は、強制的に落とすしかありません。その場合はGuestOSのファイルシステムが破損する可能性があります。
  2. 対象ESXi上のすべての仮想マシンをShutdownし終わったら、ESXiのサポート(VxRailの場合はDell EMC)の指示通りにESXiを再起動します。
    • vSANを利用している場合、かならずvSANデータオブジェクトがすべて健全であることを確認してください。(後述)
    • 障害の内容や状況に応じて再起動の手順が異なる場合がありますが、たいていの場合はvSANデータオブジェクトの健全性を確認してからNodeの強制リセット(iDRAC or BMC)のパターンで問題ないです。
  3. ESXiの再起動が完了したらvCenterから正しく認識されている(応答なし状態ではない)ことをvSphere Web Clientから確認し、Shutdownした仮想マシンを起動してください。
  4. 最後にvSANヘルスチェックとVxRail ManagerのDiagnostic(VxRailの場合)を実施して健全性を確認してください。
    • こちらのヘルスチェック手順をご参考にしてください
    • エラーや警告があった場合はサポートにご連絡ください。

 

この方法のメリット・デメリット

メリット

    • 比較的簡単
    • vCenterやPSCの配置に依存しない
      • 対象のESXi上にvCenterやPSCがいた場合、それらはShutdownされるが本手順では関係ない

 

デメリット

    • 最低でも15分くらいはダウンタイムが発生する
    • 万が一ESXiが起動してこなかった場合は数十分~数時間のダウンタイムが発生する場合がある。
      • とりいそぎ他のESXiで起動する必要があるため

 

この方法の使いどころ

以下の場合にお勧めです。

    • 仮想化環境の操作にあまり慣れてない
    • 手順をシンプルにしてオペレーションミスを防ぎたい
    • メンテナンスウインドウをとしてダウンタイムを5~8時間程度確保できる

 

 

 

(補足)vSANデータオブジェクトの健全性を確認

vSAN環境では仮想マシンが使用するデータはCluster内の各ESXiが分散して保有することで冗長性を確保しています。

もしvSANデータオブジェクトが健全でない(=冗長性が確保されていない)状態でESXiを再起動してしまうと、データにアクセスできなくなる仮想マシンが出てくる可能性があります。

なのでESXiの(強制)再起動前に必ずvSANデータオブジェクトの健全性を確認しましょう。

 

確認方法はvSphere WebClientにログインして以下の画面を開いてください。

右上の再テストボタンも押してください。

 

2.PNG

 

赤線を引いたVirtual SAN オブジェクトの健全性がパスしていれば問題ありません。

画面下部ですべてのobjectがhealthyであることを確認してください。

 

また失敗となっているネットワーク、物理ディスク、クラスタは”応答なし”状態のESXiがある場合は必ずでますのでこの段階では無視してください。

 

 

 

以上です。次回は、

② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動(ダウンタイム数分~数十分)

について説明します。

vMotionできない、、、そんな時。 (その③)

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。

 

vMotionできない、、、そんな時。      (その①)

vMotionできない、、、そんな時。      (その②)

 

本記事では前回記事で説明した対処法の一つである、

② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動(ダウンタイム数分~数十分

について説明します。

 

実施方法

 

※下記手順では仮想マシンの停止~起動を繰り返していますが、必ず1 VM ずつ実施してください。

本手順では仮想マシンを順々に移動していきますが、VMの種別として、以下の順番で実施します。

1.GuestOSから安全にShutdownできるVM

2.VCSA/PSC

3.GuestOSから安全にShutdownできないVM

      • 安全にShutdownできないVMとはGuestOS側からShutdownする手順が存在しないVMのことです。
      • VxRail環境ではVMware Log InsightがデフォルトではGuestOS側からShutdownする方法がなく、安全にShutdownできないVMに相当します。

 

 

対象ESXi上の安全にShutdownできるVMの移動方法

 

    1. 仮想マシンのダウンタイムの調整が完了したら、対象ESXi上の仮想マシンの一つGuestOS側からShutdownしてください。
      • 具体的なShutdown手順や対象の仮想マシンを管理している担当者もしくは構築ベンダやOSベンダにご相談ください。
    2. Shutdownできたことを確認する
      • Ping疎通などで確実にOSが落ちたことを確認してください。
      • 対象ESXiにてコマンドが発行できる場合はlocalcli vm process listコマンドから対象VMがいないことを確認してください。
      • なお、OSレベルでのShutdownが完了したのちであっても、下図のようにGUI上ではDisconnect(または切断状態)のままであり、対象VMについて操作はできません。(※下図はVxRail Manager VMをShutdownした後です。)
      • 3-1.PNG
    3. Shutdownした仮想マシンを起動するESXiのHost Clientを起動する(WebClientではない)
    4. HostClientから仮想マシンの登録ウィザードを起動する
      • 3-2.PNG
    5. 既存の仮想マシンの登録を選ぶ
      • 3-3.PNG
    6. データストアから対象のVMを探す
      • 3-3-1.PNG
    7. データストアから対象のVMを探す
      • 3-4.PNG
    8. 対象の仮想マシンが選択されていることを確認して次の手順に進み、登録を完了させる
      • 3-5.PNG
    9. 登録が完了するとWebClientで切断状態(またはdisconnected)ではなくなる
      • 3-6.PNG
    10. 手動で別のESXiに移動した場合、ネットワークアダプタに接続できなくなるため、WebClientからネットワークアダプタをいったん別のポートグループに変更した後、再度元のポートグループに戻す。
      • 3-7.PNG
    11. ネットワークアダプタのポートグループ設定を変更→戻しを実施したのちにVMを起動する。
    12. 起動時に質問への回答を選択する
      • 3-8.PNG
    13. 移動しました、を選択してOKをおすとVMが起動する
      • 3-9.PNG
    14. 仮想マシンの移動と起動が完了したので、GuestOSレベルでの動作を確認する。
    15. 同様の作業を対象ESXi上の安全にShutdownできるすべてのVMで実施する。※ただしVCSA/PSCでは実施しない。
    16. 対象ESXi上のすべての仮想マシンをShutdownし終わったら、ESXiのサポート(VxRailの場合はDell EMC)の指示通りにESXiを再起動し、作業後にヘルスチェックを実施してください

 

 

 

対象ESXi上のVCSA/PSCがある場合の移動方法

 

    1. 安全にShutdownできるVMがすべて移動済みであることを確認する。
    2. WebClientにて分散スイッチの新規ポート作成ウィザードを起動する
        • 3-10.PNG
    3. 適当に名前をつける
        • 3-11.PNG
    4. ポートバインドの種類として短期ポート(もしくはEphemeral port)を選択する
        • 3-12.PNG
      1. ポートバインド以外の設定はVCSA/PSCポートグループの設定と同じにする
      2. ポートグループの作成完了時に以下のエラーがでるが、対象ESXiでのポートグループ作成に失敗したことを示すだけなので静観する
          • 3-13.PNG
        1. ポートグループの作成が完了したら以下を実施して、ポートグループの設定が正しいことを確認する。
          1. VxRail Manager VMが稼働するESXiのHostClientを起動する
          2. VxRail Manager VMの設定の編集から、上記で作成した短期ポートのポートグループに設定する
              • 3-14.PNG
          3. 設定が完了したら、vCenterとの接続に問題がないことを確認する
            • VCSAやESXiからPing可能であることを確認
            • VxRail Manager GUIにログインまで可能であることを確認
          4. ポートグループの設定確認が完了したら、VCSAとPSCをGuestOS側から停止する
          5. 別のESXiのHostClientからVCSAとPSCを登録する
          6. HostClientにてVCSAとPSCを編集して作成した短期ポートのポートグループに接続する
          7. VCSA/PSCを起動する
          8. 起動後、WebClientに接続が完了したら、VCSA/PSCのポートグループをもともとのポートグループに戻す
          9. VCSA/PSCの正常動作を確認する
          10. 対象ESXi上のすべての仮想マシンをShutdownし終わったら、ESXiのサポート(VxRailの場合はDell EMC)の指示通りにESXiを再起動し、作業後にヘルスチェックを実施してください
          11.  

            対象ESXi上の安全にShutdownできないVMの移動方法

              1. 本手順の実施をする前に対象ESXi上には、安全にShutdownできないVMしかいないことを確認してください
                • 安全にShutdownできないVMとはGuestOS側からShutdownする手順が存在しないVMのことです。
                • VxRail環境ではVMware Log InsightがデフォルトではGuestOS側からShutdownする方法がなく、安全にShutdownできないVMに相当します。
              2. 正常にShutdownできない場合はESXiごと落とすか個別にKillするしかありません。本手順で想定している状況ではESXiへSSHでログインすらできない場合もあり、その場合は個別のKillは実施できず、ESXiごと落とす手順になります。
              3. 強制的にVMを落とす手順は、PCの電源を引っこ抜く行為に等しくファイルシステムが破損するリスクがあります。仮想マシン上で稼働するOSベンダやアプリケーションベンダに相談し、少しでも安全に落とせるような状況で実施してください。
              4. 実際の移行手順としてはvSphere HAによる移行が一番簡単ですので、BMCやiDRACのハードウェア管理インターフェースからESXiをShutdownするような手順になりますが、実施する前にかならずvSphere Web ClientからvSANヘルスチェックを実施して、冗長性の低下したデータがないことを確認してください。
              5. データ冗長性に問題ないことが確認できたら対象ESXiを強制的にShutdownし、PonwerOnしてください。
              6. vSphere HAが有効な場合は自動的にほかのESXi上で再起動されます。
              7. 設定や条件などによってほかのESXi上で再起動されなかったVMはESXiの起動後に手動で起動するか、ほかのESXiの仮想マシンを再登録して起動してください。
              8. 起動後、正常性を確認してください。
              9. ESXiの再起動が完了したらvCenterから正しく認識されている(応答なし状態ではない)ことをvSphere Web Clientから確認し、Shutdownした仮想マシンを起動してください。
              10. 最後にvSANヘルスチェックとVxRail ManagerのDiagnostic(VxRailの場合)を実施して健全性を確認してください。
              • こちらのヘルスチェック手順をご参考にしてください
              • エラーや警告があった場合はサポートにご連絡ください。

             

            この方法のメリット・デメリット

            メリット

              • ダウンタイムを短くできる。
              • VMの移動を複数回に分けて実行できる
              • 万が一ESXiが起動してこなくても安全

             

            デメリット

              • 手順が複雑

             

            この方法の使いどころ

            以下の場合にお勧めです。

              • ダウンタイムを少しでも短くしたい
              • 長時間のメンテナンスウインドウを確保できない
              • VMによってメンテナンスウィンドウの時間が異なる

             

             

            今回は非常にボリュームの大きい内容となっていましましたが、手間をかけてのダウンタイムを短くしたい場合などに有効な方法を紹介しました。

             

            次回は、

            仮想マシンを強制的にPowerOff(Kill)し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

            について説明します。

            Compute Resource selection when creating VM on ESXI

            $
            0
            0

            Hi everyone,

            I am new to vmware so have some very basics question:

            1)When creating a VM, one option is to choose a ESXI host that will provide compute resource for the VM such as processor.

            Does this compute resource also include RAM ? if yes    is  it allocated out of ESXI HOST's total RAM?

             

            2) Let say we have single socket dual core processor, assume hyper threading is not enabled.

            Will  ESXI  see   1X2= 2 Logical processors or pcpu?

            If hyper threading is enabled, then :

            ESXI see 1 x2X2=4 Logical processors?

             

            3)  VCPUS are mapped to logical processors in some ratio,  Ideally we want single VCPU mapped to single Logical CPU ( pCPU) to avoid contention. But we can also do over subscription for example:  4 VCPU are mapped to single Logical Processor ( pcpu), the draw back is 4 vCPU will be scheduled to single logical Processor , depending upon the load ,some VCPU will have to wait longer than others to be serviced by the logical processor.

             

            Did i get it right?

             

            4)  Let say we want to achieve following goal:

            Bare minimum, a VM is given 2 VCPU, but in case of heavy load such as VCPU  hitting 190% utilization combined, i.e  each VCPU is at 95% utilization,   VM should be able to request 2 additional vCPU to meet the demand. Once the demand is gone, these 2 additional  VCPU should be returned to ESXI host.  Is it possible?

             

            Appreciated!!


            vMotionできない、、、そんな時。 (その④)

            $
            0
            0

            **** 留意事項 *****

            こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

            DECNが近い将来に廃止となるためこちらに移行させていただいております。

            内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

             

             

            前回よりだいぶ時間が空いてしまいましたが、本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。

             

            vMotionできない、、、そんな時。      (その①)

            vMotionできない、、、そんな時。      (その②)

            vMotionできない、、、そんな時。      (その③)

             

             

             

            本記事では前回記事で説明した対処法である以下について説明します。

            ③ 仮想マシンを強制的にPowerOff(Kill)し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分)

             

            ④ 仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

             

            予告では③のみでしたが、似たような話なのでまとめることにしました。

             

            今回の手順は基本的には前回記事の最後の手順(対象ESXi上の安全にShutdownできないVMの移動方法)と同様です。

            本手順は稼働中のVMを強制的に落とす手順のためデータの破損が発生する可能性があります。したがって以下の注意事項があります。

             

            基本的な注意事項は以下です。

            ・安全にシャットダウンできないVMに対して実施する。シャットダウンできる場合は前回記事に沿った対応をする

            ・実施する前に必ずデータの冗長性低下が起こっていないことを確認する。

            ・大事なデータは必ずバックアップをする

             

             

            実施方法

             

            事前の確認

              1. vSphere Web ClientからvSANヘルスチェックを実施して、冗長性の低下したデータがないことを確認する
              2. 対象VMのデータのバックアップおよびDiskにコミット済みであることを確認する
                • 可能であればアプリケーションレベル・仮想マシンレベルのバックアップを取得する
                • 簡易的にスナップショットの取得でも可
                • 可能であれば仮想マシン負荷の低い時間帯を狙って実施する
                • 未コミットのデータを可能な限りDiskにコミットする(Linuxのsyncコマンドなど)
              3. 対象VMにVCSA/PSCが含まれる場合は事前にEphemeral Portを作成する
                • 手順については前回記事の 「対象ESXi上のVCSA/PSCがある場合の移動方法」を参照ください

             

            ESXiごとShutdownする手順

            事前の準備・確認が完了したらいよいよ仮想マシンを強制的に落とします。

            一番簡単な方法はホストであるESXiごと落としてしまうことです。

            手順については前回記事の「対象ESXi上の安全にShutdownできないVMの移動方法」を参考にしてください。

            全仮想マシンがすべて停止し、vSphere HAが有効な場合は別のESXiホストでVMが再起動します。

            vSphere HAが無効な場合は対象ESXiホストの再起動が完了したのちに、手動で起動してください。

             

            vSphere HAが有効なのに仮想マシンが再起動されなかった場合は以下の理由が考えられます。

             

            各仮想マシンを個別に停止する方法

            状況によっては各VMを一つずつ停止したい場合もあると思います。その場合は対象ESXiホストにSSHかESXi Shellでログインし、Killを実施する必要があります。

             

            仮想マシンの個別のKillについては以下が参考になります。

             

            killした後の挙動については状況に依存します。状況によっては障害によってすでにバックグラウンドでHAジョブが開始されており、仮想マシンファイルのロック取得待ちとなっている場合があります。この場合は仮想マシンが停止するとHAジョブにより別のホストで再起動されます。

             

            状況によってはHAジョブが開始されていない場合もありますので、その場合は手動にて他のHostに再登録および起動とネットワークアダプタの再設定を実施する必要があります。

            手順については前回記事の「対象ESXi上の安全にShutdownできるVMの移動方法」のステップ2以降をご参照ください。

             

             

            いかがでしたでしょうか。一応今回でこのシリーズは終了となります。

            仮想化技術の発展によってサーバの可用性と可搬性が向上し、多くのメリットを享受できるようになりましたが、一方で今回の一連の記事で想定している障害のように、ハイパーバイザーに起因する不具合によって、物理サーバにはなかったダウンタイムが発生してしまう場合もあります。

            しかしながら物理サーバ時代の不便さと比べれば、仮想化のメリットは非常に大きく、管理負荷低減やサービスレベルの向上が実現されていることも事実とおもいます。

            hostdの不具合によるvMotion不可という事象は、仮想化基盤の管理者であれば一度は経験し、かつお客様にとっては対処に困る障害対応と思います。

            本不具合だけで仮想化技術を嫌いにならず、長く付き合っていただければと思います。

            もしhostd不具合などでvMotion不可となる事象が発生した際は、本記事によってお客様のストレス軽減や業務影響の低減に寄与できれば幸いです。

            vSAN disks total used capacity is not matching with the vCenter cluster used capacity

            $
            0
            0

            vSAN disks total used capacity is not matching with the vCenter cluster used capacity

             

            Cluster used capacity in vCenter is : 2.66TB and the in vSAN disks total capacity is 6.23TB. Please find the screenshot attached for you reference.

             

            Please let me know why there is a difference in the used capacity.

            vCenter に定義されているアラーム定義のダンプを取得する方法

            $
            0
            0

            **** 留意事項 *****

            こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

            DECNが近い将来に廃止となるためこちらに移行させていただいております。

            内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

            アラーム定義情報を一括で取得したい!

             

            VxRailのログを見ていると、ときどき突如としてalarm-xx が現れることがあります。

             

             

            alam-xxはvCenterで定義されている個々のアラームに対応するMoref IDなので、当然ながらそれに対応するアラーム定義があるのですが、残念ながらMoref IDは環境によって異なりますし、(あるかもしれませんが)ID採番のRuleなどもなさそうなのでMorefIDだけからアラームの詳細を予測することができません。

             

             

             

            そのため、何かが起きていることはわかるのですが、「何が起きているの!!??」とちょっとドキドキしてしまいます。

            そういう時、「全部のAlarmのMorefIDと対応する情報が一括で取得できたらいいのに・・・」と常々思っていました。

             

             

             

            また、運用管理者の観点からも現在のシステムに定義されているアラームの一覧やダンプを取得したい!ということはあるかと思います。

             

             

            しかしながら、WebClientや標準のコマンドとしてアラーム定義の細かい情報を一括でExportしたりする方法は見当たりませんでした。

            アラーム名と定義場所は出せるかも知れませんが細かいトリガーやアクションの情報となるとWebClientから一つ一つコピー&ペーストするような作業になってしまうのでとてもやる気になりません。

             

             

            ということで、今回はvSphere SDK for pythonを利用して、VCSA CLI上で一括でアラーム定義情報をDumpスクリプトを作成しましたので、使用方法と合わせて共有させていただきます。

             

             

            開発・検証環境

             

            今回のスクリプトは以下の環境で動作検証をしました。

            多少Versionが違っても動くとは思います。

            もし動かなかったらコメント等で教えていただければ、時間があるときに修正します。

            もちろんご自由にスクリプトを書き換えていただいてもかまいません。

             

            VxRail™ Appliance 4.5.229

            VMware vCenter Server Virtual Appliance (vCSA) 6.5 U2c GA build 9451637

            VMware ESXi 6.5 Express Patch 11 GA build 10719125

             

             

             

            使用方法

             

            いざ、スクリプトファイルと添付して使用方法を書くぞ!、、、と思った段階で初めて気づきましたが、このブログはファイルの添付ができないんですね。。。仕方ないのでソースを直に書きます。

            HTMLによる不必要な改行の挿入などによるコード破壊を防ぐため、あえてフォーマットを無効にしています。

            少し見栄えが悪いですがご容赦ください。

            pythonは文法上、改行やインデントにシビアなのでコピペする際にご留意ください。不必要な空行や、スペースが一つ挿入されただけでも動かなくなります。

             

            #####   ここから ######   # coding:utf-8 #!/usr/bin/env python  from __future__ import print_function from __future__ import unicode_literals import os import codecs import subprocess import re import string import json import ssl import sys import traceback import atexit import platform import time import datetime import socket import getpass import argparse  sys.path.append("/usr/lib/vmware/site-packages/")  from pyVmomi import vim, vmodl from pyVim import connect from pyVim.connect import SmartConnect, Disconnect from pyVim.task import WaitForTask   def parse_argument():     parser = argparse.ArgumentParser(description='Print All Alarm Definition')     parser.add_argument('-s', '--server', dest="server", required=True, help='vCenter IP Address')     parser.add_argument('-u', '--username', dest="username", required=True, help='vCenter SSO admin username')     parser.add_argument('-p', '--password', dest="password", required=True, help='vCenter SSO admin password')     args = parser.parse_args()     return args    def main():     args = parse_argument()     vcipaddr = args.server     vcusername = args.username     vcpassword = args.password     context = None     context = ssl.create_default_context()     context.check_hostname = False     context.verify_mode = ssl.CERT_NONE     si = connect.Connect(host = vcipaddr,user = vcusername,pwd = vcpassword)     atexit.register(Disconnect, si)          alarms = si.content.rootFolder.declaredAlarmState     for alarm in alarms:         print(alarm.alarm.info)  if __name__ == '__main__':     main()    #####  ここまで  #######  

             

             

            ↑上記の内容をVCSAの適当な場所にdump_AlarmDefinition.pyとして保存してください。

             

            保存したら以下のSyntaxで実行してみてください。

             

            root@vc [ ~ ]# python dump_AlarmDefinition.py -s <vcenter ip> -u <vcenter sso user> -p '<vcenter sso user password>'

             

            パスワードに特殊文字が含まれる場合は、シングルクォーテーションで括ってください。

            例は以下です。

            ※例にあるパスワードはVMware HOLで用いられるものを仮で使用しており、その他の意味はありません。

             

            実行例:

            root@vc [ ~ ]# python dump_AlarmDefinition.py -s localhost -u administrator@vsphere.local -p 'VMware1!'

             

             

            サンプル出力:

            root@vc [ ~ ]# python dump_AlarmDefinition.py -s localhost -u administrator@vsphere.local -p 'VMware1!'

            (vim.alarm.AlarmInfo) {

               dynamicType = <unset>,

               dynamicProperty = (vmodl.DynamicProperty) [],

               name = 'Host Requires Encryption Mode Enabled Alarm',

               systemName = 'alarm.HostRequiresEncryptionModeEnabledAlarm',

               description = 'Alarm to indicate that the host requires encryption mode enabled.',

               enabled = true,

               expression = (vim.alarm.OrAlarmExpression) {

                  dynamicType = <unset>,

                  dynamicProperty = (vmodl.DynamicProperty) [],

                  expression = (vim.alarm.AlarmExpression) [

                     (vim.alarm.EventAlarmExpression) {

                        dynamicType = <unset>,

                        dynamicProperty = (vmodl.DynamicProperty) [],

                        comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

                        eventType = vim.event.EventEx,

                        eventTypeId = 'com.vmware.vc.host.Crypto.ReqEnable.KeyMissingOnKMS',

                        objectType = vim.HostSystem,

                        status = 'red'

                     },

                     (vim.alarm.EventAlarmExpression) {

                        dynamicType = <unset>,

                        dynamicProperty = (vmodl.DynamicProperty) [],

                        comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

                        eventType = vim.event.EventEx,

                        eventTypeId = 'com.vmware.vc.host.Crypto.ReqEnable.KMSClusterError',

                        objectType = vim.HostSystem,

                        status = 'red'

                     },

                     (vim.alarm.EventAlarmExpression) {

                        dynamicType = <unset>,

                        dynamicProperty = (vmodl.DynamicProperty) [],

                        comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

                        eventType = vim.event.EventEx,

                        eventTypeId = 'com.vmware.vc.crypto.HostKeyUpdatedEvent',

                        objectType = vim.HostSystem,

                        status = 'green'

                     },

                     (vim.alarm.EventAlarmExpression) {

                        dynamicType = <unset>,

                        dynamicProperty = (vmodl.DynamicProperty) [],

                        comparisons = (vim.alarm.EventAlarmExpression.Comparison) [],

                        eventType = vim.event.EventEx,

                        eventTypeId = 'com.vmware.vc.host.Crypto.Enabled',

                        objectType = vim.HostSystem,

                        status = 'green'

                     }

                  ]

               },

               action = <unset>,

               actionFrequency = 0,

               setting = (vim.alarm.AlarmSetting) {

                  dynamicType = <unset>,

                  dynamicProperty = (vmodl.DynamicProperty) [],

                  toleranceRange = 0,

                  reportingFrequency = 300

               },

               alarmMetadata = <unset>,

               key = 'alarm-1',

               alarm = 'vim.alarm.Alarm:alarm-1',

               entity = 'vim.Folder:group-d1',

               lastModifiedTime = 2018-12-01T17:27:21.718Z,

               lastModifiedUser = '',

               creationEventId = 0

            }

             

            ........... 以降、全アラーム情報がDumpされる

             

             

            問題なく情報をダンプすることができました。

            出力がかなり長くなりますのでリダイレクトなどしてファイルにいったんファイルに出力するのがお勧めです。

            アラーム定義のオブジェクト情報がそのまま表示されているので見にくいですが、アラーム定義の情報をすべて網羅しているのでテキスト処理などで必要な部分のみを抽出したりできますし、またソースを変更して、名前とトリガーとアクション情報のみを抽出することも可能です。

             

            例えばスクリプト中の

             

            print(alarm.alarm.info)

             

            の部分を

             

            print(alarm.alarm.info.name)

            print(alarm.alarm.info.expression)

            print(alarm.alarm.info.action)

             

            とすれば、アラーム定義の名前とトリガー&アクション部分のみを抽出できます。

            ※pythonなのでインデントや改行には注意してください。↑はHTMLのフォーマットを無効にしていません

             

             

            いかがでしたでしょうか?実際に業務で使える情報抽出まではあと一段階の処理が必要となるとおもいますが、

            テキスト処理やpythonであればいくらでも有識者はいますので、このDump情報があれば環境に合わせて自由に必要な情報を抽出・成形できると思います。

             

            この記事の内容がお役に立てれば幸いです。

            html5 client, vsan > services pane dysfunctional

            $
            0
            0

            All,

             

            I've got a strange situation with vsan services -pane (cluster: configure > vsan > services). This is latest vcsa, version 6.7.0 Build: 14368073.

            The actual task that drove me here was to disable "Network diagnostics mode" under "performance services". The only functional workflow here is "advanced options", the pane loads and you can change settings. "Performance service" and "vsan iscsi target service" have frozen onto loading-status. The other two workflows will open the pane but it is stuck onto loading (circle rotating...). A reboot of the vcsa did not resolve the situation. It is not browser, user nor computer related as more than one were tested. Also all data was removed from the browser, with no help. It is more likely client related as the flash-client works well. Of course workflows differ and eg desired function to disable network diagnostics does not exist on the flash client. Now, how to remediate the problem? And, is there a cli command to disable "Network diagnostics mode"?

             

            Please find below a couple of screenshots which clarify the situation.

             

             

            Edit: moved question to vcenter appliance as it is more likely appropriate here.

            VMware player 12.5.9 crashes when USB device is connected.

            $
            0
            0

            VMware player 12.5.9 crashes when USB device (ext HDD, USB dongle, ...  is connected.

            This is since a Windows 10 update.

            VM gets stuck, nothing doesn't work anymore, not even power down.

            The only  way to stop is kill the VMware player.

            Viewing all 178545 articles
            Browse latest View live


            <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>