Azure Windows VM uzantısı hatalarında sorun giderme
Azure Resource Manager şablonlarına genel bakış
Azure Resource Manager şablonları, kaynaklar arasındaki bağımlılıkları tanımlayarak Azure IaaS altyapısını JSON dilinde bildirimli olarak belirtmenize imkan sağlar.
Uzantıları kullanmaya yönelik yazma şablonları hakkında daha fazla bilgi edinmek için bkz. Uzantı şablonları yazma.
Bu makalede, bazı yaygın VM uzantısı hatalarıyla ilgili sorunları gidermeyi öğreneceksiniz.
Uzantı durumunu görüntüleme
Azure Resource Manager şablonları Azure PowerShell'den yürütülebilir. Şablon yürütüldükten sonra uzantı durumu Azure Kaynak Gezgini'nden veya komut satırı araçlarından görüntülenebilir.
Aşağıda bir örnek verilmiştir:
Azure PowerShell:
Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status
Örnek çıktı şu şekildedir:
Extensions: {
"ExtensionType": "Microsoft.Compute.CustomScriptExtension",
"Name": "myCustomScriptExtension",
"SubStatuses": [
{
"Code": "ComponentStatus/StdOut/succeeded",
"DisplayStatus": "Provisioning succeeded",
"Level": "Info",
"Message": " Directory: C:\\temp\\n\\n\\nMode LastWriteTime Length Name
\\n---- ------------- ------ ---- \\n-a--- 9/1/2015 2:03 AM 11
test.txt \\n\\n",
"Time": null
},
{
"Code": "ComponentStatus/StdErr/succeeded",
"DisplayStatus": "Provisioning succeeded",
"Level": "Info",
"Message": "",
"Time": null
}
]
}
Uzantı hatalarını giderme
VM Aracısı'nın çalıştığını ve Hazır olduğunu doğrulayın
Uzantıları yönetmek, yüklemek ve yürütmek için VM Aracısı gereklidir. VM Aracısı çalışmıyorsa veya Azure platformuna Hazır durumunu bildiremiyorsa uzantılar düzgün çalışmaz.
VM Aracısı sorunlarını gidermek için lütfen aşağıdaki sayfalara bakın:
- Windows VM için Windows Azure Konuk Aracısı sorunlarını giderme
- Linux VM için Azure Linux Aracısı sorunlarını giderme
Belirli uzantı sorun giderme kılavuzunuzu denetleyin
Bazı uzantıların sorun gidermeyi açıklayan belirli bir sayfası vardır. Bu uzantıların ve sayfaların listesini Uzantı sorunlarını giderme sayfasında bulabilirsiniz.
Uzantının durumunu görüntüleme
Yukarıda açıklandığı gibi, Uzantının durumu PowerShell cmdlet'i çalıştırılarak bulunabilir:
Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status
veya CLI komutu:
az vm extension show -g <RG Name> --vm-name <VM Name> --name <Extension Name>
veya Azure portal, VM Dikey Penceresine / Ayarlara / Uzantılara göz atarak. Ardından uzantıya tıklayıp durumunu ve iletisini de kontrol edebilirsiniz.
Uzantıyı VM'de yeniden çalıştırma
Özel Betik Uzantısı'nı kullanarak VM'de betik çalıştırıyorsanız bazen VM'nin başarıyla oluşturulduğu ancak betiğin başarısız olduğu bir hatayla karşılaşabilirsiniz. Bu koşullar altında, bu hatadan kurtarmanın önerilen yolu uzantıyı kaldırmak ve şablonu yeniden çalıştırmaktır. Not: Gelecekte bu işlevsellik, uzantıyı kaldırma gereksinimini ortadan kaldıracak şekilde geliştirilecektir.
Uzantıyı Azure PowerShell'den kaldırma
Remove-AzVMExtension -ResourceGroupName $RGName -VMName $vmName -Name "myCustomScriptExtension"
Uzantı kaldırıldıktan sonra, betikleri VM'de çalıştırmak için şablon yeniden yürütülebilir.
VM'ye yeni bir GoalState tetikleme
Bir uzantının yürütülmediğini veya eksik bir "Windows Azure CRP Sertifika Oluşturucu" nedeniyle yürütülediğini fark edebilirsiniz (bu sertifika, uzantının korumalı ayarlarının aktarımını güvenli hale getirmek için kullanılır). Bu sertifika, Sanal Makinenin içinden Windows Konuk Aracısı yeniden başlatılarak otomatik olarak yeniden oluşturulur:
- Görev Yöneticisi'ni açma
- Ayrıntılar sekmesine gidin
- WindowsAzureGuestAgent.exe işlemini bulma
- Sağ tıklayın ve "Görevi Sonlandır"ı seçin. İşlem otomatik olarak yeniden başlatılır
Ayrıca bir "VM Yeniden Uygulaması" yürüterek VM'ye yeni bir GoalState tetikleyebilirsiniz. VM Reapply , bir VM'nin durumunu yeniden uygulamak için 2020'de kullanıma sunulan bir API'dir. Bunu, kısa bir VM kapalı kalma süresini tolere edebildiğiniz bir zamanda yapmanızı öneririz. Reapply'nin kendisi VM'nin yeniden başlatılmasına neden olmasa da ve çoğu zaman Reapply çağrısının VM'yi yeniden başlatmaması durumunda, Reapply yeni bir hedef durumu tetiklediğinde VM modelinde bekleyen başka bir güncelleştirmenin uygulanması ve diğer değişikliklerin yeniden başlatılmasının gerekmesi çok küçük bir risktir.
Azure portal:
Portalda VM'yi seçin ve sol bölmede Destek + sorun giderme'nin altında Yeniden dağıt + yeniden uygulama'yı ve ardından Yeniden uygulama'yı seçin.
Azure PowerShell (RG Adı ve VM Adı değerleriniz ile değiştirin):
Set-AzVM -ResourceGroupName <RG Name> -Name <VM Name> -Reapply
Azure CLI (RG Adı ve VM Adı değerleriniz ile değiştirin):
az vm reapply -g <RG Name> -n <VM Name>
"VM Yeniden Uygulama" işe yaramadıysa, Azure Yönetim Portalı'ndan VM'ye yeni bir boş Veri Diski ekleyebilir ve ardından sertifika geri eklendikten sonra kaldırabilirsiniz.
VM'nin içindeki uzantı günlüklerine bakın
Önceki adımlar işe yaramadıysa ve uzantınız hala başarısız durumdaysa, sonraki adım Sanal Makine içindeki günlüklerine bakmaktır.
Windows VM'sinde uzantı günlükleri genellikle
C:\WindowsAzure\Logs\Plugins
Uzantı ayarları ve durum dosyaları
C:\Packages\Plugins
Bir Linux VM'sinde uzantı günlükleri genellikle
/var/log/azure/
Uzantı ayarları ve durum dosyaları
/var/lib/waagent/
Her uzantı farklıdır ancak genellikle benzer ilkelere uyar:
Uzantı paketleri ve ikili dosyalar VM'ye indirilir (örn. Linux için "/var/lib/waagent/custom-script/download/1" veya Windows için "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads\0" ).
Yapılandırmaları ve ayarları Azure Platformu'ndan VM Aracısı aracılığıyla uzantı işleyicisine geçirilir (örneğin. Linux için "/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/config" veya Windows için "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\RuntimeSettings" )
VM'nin içindeki uzantı işleyicileri bir durum dosyasına yazıyor (örneğin. Linux için "/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/status/1.status" veya "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status" (Windows için C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status) daha sonra Azure Platformu'na bildirilecektir. Bu durum PowerShell, CLI veya Azure portal VM'nin uzantı dikey penceresinde bildirilen durumdur.
Ayrıca yürütmelerinin ayrıntılı günlüklerini de yazar (örn. Linux için "/var/log/azure/custom-script/handler.log" veya Windows için "C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log" ).
VM mevcut bir VM'den yeniden oluşturulursa
Başka bir Azure VM'den gelen özelleştirilmiş bir Diski temel alan bir Azure VM oluşturuyor olabilirsiniz. Bu durumda, eski VM'de uzantılar olabilir ve bu nedenle ikili dosyalar, günlükler ve durum dosyaları kalır. Yeni VM modeli, önceki VM'nin uzantı durumlarını fark etmez ve bu uzantılar için yanlış bir durum bildirebilir. Yenisini oluşturmadan önce uzantıları eski VM'den kaldırmanızı ve yeni VM oluşturulduktan sonra bu uzantıları yeniden yüklemenizi kesinlikle öneririz. Aynı durum, mevcut bir Azure VM'sinden genelleştirilmiş bir görüntü oluşturduğunuzda da oluşabilir. Uzantılardan tutarsız durumdan kaçınmak için sizi uzantıları kaldırmaya davet ediyoruz.
Bilinen sorunlar
PowerShell iç veya dış komut olarak tanınmıyor
RunCommand uzantısının çıkışında aşağıdaki hata girişlerini fark edeceksiniz:
RunCommandExtension failed with "'powershell' isn't recognized as an internal or external command,"
Analiz
Uzantılar Yerel Sistem hesabı altında çalıştığından, VM'de RDP yaptığınızda powershell.exe düzgün çalışıyor ancak RunCommand ile çalıştırıldığında başarısız oluyor olabilir.
Çözüm
- PowerShell'in PATH ortam değişkeninde düzgün listelendiğinden emin olun:
- Denetim Masası'nı açın
- Sistem ve Güvenlik
- Sistem
- Gelişmiş sekmesi -> Ortam Değişkenleri
- 'Sistem değişkenleri' altında Düzenle'ye tıklayın ve PowerShell'in PATH ortam değişkeninde olduğundan emin olun (genellikle: "C:\Windows\System32\WindowsPowerShell\v1.0")
- VM'yi yeniden başlatın veya WindowsAzureGuestAgent hizmetini yeniden başlatın, ardından Çalıştır Komutunu yeniden deneyin.
Komut iç veya dış komut olarak tanınmıyor
C:\WindowsAzure\Logs\Plugins<ExtensionName><Version>\CommandExecution.log dosyasında aşağıdakileri görürsünüz:
Execution Error: '<command>' isn't recognized as an internal or external command, operable program or batch file.
Analiz
Uzantılar Yerel Sistem hesabı altında çalıştığından, VM'de RDP yaptığınızda powershell.exe düzgün çalışıyor ancak RunCommand ile çalıştırıldığında başarısız oluyor olabilir.
Çözüm
- VM'de bir Komut İstemi açın ve hatayı yeniden oluşturmak için bir komut yürütür. VM Aracısı Yönetici cmd.exe kullanır ve cmd her başlatıldığında yürütülecek önceden yapılandırılmış bir komutunuz olabilir.
- Path değişkeninizin yanlış yapılandırılmış olması da olasıdır, ancak bu sorun yaşayan komuta bağlıdır.
VMAccessAgent, Yönetici hesabı için Uzak Masaüstü Bağlantısı ayarları güncelleştirilemiyor ile başarısız oluyor. Hata: System.Runtime.InteropServices.COMException (0x800706D9): Uç nokta eşleyiciden başka uç nokta yok.
Uzantının durumunda aşağıdakileri görürsünüz:
Type Microsoft.Compute.VMAccessAgent
Version 2.4.8
Status Provisioning failed
Status level Error
Status message Cannot update Remote Desktop Connection settings for Administrator account. Error: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9) at NetFwTypeLib.INetFwRules.GetEnumerator() at
Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktopFirewallRules()
at Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktop() at
Analiz
Bu hata, Windows Güvenlik Duvarı hizmeti çalışmadığında oluşabilir.
Çözüm
Windows Güvenlik Duvarı hizmetinin etkin ve çalışır durumda olup olmadığını denetleyin. Değilse, lütfen etkinleştirin ve başlatın; ardından VMAccessAgent'ı çalıştırmayı yeniden deneyin.
Doğrulama yordamına göre uzak sertifika geçersiz.
WaAppAgent.log dosyasında aşağıdakileri görürsünüz
System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.
Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
Analiz
Sanal makinenizde büyük olasılıkla "Güvenilen Kök Sertifika Yetkilileri" içinde Baltimore CyberTrust Kök sertifikası eksiktir.
Çözüm
certmgr.msc ile sertifikalar konsolunu açın ve sertifikanın orada olup olmadığını denetleyin.
Bir diğer olası sorun, sertifika zincirinin ZScaler gibi bir üçüncü taraf SSL Denetleme aracı tarafından bozulmasıdır. Bu tür bir araç SSL denetimini atlayacak şekilde yapılandırılmalıdır.