Azure Virtual MachineのManaged Disksサイズを変更する(FIOでIOPSを測定もする)

 

Azure VM のデータディスクの拡張を試してみました。
また、Managed DiskはサイズによってIOPSが違います。

今回は併せてManaged Diskのサイズ拡張による、IOPSの変化をFIOで測定してみました。

Azure VMでのデータディスク拡張作業は、下記条件で実施しています。

    • OSはCent OS 7.7
    • Managed DISKはPremium SSDを利用
    • 32GB→512GBに拡張
    • データディスクは/dev/sdc
    • データディスクは/mnt/diskにマウント済みである。
    • IOPSはFIOで測定

※念のため、必ずバックアップを取得したうえで作業を実施して下さい。

なお、データディスクの追加に関しては以下の記事に纏めております。

Azure VM(CentOS 7)にデータディスクを追加する

1 .Azure VMのデータディスクサイズ変更

データディスクのサイズ変更を、Azure Portal上で実施します。
作業はVirtual Machine 停止させて実施します。
データディスクのアタッチ、デタッチはオンラインでも可能ですが、アタッチ済みのディスクの構成変更は、仮想マシンを停止する必要があります。(一度デタッチ後に構成変更して再アタッチという手も。。。)
対象のVirtual Machineを選択後、SettingsにあるDisksをクリックします。以下の画面が表示されますので、拡張するデータディスクをクリックします。

Disksの画面に移動するので、構成をクリックします。以下の画面が表示されますので、アカウントの種類やサイズの項目を変更します。今回はアカウントの種類をPremium SSDサイズを512GBとし保存をクリックします。

保存が完了したら、Virtual Machineを起動します。

2. Cent OSでデータディスクのボリューム拡張設定

Virtual Machineを起動した段階では、Azure側で実施したディスクの拡張はデバイスとしては認識されていますが、ボリュームとしては拡張されていない状態です。

dfのコマンド結果を見ると、拡張前の32Gしか認識されていない事が分かります。

[ユーザー名@ホスト名 tmp]$ fdisk -l /dev/sdc[

Disk /dev/sdc: 549.8 GB, 549755813888 bytes, 1073741824 sectors

[ユーザー名@ホスト名 tmp]$ df -h | grep /dev/sdc

/dev/sdc1 32G 6.1G 24G 21% /mnt/disk

ボリュームのサイズ変更を、fdiskコマンド使って行います。

[ユーザー名@ホスト名 tmp]$ fdisk /dev/sdc

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

コマンド (m でヘルプ): p

Disk /dev/sdc: 549.8 GB, 549755813888 bytes, 1073741824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
Disk label type: dos
ディスク識別子: 0x00140f2e

デバイス ブート 始点 終点 ブロック Id システム
/dev/sdc1 2048 67108863 33553408 83 Linux

コマンド (m でヘルプ): d
Selected partition 1
Partition 1 is deleted

コマンド (m でヘルプ): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
パーティション番号 (1-4, default 1): 1
最初 sector (2048-1073741823, 初期値 2048):”入力せずにEnter”
初期値 2048 を使います
Last sector, +sectors or +size{K,M,G} (2048-1073741823, 初期値 1073741823):”入力せずにEnter”
初期値 1073741823 を使います
Partition 1 of type Linux and of size 512 GiB is set

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!

ioctl() を呼び出してパーティションテーブルを再読込みします。

WARNING: Re-reading the partition table failed with error 16: デバイスもしくはリソースがビジー状態です.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
ディスクを同期しています。

以上の操作が完了したら、パーティションを拡張します。これで作業完了です。

[ユーザー名@ホスト名 tmp]$ resize2fs /dev/sdc1

確認してみると、データディスクのサイズが変わっているのがわかります。

[ユーザー名@ホスト名 tmp]$ df -h | grep /dev/sdc 

/dev/sdc1 504G 6.1G 477G 2% /mnt/disk

3.FIOでManaged DiskのIOPSを測定

FIOのセットアップはyumコマンド(epelは有効)でOKです。関連パッケージを含めてインストールされます。

[ユーザー名@ホスト名 tmp]$ yum -y install fio

FIOのコマンドは以下のサイトを参考にしています。

https://qiita.com/toshihirock/items/fa4d310115e6921ab0ac

実行してみると以下のような結果になりました。ランダムreadでもスペック通りのIOPSが出ています。シーケンシャルでもおおむね同じ数値が出ています。

#シーケンシャルwriteの場合
 write: IOPS=402, BW=1610KiB/s (1649kB/s)(15.0MiB/10154msec)
#シーケンシャルreadの場合
 read: IOPS=2347, BW=9391KiB/s (9617kB/s)(92.3MiB/10069msec)

#ランダムwriteの場合
 write: IOPS=395, BW=6332KiB/s (6484kB/s)(69.8MiB/11295msec)
#ランダムreadの場合
 read: IOPS=2337, BW=36.5MiB/s (38.3MB/s)(383MiB/10490msec)

なお、いくつかのパターンで試すと、”ほぼ”Managed Diskの指標通りになっている事がわかります。

#Standard HDD(32GB)の場合(シーケンシャルread)
 read: IOPS=562, BW=2251KiB/s (2305kB/s)(22.3MiB/10131msec)

#Standard HDD(32GB)の場合(シーケンシャルwrite)
  write: IOPS=152, BW=610KiB/s (625kB/s)(6296KiB/10316msec)

#Premium SSD(32GB)の場合(シーケンシャルread)
  read: IOPS=122, BW=488KiB/s (500kB/s)(5148KiB/10544msec)

#Premium SSD(32GB)の場合(シーケンシャルwrite)
  write: IOPS=122, BW=489KiB/s (500kB/s)(5388KiB/11028msec)

※Writeが遅いのですが、この原因は不明です。

 

Azure Virtual Machineを別テナントに移してみた

 

今回は、Azure VMをAzureの別テナントへ移行してみました。

実際に試行錯誤して実施してみたのですが、最終的には以下のような段取りになりました。

      • Azure VMのManaged Disksを別テナントのBlobストレージにコピーする
      • コピーしたファイルをManaged Disksに戻す
      • Managed DisksからVMを作成する

実施してみた所、Azure VMのManaged Disksを移行先のテナントのBLOBストレージにVHDファイルとして保管する必要があるようでした。移行先テナントでVHDファイルをManaged Disksに戻すことで仮想マシンを作成することで実現出来ました。

今回作業にあたっては、PowerShellを利用して実施してみました。

※なお、同じテナントの別サブスクリプションへは、Managed Disksのまま移行が可能です。

1 .Azure VMのManaged Disksを移行先テナントのBlobストレージにコピーする

まず事前に以下の準備をしておきます。

      • 移行先のテナントに、ストレージアカウントとBlobストレージのコンテナを準備しておく
      • 移行対象の仮想マシンを停止しておく。(Managed DisksにAzure VMをアタッチしていない場合はそのままで実行可能です。)

Managed Disksを一旦ローカルにダウンロードして、移行先のストレージアカウントにアップロードする事でも対応可能です。

ただ作業が面倒なので、以下のサイトを参考に、Managed Disksをダウンロードせずに、直接移行先のBlobストレージにコピーする方法を試してみました。

サイト記載のサンプルをAz化しています。

https://docs.microsoft.com/ja-jp/archive/blogs/jpaztech/export-managed-disks-to-vhd

Power Shell実行時には各テナントへのログイン画面が表示されます。適時ログインして下さい。

※サイト記載のサンプルをAz化しています。

#Managed Disk Copy PowerShell

# コピー元へのログイン
Login-AzAccount
Select-AzSubscription -SubscriptionId  “コピー元のサブスクリプション ID”

# コピー元のディスクパラメータ
$sourcergname = “コピー元リソースグループ名”
$diskname = “コピー対象のManagedDisk名”

# SAS URL の作成(有効時間を1時間にしています。タイムアウトになる場合は適時調整します。)
$mdiskURL = Grant-AzDiskAccess -ResourceGroupName $sourcergname -DiskName $diskname -Access Read -DurationInSecond 3600

# コピー先の情報
# コピー先テナントにログイン

Login-AzAccount
Select-AzSubscription -SubscriptionId  “コピー先のサブスクリプション ID”

# コピー先の各種パラメーター
$targetrgname = “コピー先リソースグループ名”
$storageacccountname = “コピー先ストレージアカウント名”
$countainername = “コピー先コンテナ名”

$storageacccountkey = Get-AzStorageAccountKey -ResourceGroupName $targetrgname -Name $storageacccountname
$storagectx = New-AzStorageContext -StorageAccountName $storageacccountname -StorageAccountKey $storageacccountkey[0].Value
$targetcontainer = Get-AzStorageContainer -Name $countainername -Context $storagectx

$destdiskname = “コピー後のファイル名”
$sourceSASurl = $mdiskURL.AccessSAS

# コピー
$ops = Start-AzStorageBlobCopy -AbsoluteUri $sourceSASurl -DestBlob $destdiskname -DestContainer $targetcontainer.Name -DestContext $storagectx
Get-AzStorageBlobCopyState -Container $targetcontainer.Name -Blob $destdiskname -Context $storagectx -WaitForComplete

コマンドが完了したら、移行先のBlobストレージ内にファイルが生成されているの確認してください。生成されていたら作業は完了です。

.コピーされたVHDファイルをManaged Disksに変換する

コピーされたファイルをコピー先のテナントでManaged Disksに変換します。

以下のサイトを参考に戻すPower Shellを作ってみました。

https://docs.microsoft.com/ja-jp/archive/blogs/jpaztech/convertvhdtomanageddiskdeployvm

本Power Shellの重要な注意点ですが、OS Typeを指定しないと、変換自体は出来るのですが、後の作業で仮想マシン作成ボタンが押せない状態となります。これでドはまりしました。

Power Shell内で指定するVHDファイルのURLは、VHDファイルが保管されているBlobストレージにて確認します。

Storage ExplorerにてVHDファイルを選択します。右クリックするとプロパティという項目が表示されますので選択します。下記画面が表示されますので、Uriに表示されている内容をコピーします、Power Shell実行時に指定するVHDファイルのURLになります。

実際に実行するPower Shellは下記の通りになりました。

# VHD→ManagedDisk PowerShell

#Select Subscription
$SubscriptionId =“コピー先のサブスクリプションID”
Select-AzSubscription -SubscriptionId $SubscriptionId

#Parameter
$ResourceGroupName = “ManagedDiskのRG名”
$location = “ManagedDiskのロケーション”
$DiskName = “作成するManagedDisk名”
$vhdUri = “コピーしたファイルのURL”
$AccountType =“ストレージアカウントのType (ex; Standard_LRS)”<
$OsType = ”ManagedDiskのOS Type (ex; Linux)”

#Disk Config
$DiskConfig = New-AzDiskConfig `
-AccountType $AccountType `
-Location $Location `
-CreateOption Import `
-SourceUri $vhdUri `
-OsType $OsType

#VHD → Managed Disk
New-AzDisk `
-DiskName $DiskName `
-Disk $DiskConfig `
-ResourceGroupName $ResourceGroupName

※複数のサブスクリプションにログインした状態での作業となるため、作業ミス防止用に明示的にサブスクリプションを指定を追加しています。

Power Shellを実行し完了すると、新たにManaged Disksができています。確認はディスクのメニューでできます。

変換が終了したManaged Disksを選択すると、VMの作成というボタンが表示されてますのでクリックします。そうすると仮想マシンの作成画面に遷移しますので、そのまま作成を進めればAzure VMが作成できます。

※オペレーティングシステムが空白の場合はVMの作成ボタンがクリックできません。

.移行後のAzure VMで作業が必要そうです

なお、OMSエージェントを含む、拡張機能は接続先のテナントが異なる為、再度設定が必要になります。この編でドはまりする事もあるので注意が必要になります。

別件にはなりますが参考程度で見て頂ければと。(結果、関連パッケージのアンインストール、インストールを実施しました。)

Log AnalyticsでLogやリソース情報が取得出来なくなった時にやった事

 

 

Power ShellでAzure VM起動/停止と一緒にディスクタイプを変更する

 

Azure Managed Disksですが、Azure VMの起動停止状態に関わらず使用料金が発生します。

またAccount Type(Premium SSD、Standard HDD)により使用料金が異なります。
Azure VMを停止している時に、Premium SSDを利用する事はコストの無駄になります。Azure VM停止時にPremiumSSD等からStandard HDDに戻す事等で、Azureの利用料金を抑えることができます。

今回は、Azure VM起動時や停止時に、Managed DiskのAccount Typeを変更するPower Shellを作ってみました。

作成にあたっては、以下のサイトを参考にしています。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/convert-disk-storage

Azure VMの起動停止をRunbook使って実施する記事やAzure VMの停止忘れ対応に関する記事も併せて参考にして頂ければと。

Azure AutomationのRunbookで実行時間制限

Azure VMの割り当て解除、停止忘れ対策

1 .Azure VM起動と共にディスクタイプを変更するPower Shell(HDD→SSD) 

Azure VMの起動に併せて、Azure VMに接続されているすべてのManaged DiskをStandard SSDとするようにしてみました。
Power Shell実行時に、VM名を変数として指定し、実行するようにしています。(VM IDを2回指定してますが、気にしないでください。)

#Vm Start (Changed Disk Type)

#VM名を固定にする場合は、下記の通り指定します。(param部分はコメントアウト)
#$vmName =”VM Name”

param (
            [string] [Parameter(Mandatory=$true)] $vmName
            )

$resourceGroupName =“リソースグループ名”
$storageType =“StandardSSD_LRS”

$VM = Get-AzVM -Name $vmName -resourceGroupName $resourceGroupName
$vmDisks = Get-AzDisk | Where { $_.ResourceGroupName -eq $resourceGroupName } | Where { $_.ManagedBy -eq $VM.id }

foreach ($disk in $vmDisks)
 {
  if ($disk.ManagedBy -eq $vm.Id)
  {
  $diskUpdateConfig = New-AzDiskUpdateConfig –AccountType $storageType
  Update-AzDisk -DiskUpdate $diskUpdateConfig -ResourceGroupName $resourceGroupName `
  -DiskName $disk.Name
  }
}

Start-AzVM -ResourceGroupName $resourceGroupName -Name $vmName

起動対象のVM名を指定し、Power Shell実行します。(今回はPowerShell名を、VM_Start_SelectDiskType.ps1としています。)

c:\VM_Start_SelectDiskType.ps1 -vmName VM Name

.Azure VM停止と共にディスクタイプを変更するPower Shell(SSD→HDD

Azure VM停止に併せて、VMに接続されているManaged DiskをすべてStandard HDDにしています。Power Shell実行時に、VM名を変数として指定し、実行するようにしています。

#Vm Stop (Changed Disk Type)

#VM名を固定にする場合は、下記の通り指定します。(param部分はコメントアウト)
#$vmName =”VM Name”

param (
[string] [Parameter(Mandatory=$true)] $vmName
   )

  $resourceGroupName =“リソースグループ名”
  $storageType =“Standard_LRS”

 Stop-AzVM -ResourceGroupName $resourceGroupName -Name $vmName -Force

 $VM = Get-AzVM -Name $vmName -resourceGroupName $resourceGroupName
 $vmDisks = Get-AzDisk | Where { $_.ResourceGroupName -eq $resourceGroupName } | Where { $_.ManagedBy -eq $VM.id }

foreach ($disk in $vmDisks)
{
 if ($disk.ManagedBy -eq $vm.Id)
  {
  $diskUpdateConfig = New-AzDiskUpdateConfig –AccountType $storageType
  Update-AzDisk -DiskUpdate $diskUpdateConfig -ResourceGroupName $resourceGroupName `
  -DiskName $disk.Name

 }
}

停止対象のVM名を指定し、Power Shell実行します。(今回はPowerShell名を、VM_Stop_SelectDiskType.ps1としています。)

c:\VM_Stop_SelectDiskType.ps1 -vmName VM Name

3 .Managed DisksのAccount Typeを確認する

Power ShellでManaged DiskのAccount Typeを表示する事ができます。変更後の確認に使えます。

Get-AzDisk -resourceGroupName  ”リソースグループ名” |ft Name,@{Name=”Name”; Expression={$_.Sku.Name}}

Azure VM(CentOS 7)にデータディスクを追加する

 

今回はAzure VM (CentOS 7) へのデータディスク(Managed Disks(Standard SSD))追加を試してみました。

マイクロソフト様のサイトを参考に検証を進めてみました。

実施した内容は以下の通りになります。

      • データディスクの作成、追加(今回はPowerShellでやってみてます)
      • CentOS上でマウント、パーティション作成、フォーマット、fstabへの追加

 

1.Power ShellでデータDISKを作成し追加

以下のサイトを参考に仮想マシンにデータディスクを追加するPower Shellを作ってみました。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/attach-disk-portal

なお、Power Shell内のリソースグループ名やVM名、データディスク名は適時指定して下さい。

$rgName = ‘リソースグループ名’
$vmName = ‘DISK追加するVM名’
$location = ‘japaneast’
#今回は、Standard SSDなので下記を指定。

$storageType = ‘StandardSSD_LRS’
$dataDiskName = ‘VM名_CashDisk_1(追加するDISK名)’
#今回は、最低の4GBを指定。
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 4
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName$vm = Get-AzVM -Name $vmName -ResourceGroupName $rgName
$vm = Add-AzVMDataDisk -VM $vm -Name $dataDiskName -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1Update-AzVM -VM $vm -ResourceGroupName $rgName

2.Linux(CentOS)上で追加したディスクをマウントしパーティションを作成する

以下のマイクロソフト様のサイトに記載の通りの手順になります。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/attach-disk-portal

まず、仮想マシンにディスクが追加された状況をOS上で確認します。

[root@test-01]# dmesg | grep SCSI

[ 0.342149] SCSI subsystem initialized
[ 0.987188] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[ 2.867663] sd 2:0:0:0: [sda] Attached SCSI disk
[ 2.873137] sd 3:0:1:0: [sdb] Attached SCSI disk
[3965178.687477] sd 5:0:0:1: [sdc] Attached SCSI disk

今回の場合、sdcが追加されているので、fdsikでパーティションを作成します。

今回は新しいパーティションを作成するので、コマンドはnで実施します。

[root@akbwg-web-01 httpd]# fdisk /dev/sdc
Welcome to fdisk (util-linux 2.23.2).Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x07ecc989.The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.コマンド (m でヘルプ): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
パーティション番号 (1-4, default 1): 1
最初 sector (2048-8388607, 初期値 2048):
初期値 2048 を使います
Last sector, +sectors or +size{K,M,G} (2048-8388607, 初期値 8388607):
初期値 8388607 を使います
Partition 1 of type Linux and of size 4 GiB is setコマンド (m でヘルプ): w
パーティションテーブルは変更されました!ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。

最後にmkfsコマンドでディスクをフォーマット後、マウントします。
今回はマウントポイントを/mnt/ramdiskとしてます。
UUIDを指定したマウントを行う為、/dev/sdc1のUUIDをコピーしてfstabを作成します。

[root@test-01]# mkfs -t ext4 /dev/sdc1
[root@test-01]# blkid

/dev/sda1: UUID=”fa2f8157-XXXXX-XXXXXX” TYPE=”xfs”
/dev/sda2: UUID=”12907c8a-XXXXX-XXXXXX” TYPE=”xfs”
/dev/sdb1: UUID=”bb32dd89-XXXXX-XXXXXX” TYPE=”ext4″
/dev/sdc1: UUID=”66891613-XXXXX-XXXXXX” TYPE=”ext4″

[root@test-01]# mkdir /mnt/ramdisk
[root@test-01]# vi /etc/fstab

##fstabに以下を追記します。
UID=66891613-XXXXX-XXXXXX /mnt/ramdisk ext4 defaults,nofail 0 0

OS再起動してマウントされていることを確認します。

なお、Azure VMでのディスクサイズ変更は下記で試してみてますので、併せて見て頂ければと。

Azure Virtual MachineのManaged Disksサイズを変更する(FIOでIOPSを測定もする)

---------------

使われていないAzure Managed Disksやネットワークインターフェースをまとめて削除

 

Azure VMを削除した場合、VM自体は削除されますが、VMに紐づいていたManaged Disksやネットワークインターフェースは一緒に削除されません。

Managed Disksやネットワークインタフェースを個別に削除する必要があります。特に、Managed Disksは削除しない限り使ってなくても課金が継続さます。不必要な場合は削除しておいた方がお得です。

Azure VM削除した時に、一緒に消し忘れる事も結構ありがちですし、都度個別に削除する作業も結構面倒です。

そこで今回はリソースグループ内で利用されていないManaged Disksやネットワークインターフェースをまとめて削除するPower Shellを作ってみました。

1.使われていないManaged Disksをまとめて削除するPower Shell

使用されていない、Managed Disks一覧の取得、削除を行ってみます。

所有者VMが存在しないManaged Disksを使用されていないディスクとしています。

    • 対象リソースグループ名を指定する
    • 削除の場合は1を指定する。取得表示のみの場合は0を指定する。
    • 確認メッセージを表示する場合は-Forceを外してください。

#対象のRG名を指定
$rgName =“リソースグループ名”
$deleteUnattachedDisks=0

$managedDisks = Get-AzureRmDisk foreach ($md in $managedDisks) {
#リソースグループを指定しない場合は置き換える。
#if$md.ManagedBy -eq $null)

if($md.ManagedBy -eq $null| Where { $md.ResourceGroupName -eq $rgName }){

#削除の場合は1、確認だけの場合は0を指定

if($deleteUnattachedDisks -eq 1){

Write-Host “Deleting unattached Managed Disk with Id: $($md.Id)”

#確認メッセージを表示する場合は、-Forceを削除すること

$md | Remove-AzureRmDisk -Force

Write-Host “Deleted unattached Managed Disk with Id: $($md.Id) “

}else{

$md.Id

} } }

削除された場合は、以下のようなメッセージが表示されます。

Deleted unattached Managed Disk with Id: /subscriptions/”SubscriptionID”/resourceGroups/”RG名”/providers/Microsoft.Compute/disks/”Disk名”

2.使われていないAzure ネットワークインターフェースをまとめて削除するPower Shell

Managed Disksと同様に、使用されていないネットワークインターフェースの一覧の取得、削除を行ってみました。

接続先が存在しないネットワークインターフェースを使用されていないディスクとしています。

    • 対象リソースグループ名を指定する
    • 削除の場合は1を指定する。取得表示のみの場合は0を指定する。
    • 確認メッセージを表示する場合は-Forceを外してください。
#対象のRG名を指定
$rgName =“リソースグループ名”

$deleteNetworkIF=1

$NetworkIF = Get-AzureRmNetworkInterface foreach ($nic in $NetworkIF) {

#リソースグループを指定しない場合は、これに置き換える。
#if$nic.VirtualMachine -eq $null)

if($nic.VirtualMachine -eq $null| Where { $nic.ResourceGroupName -eq $rgName }){

#削除の場合は1、確認だけの場合は0を指定

if($deleteNetworkIF -eq 1){

Write-Host “Deleting unattached Network Interface with Name: $($nic.name)”

#確認メッセージを表示する場合は、-Forceを削除すること

$md | Remove-AzureRmNetworkInterface -Force

Write-Host “Deleting unattached Network Interface with Name: $($nic.Name) “

}else{

$nic.Id

} } }

削除された場合は、以下のようなメッセージが表示されます。

Deleted unattached Managed Disk with Id: /subscriptions/”SubscriptionID”/resourceGroups/”RG名”/providers/Microsoft.Network/networkInterfaces/”ネットワークインターフェース名”