DEV Community

Cover image for VMware’den Proxmox’a Taşıdığım Windows 0x7B Verdi: VirtIO SCSI Çözümü
Hakan İSMAİL
Hakan İSMAİL

Posted on

VMware’den Proxmox’a Taşıdığım Windows 0x7B Verdi: VirtIO SCSI Çözümü

Bu yazıda VMware'de kurulmuş bir Windows Server 2022 VM'ini Proxmox'a taşırken takıldığım bir yeri ve nasıl çözdüğümü yazıyorum.

Baştan söyleyeyim: bunu kendi ortamımda, öğrenirken yaptım. Sektörde çalışan biri değilim, yani "sahada böyle yapılır" demiyorum. Ben böyle çözdüm, şunları denedim, şunları bilmiyorum diyorum.

Ne oldu

VM'i VMware Workstation'da kurmuştum. Ayarları şöyleydi:

  • VMware Workstation 26.0.1.25688693
  • UEFI
  • 2 vCPU, 8 GB RAM
  • 60 GB disk (.vmdk, tek dosya)
  • Kontrolcü: VMware PVSCSI (Paravirtualized SCSI), disk tipi SCSI

VMware Tools kuruluydu ve VM VMware üzerinde hiçbir sorun çıkarmadan çalışıyordu. ESXi'dan taşınan VM'lerde de aynı hatayı yaşayanlar var (Kaynaklar'daki Windows OS Hub yazısı bunlardan biri), ben Workstation'da kurduğum VM ile denedim.

VMware üzerinde çalışan Windows Server 2022: servisler, aygıt yöneticisi ve yüklü programlar

Bu VM'i Proxmox'a geçireceğim. Önce VM'i kapatıp diski scp ile Proxmox'un /var/tmp klasörüne kopyaladım:

❯ scp "/home/<kullanıcı>/vmware/Windows Server 2022/Windows Server 2022.vmdk" root@<proxmox-ip>:/var/tmp/ws2022-source.vmdk
root@<proxmox-ip>'s password:
Windows Server 2022.vmdk                                          100%   11GB 130.7MB/s   01:25
Enter fullscreen mode Exit fullscreen mode

Sonra bu diski bir VM'e import edeceğim, ama önce o VM'i hazırlayalım:

Proxmox'ta hazırladığım boş VM'in donanım ayarları

Burada SCSI kontrolcüsünün ve ağ kartının VirtIO olması şimdilik fark etmiyor, çünkü Windows'un bulunduğu diski SATA olarak import edeceğim.

Diski import edelim:

root@pve-a:~# qm disk import 103 /var/tmp/ws2022-source.vmdk nfs-shared --format vmdk --target-disk sata0
importing disk '/var/tmp/ws2022-source.vmdk' to VM 103 ...
Formatting '/mnt/pve/nfs-shared/images/103/vm-103-disk-0.vmdk', fmt=vmdk size=64424509440 compat6=off hwversion=undefined
transferred 0.0 B of 60.0 GiB (0.00%)
transferred 614.4 MiB of 60.0 GiB (1.00%)
.
.
.
transferred 60.0 GiB of 60.0 GiB (100.00%)
sata0: successfully imported disk 'nfs-shared:103/vm-103-disk-0.vmdk'
Enter fullscreen mode Exit fullscreen mode

Boot diski olarak ayarlayıp VM'i başlatalım:

root@pve-a:~# qm set 103 --boot order=sata0
update VM 103: -boot order=sata0
root@pve-a:~# qm start 103
Enter fullscreen mode Exit fullscreen mode

Bu haliyle sorunsuz açıldı. Ekranda tek sorun VMware Tools hatası. Bu normal, çünkü VM artık QEMU üzerinde çalışıyor ve ana disk SATA kontrolcüsünün arkasında.

Proxmox'ta açılan Windows'ta VMware Tools hatası

VirtIO SCSI kontrolcüsü şu an boşta. VM'i kapatıp ana diski SCSI'ya taşıyınca şu mavi ekranı aldım:

0x7B mavi ekranı

0x0000007B  INACCESSIBLE_BOOT_DEVICE
Enter fullscreen mode Exit fullscreen mode

Diski SATA'ya geri alınca VM yine normal açıldı. Yani disk sağlam, sorun Windows'un o kontrolcü üzerinden diske ulaşamaması.

Kontrolcüyü VMware PVSCSI yapınca da VM açılıyor. Büyük ihtimalle PVSCSI sürücüsü VMware Tools'tan geldiği için, bunu doğrulamadım. Ama VirtIO, Proxmox'un (QEMU'nun) kendi paravirtualized kontrolcüsü ve genel öneri bu yönde, o yüzden ona geçmek istedim. Performans farkını ölçmedim.

Neden oluyor (anladığım kadarıyla)

Windows boot sırasında disk sürücüsünü çok erken yüklemek zorunda. Bunu da registry'deki Services altında Start=0 (boot-start) olarak işaretlenmiş servis kayıtlarına bakarak yapıyor. SATA ve LSI gibi kontrolcülerin sürücüleri Windows'la birlikte geldiği için onlarda sorun yok. VirtIO SCSI sürücüsü (vioscsi) ise Windows'ta hazır gelmiyor, benim VM'de de hiç kurulmamıştı.

Beni yanıltan şey pnputil /add-driver oldu:

pnputil /add-driver D:\vioscsi\w10\amd64\vioscsi.inf /install
Enter fullscreen mode Exit fullscreen mode

Çıktı "Driver package added successfully" diyor ama bu sürücüyü sadece driver store'a koyuyor. Services\vioscsi kaydı oluşmuyor. Kayıt, Windows cihazı gerçekten görüp sürücüyü kurunca yazılıyor. Cihaz yoksa kayıt da yok.

Standart çözüm: kurtarma ortamından DISM

Aramaya başlayınca çıkan ilk yöntem bu: VM'i Windows kurulum ISO'sundan kurtarma ortamında (WinRE/WinPE) açıp sürücüyü diskteki kapalı Windows'a enjekte etmek. Daha önce başka bir VM'de bunu yaptım ve çalıştı. Ama bir kez yapınca neden ilk tercihim olmadığını da gördüm, çünkü iş tek komut değil:

  1. VM'e Windows kurulum ISO'sunu ve virtio-win ISO'sunu birlikte bağla, boot sırasını değiştir, kurulum ekranından kurtarma komut satırına gir.
  2. diskpart ile list disk çalıştır. İlk başta büyük ihtimalle disk görünmez, çünkü WinPE de VirtIO kontrolcüsünü tanımıyor.
  3. Sürücü ISO'sunun hangi harfi aldığını bul (wmic logicaldisk get caption, volumename).
  4. drvload ile vioscsi.inf'i WinPE'ye yükle. Klasörde .sys ve .cat dosyaları eksikse bu adım hata veriyor.
  5. diskpart'ı tekrar çalıştır, artık Windows diskini görmen lazım. Windows'un kurulu olduğu bölümün harfini bul. Bu harf C: olmayabilir, bazı anlatımlarda E: kullanılıyor. Harf atanmamışsa kendin atamak gerekiyor.
  6. dism /image:<harf>:\ /add-driver /driver:...\vioscsi.inf ile sürücüyü offline imaja ekle.
  7. Bazı anlatımlarda bunun yetmediği, offline registry'yi yükleyip servisin Start değerini 0 yaptırmak gerektiği yazıyor. Ben bunu kendim doğrulamadım.
  8. wpeutil reboot ile çık, boot sırasını geri al, ISO'ları çıkar.

Bu adımlardan biri takılınca nerede hata olduğunu anlamak zor. Forumda DISM'i denemiş biri harf atama aşamasında takılmış, DISM hata vermiş, sonra yine açılmamış. Aynı kişide bir denemede offline kurulum başarılı olmuş, diğerinde olmamış.

Tek VM için bu kabul edilebilir. Birden fazla VM'de her biri için kurtarma ortamına boot etmek, ISO takıp çıkarmak, harfleri tek tek bulmak istediğim şey değildi. Bu yüzden VM'i çalışır halde bırakıp Windows'un sürücüyü kendisinin kurmasını sağlayan yolu aradım.

İlk denemem: registry'yi elle yazmak

Bir klonda Services\vioscsi altına elle Start=0 yazdım. Açılmadı, yine 0x7B. Sonradan fark ettim: anahtar sıfırdan oluşmuştu, içinde ImagePath, Group gibi değerler yoktu. "Start=0 var" demek hiçbir şey ispatlamıyordu.

Sonra başka bir klonda servis anahtarını, ImagePath, Group, ErrorControl değerlerini, vioscsi.sys dosyasını ve CriticalDeviceDatabase girdilerini elle yazdım. O da açılmadı. Nedenini bulamadım, eksik bir değer ya da yanlış bir eşleşme olabilir, ama doğrulamadım. Elle yazmayı bıraktım.

Çalışan yöntem

Proxmox forumunda da önerilen yol: VM'i SATA ile bir kez aç, VirtIO SCSI kontrolcüsüne bağlı geçici bir disk ekle, Windows cihazı gerçekten görüp sürücüyü kendisi kursun. Mantık, kayıtları ben yazmayacağım, Windows yazsın.

Kontrolcü tipi (scsihw) VM genelinde tek bir ayar. Ana disk PVSCSI'da kalıp geçici diski VirtIO'ya bağlayamıyorsun. İlk başta geçici diski PVSCSI kontrolcüsüyle ekledim, Windows VirtIO cihazını hiç görmedi. Ana diskin SATA'da olması bu yüzden gerekiyor.

1. ISO'yu bağla, geçici diski ekle, sürücüleri kur. Önce virtio-win ISO'sunu bağladım (ben 0.1.302 sürümünü kullandım):

qm set 103 --ide2 local:iso/virtio-win-0.1.302.iso,media=cdrom
Enter fullscreen mode Exit fullscreen mode

Proxmox arayüzünde virtio-win ISO'sunun CD/DVD sürücüsüne bağlanması

Sonra VM'e VM açıkken 1 GB'lık geçici bir SCSI disk ekledim. Bu disk VM'in VirtIO SCSI kontrolcüsüne bağlanıyor, Windows'un cihazı görmesi için gereken de bu.

VM'e eklenen 1 GB'lık geçici SCSI disk

VM içinde virtio-win yükleyicisini çalıştırdım:

virtio-win-guest-tools yükleyicisi

İstersek sadece SCSI sürücüsünün .inf dosyasını da kurabiliriz. Ben bu akışta yükleyiciyi kullandım:

pnputil /add-driver D:\vioscsi\w10\amd64\vioscsi.inf /install
Enter fullscreen mode Exit fullscreen mode

Yükleyici yeniden başlatma istedi, ama önce durumu kontrol ettim.

2. VM içinde kontrol et.

Get-PnpDevice -FriendlyName "*VirtIO SCSI*" | Select Status, FriendlyName
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\vioscsi" | Select Start, Group, ImagePath
Enter fullscreen mode Exit fullscreen mode

İlk çıktıda cihaz Error durumundaydı, ama servis kaydı artık doluydu (Start=0, Group=SCSI miniport, ImagePath=System32\drivers\vioscsi.sys). Problem kodunu sorguladım:

Get-PnpDevice -FriendlyName "*VirtIO SCSI*" | Get-PnpDeviceProperty DEVPKEY_Device_ProblemCode | Select Data
Enter fullscreen mode Exit fullscreen mode

Yeniden başlatmadan önce komut çıktıları

Kod 12 çıktı ("yeterli boş kaynak yok"). VM'i yeniden başlattım, cihaz OK oldu, kod 0'a düştü. Sebebini kesin bilmiyorum. Yükleyici zaten yeniden başlatma istiyordu, yani kurulum yarım kalmış olabilir. Diski VM açıkken eklemem de (sıcak ekleme) bir etken olabilir. İkisini ayırmak için diski VM kapalıyken ekleyip denemek gerekir, ben denemedim.

Yeniden başlattıktan sonra komut çıktıları

3. Kapat, geçici diski sil, ana diski scsi0'a al.

Önce qm config 103 ile hangi yuvanın hangi disk olduğuna bak. Benim VM'de geçici disk scsi0 yuvasındaydı, ana disk sata0'daydı:

qm config 103
qm set 103 --delete scsi0
qm set 103 --delete sata0
qm set 103 --scsi0 nfs-shared:103/vm-103-disk-0.vmdk
qm set 103 --boot order=scsi0
qm start 103
Enter fullscreen mode Exit fullscreen mode

--delete bir disk yuvasına verilince diski silmiyor, unused olarak ayırıyor. Ama sonradan unused bir diski arayüzde Remove edersen o disk gerçekten silinir. --delete sata0 sonrası ana disk de bir an unused oluyor, o yüzden disk adını kontrol etmeden bir şey silme.

VM VirtIO SCSI üzerinden sorunsuz açıldı. Geriye kalan unused geçici diski arayüzden temizledim.

Denediğim diğer şeyler

  • virtio-blk: Diski virtio0 yapıp denedim, direkt 0x7B aldım. virtio-blk ve virtio-scsi ayrı sürücüler (viostor ve vioscsi). Birini kurmak diğerini kurmuyor.
  • Offline DISM: Yukarıda anlattığım yöntem benim için çalıştı, ama her VM için kurtarma ortamına boot etmek gerekiyor, ben bu yüzden SATA yöntemini seçtim. Forumda bazı kullanıcılarda DISM yöntemi de açılmamış, yani garanti değil.
  • Sahte cihaz fikri: Cihaz gelmeden servis kaydını yazdırmak için pnputil /add-device ile sahte bir cihaz yaratmayı düşündüm. Server 2022'deki pnputil bu seçeneği tanımadı, orada bıraktım.
  • Sürücü klasörü: Ben w10\amd64 klasörünü kullandım. ISO'da 2k22 klasörü de var, Server 2022 için doğrusu muhtemelen o.
  • Kapsam: Sadece Windows Server 2022'de denedim. 2019, 2025 ya da Windows 10/11'de aynı olur mu bilmiyorum.

Önceden yapılabilecek olan

Taşımadan önce VirtIO sürücülerini VM'e kurmak bu sorunu büyük ihtimalle baştan önler, genel öneri de bu. Ben VM zaten taşınmış haldeyken karşılaştım. Forumda, VirtIO SCSI sürücüsünün bir SCSI disk takılı olmadan "önceden kurulamadığını" söyleyen yorumlar da var, yani temiz akış için bile geçici disk adımı gerekebilir.

Sonuç

VM artık VirtIO SCSI üzerinden açılıyor. Device Manager'da Red Hat VirtIO SCSI controller OK görünüyor, geçici disk silindi. Ağ sürücüsü de çalışır durumda.

Proxmox'ta çalışan VM'in Device Manager ekranı

Özetle yaptığım şey:

  1. Ana diski SATA'ya bağla, VM açılsın.
  2. SCSI kontrolcüsünü virtio-scsi-single yap (veya virtio-scsi).
  3. VM'e ikinci, geçici bir SCSI disk ekle (1 GB yeter).
  4. VM'i aç ve VirtIO sürücülerini yükle.
  5. VirtIO SCSI cihazının geldiğini kontrol et. Error görünüyorsa VM'i yeniden başlat.
  6. Cihaz OK ise VM'i kapat.
  7. Geçici diski sil, ana diski scsi0 olarak bağla, boot sırasını scsi0 yap.
  8. VM'i aç.

VMware'in sürücülerine de artık ihtiyaç yok.

Kaynaklar

Top comments (0)