VPS uzerinde Proxmox ve nested virtualization kurulumu

Kısa cevap

İç içe sanallaştırma (nested virtualization), bir sanal makine içerisinde çalışan hipervizördür: VPS'niz zaten bir konuk sistemdir ve siz onun üzerinde kendi konuklarınızı çalıştırmak istersiniz. Bu özellik, yalnızca sağlayıcınızın hipervizörü CPU'nun sanallaştırma uzantılarını örneğinize kasıtlı olarak açtığında çalışır; /proc/cpuinfo içerisinde vmx bayrağını (Intel için) veya svm (AMD için) kontrol edin. Eğer bunlardan hiçbiri görünmüyorsa, VPS içerisinde yapacağınız hiçbir yapılandırma sorunu çözmeyecektir.

Öncelikle bir beklenti yönetimi: Docker için bunların hiçbirine gerek yoktur. Konteynırlar VPS çekirdeğinizi paylaşır ve asla /dev/kvm ile etkileşime girmez. Eğer asıl amaç "sunucumda konteynırlar üzerinde birkaç servis çalıştırmak" ise, zaten ihtiyacınız olan her şeye sahipsiniz demektir. İç içe sanallaştırma; ikinci bir çekirdek, Proxmox laboratuvarı, Windows konuk sistemi, Firecracker microVM'leri, Android emülatörü, gerçek sanal makinelerden oluşan bir Kubernetes test ortamı veya sanal makine imajlarını boot eden CI çalıştırıcıları istediğinizde önem kazanır.

Aslında ne iç içe geçirilmektedir

Üç katman mevcuttur:

• L0, sağlayıcının fiziksel donanım üzerindeki hipervizörü. Buna erişiminiz yoktur.
• L1, sizin VPS'iniz. L0 için bu sadece bir konuktur.
• L2, VPS'inizin içinde çalıştırmak istediğiniz sanal makinedir.

Donanım sanallaştırması, Intel tarafında VT-x (vmx bayrağı) ve EPT, AMD tarafında ise AMD-V / SVM (svm) ve RVI/NPT birleşimidir. Bir hipervizör, bu komutları konuk moduna girmek ve CPU'nun aynı anda iki sayfa tablosunu işlemesini sağlamak için kullanır.

Hiçbiri tekrar girilebilir (re-entrant) olacak şekilde tasarlanmadığından, iç içe geçirme emüle edilir: L1, VMLAUNCH veya VMRESUME gibi bir VMX komutu çalıştırdığında, bu komut L0'a takılır (trap) ve L0, L1 adına L2 için gölge yapıları yönetir. VMCS shadowing özelliğine sahip CPU'larda, L1'in VMREAD ve VMWRITE komutları bir çıkış (exit) gerçekleşmeden karşılanabilir; bu durum trafiğin büyük kısmını ortadan kaldırsa da geri kalanını etkilemez. KVM bunu başarılı bir şekilde yapar, ancak her çıkışta L0 fazladan işlem yükü altına girer; sağlayıcının bu özelliği isteğe bağlı sunmasının nedeni budur.

L0 katmanında KVM kullanıldığında, hızlandırılmış bir L2 için iki koşulun aynı anda sağlanması gerekir:

1. L0'ın KVM modülü nested=1 parametresi ile yüklenmiş olmalıdır.
2. L0, VPS'inize bu bayrağı taşıyan bir CPU modeli vermelidir; bu ayar libvirt içinde <cpu mode='host-passthrough'/>, Proxmox içinde cpu: host, ham QEMU içinde ise -cpu host ile yapılır. Genel bir emüle edilmiş model (qemu64, kvm64), iç içe geçirme küresel olarak açık olsa bile vmx özelliğini gizler.

Diğer hipervizörlerin kendi anahtarları vardır. Örneğin Hyper-V, sanal makineleri içindeki iç içe geçmiş bir hipervizör için sanallaştırma uzantılarını emüle eder, ancak bu yalnızca iç içe geçirme özelliğinin tek tek etkinleştirildiği sanal makinelerde çalışır.

VPS durumunuzu bir dakikada kontrol edin

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

Kullanılabilir bir örnek vmx veya svm çıktısı verir, kvm-ok komutu KVM acceleration can be used değerini döndürür ve /dev/kvm dosyası root:kvm modunda 660 olarak mevcuttur. Eğer bayrak mevcut ancak aygıt düğümü yoksa, modülü manuel olarak yükleyin ve çekirdek günlüğünü okuyun:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

Bir dosya sürekli alıntılanır ve yaygın olarak yanlış yorumlanır:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

VPS'nizin içinde yer alan bu ayar sizin KVM modülünüzün ayarıdır ve bir L2 konuğun üçüncü bir seviyeyi iç içe çalıştırıp çalıştıramayacağını yönetir. L0 katmanının sizin için iç içe sanallaştırmayı etkinleştirip etkinleştirmediği hakkında hiçbir bilgi vermez; bu sorunun cevabını /proc/cpuinfo ve kvm-ok verir. nested parametresi, tamamen size ait olan bir makinede ayarladığınız kontrol düğmesidir:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

Bir VM çalışırken modülün kaldırılmasına izin verilmez; bu nedenle önce guest sistemler kapatılmalıdır. Bu makine bir Proxmox host ise Proxmox VE 9 üzerinde nested virtualization etkinleştirme başlığında aynı modprobe.d değişikliği ve flag'in guest içinde görünür olmasını sağlayan VM başına cpu: host ayarı açıklanır.

Çoğu VPS sağlayıcısının bu özelliği neden kapalı tuttuğu

• Canlı taşıma (Live migration). Size vmx sunmak, bu bayrağı taşıyan bir CPU modelini dışa açmak anlamına gelir. Bu CPU özelliklerine bağımlı olan bir konuk sistem, bu özelliklere sahip olmayan bir makineye güvenli bir şekilde taşınamaz. Müşterilerini başka düğümlere taşıyarak boşaltma yapan bir ana makine, iç içe sanallaştırmayı (nesting) etkinleştirdiği anda bu yeteneğini kaybeder.
• Saldırı yüzeyi. İç içe geçmiş VMX/SVM yolları, çekirdeğin sanallaştırma katmanındaki en karmaşık kodlar arasındadır ve buna uygun bir CVE geçmişine sahiptir.
• L0 katmanı KVM olmayabilir. Eğer systemd-detect-virt komutu vmware, xen veya microsoft çıktısını veriyorsa, geçerli olan iç içe sanallaştırma kuralları KVM'nin değil, ilgili yığının kurallarıdır.

Örneğinizde bayrak görünmüyor mu? Destek ekibiyle görüşün (bazı sağlayıcılar bunu VM bazında etkinleştirir), iç içe sanallaştırmayı belgeleyen bir plan seçin veya fiziksel bir sunucuya geçin. Bu kılavuzun geri kalanı, bayrağı gösteren bir makinede root yetkisine sahip olduğunuz varsayımıyla hazırlanmıştır.

libvirt ile L2 konuk çalıştırma

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

Grafiksel bir oturuma gerek yoktur. Seri kurulum bir süre devam eder, bu nedenle kurulumu kalıcı bir kabuk içinde başlatın: Claude Code oturumlarını bir VPS üzerinde canlı tutan tmux iş akışı, bir SSH bağlantısı koptuğunda virt-install konsolunun bağlı kalmasını sağlar. Eğer --os-variant debian13 reddedilirse, osinfo-db sürümünüz yayın öncesine aittir; osinfo-query os komutunu çalıştırın ve mevcut bir isim seçin. --cpu host-passthrough, vmx trafiğini L2 içine iletir; bu yalnızca L2'nin de sanallaştırma yapması gerekiyorsa gereklidir. virsh autostart guest1 ile konuğun güvenli bir şekilde önyüklenmesini sağlayın.

Disk ve NIC üzerindeki virtio veri yolu bir süs değildir: öykünülmüş IDE ve e1000 aygıtları, hipervizöre virtio kuyruklarından çok daha sık takılır. İç içe sanallaştırma altında, L0'ın kendi başına tamamlayamadığı bir çıkış işlemi L1'e yansıtılır; burada bu işlemin yönetilmesi, kendi başına yeni çıkışları tetikleyebilir.

Ağ yönetimi: eğitimlerin atladığı kısım

VPS'niz tek bir genel IP adresine sahiptir ve bilinmeyen MAC adreslerini filtreleyen bir ağ yapısının arkasında yer alır. Bu durum iki sonucu beraberinde getirir.

L2 misafirlerini genel ağa köprülemek (bridging) genellikle çalışmaz. Genel ağ arayüzüne br0 yerleştirip misafir sisteme kendi MAC adresini atarsanız, ARP isteklerinin dışarı çıktığını ancak hiçbir yanıt gelmediğini görürsünüz; sağlayıcının anahtarı (switch), kendisine kiralanmamış bir MAC adresinden gelen çerçeveleri (frame) düşürür. Belirtiniz buysa, köprü yapılandırmasında hata ayıklamayı bırakın; mekanizma bu şekildedir.

Bunun yerine NAT ağını kullanın. libvirt, default ile birlikte gelir: virbr0, 192.168.122.0/24, dnsmasq kiralamaları ve hemen çalışan dışa dönük bağlantılar. Gelen trafik için TLS sonlandırmasını L1 katmanında yapın ve proxy ile içeri aktarın; aşağıdaki sertifika yolları Nginx üzerinde Certbot ile Let's Encrypt sertifikası oluşturma rehberinden alınmıştır:

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Öncelikle misafir sisteme statik bir kiralama (virsh net-edit default) atayın, böylece proxy_pass içindeki adres sabit kalır.

Yönetim arayüzlerini internete kapalı tutun: 5900 portundaki VNC ve 8006 portundaki Proxmox web arayüzü loopback üzerinde kalmalıdır. Bunlara bir SSH tüneli (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) üzerinden veya VPS'ye self-hosted WireGuard VPN ile erişin; bu yöntem tüm 192.168.122.0/24 misafir ağını tek bir özel sıçrama (hop) mesafesine getirir. Güvenlik duvarını dar tutun, sadece sudo ufw allow 22,80,443/tcp açık kalsın. Eğer ufw'yi etkinleştirdikten hemen sonra misafir sistemler dışa dönük bağlantılarını kaybederse, bunun yaygın nedeni /etc/default/ufw içindeki DEFAULT_FORWARD_POLICY="DROP" ayarıdır; bunu ACCEPT olarak ayarlayın ve ufw'yi yeniden yükleyin.

VPS üzerinde Proxmox

Proxmox VE 9 temelinde Debian 13 barındırır, bu nedenle Debian tabanlı bir VPS üzerine kurulumu pve-no-subscription deposu ve proxmox-ve paketi eklenerek gerçekleştirilir. Depo ve anahtarlık satırlarını Proxmox'un güncel dokümantasyonundan alın; eski bir blog gönderisinden kopyalanan URL kurulumun başarısız olmasına neden olur. Proxmox'un kiralanmış bir donanım üzerinde çalıştırılmasının mantıklı olup olmadığı, aşağıdaki ağ yapılandırmasına vakit harcamadan önce değerlendirilmelidir; evdeki bir Proxmox sunucusu ile kiralanmış bir VPS arasındaki maliyet ve yetenek karşılaştırması, güç ve donanım hesaplamaları önceden yapılmış bir analiz sunar.

Paketlerin kurulumu zor kısım değildir. Proxmox, fiziksel bir ağ kartına (NIC) köprülenmiş bir vmbr0 yapısı bekler, bu da yukarıda bahsedilen MAC filtreleme engeline takılır. VPS üzerinde çalışan yapı, fiziksel bir porta bağlı olmayan NAT'lı veya yönlendirmeli bir vmbr0, özel bir IP aralığında çalışan konuk makineler ve herkese açık servisler için ana makine üzerinde DNAT kuralları veya bir reverse proxy kullanımıdır. Halka açık servisler VM yerine container olarak çalışıyorsa, tek bir Docker Compose dosyası üzerinden birden fazla uygulamayı yöneten Traefik, otomatik sertifikalarla aynı yönlendirme işini görür. İşleme başlamadan önce /etc/network/interfaces ile snapshot alın: hatalı bir köprü tanımı, konsol erişiminizin olmayabileceği bir makinede kilitli kalmanıza neden olabilir.

Performans, dürüst bir bakış

İç içe sanallaştırma, tek seviyeli sanallaştırmadan daha yavaştır ve bu mekanizmanın etkisi yaygın değil, spesifiktir: maliyet, sıradan komutlarda değil, çıkış işlemlerinde (exits) ve adres çevriminde ortaya çıkar. EPT/NPT mevcut olduğunda, L0, L2'nin sayfa tablolarını ve kendi tablolarını tek bir gölge tabloda birleştirir; böylece TLB isabeti donanım hızında gerçekleşir. TLB ıskalaması ise daha maliyetlidir: donanım, konuk işletim sisteminin sayfa tablosu ile gölge tabloyu birlikte tarar ve L1'in kendi tablolarında yaptığı her değişiklik, L0'ın gölge tabloyu yeniden eşitleyebilmesi için bir çıkış işlemini zorunlu kılar. Konuk modundan çıkış gerektiren her işlem; G/Ç, zamanlayıcı kesmeleri, MMIO ve işlemciler arası kesmeler maliyetlidir, çünkü L2 çıkışı L0 tarafından işlenir ve L1 üzerinden geri yansıtılması gerekebilir. Küçük bir çalışma kümesi üzerinde CPU ağırlıklı işler yerel performansa yakın sonuçlar verir; büyük bellek içi çalışma kümeleri TLB ıskalamaları nedeniyle yavaşlar ve sistem çağrıları, paket trafiği veya disk G/Ç işlemleriyle yoğunlaşan her süreç katmanların etkisini hissettirir.

Bu nedenle: her yerde virtio aygıtlarını kullanın. Ayrıca qcow2 dosyanız, sağlayıcının halihazırda sanallaştırdığı bir disk üzerinde yer alıyorsa, iki ince provizyon (thin-provisioning) katmanı üst üste binmiş olur; bu durumda konuk diskindeki cache=none kullanımı, aynı blokların iki farklı sayfa önbelleğinde aynı anda tutulmasını engeller. Burada herhangi bir kıyaslama verisi sunulmamıştır: kendi iş yükünüzü kendi örneğiniz üzerinde ölçün.

Hata modları ve karşılaşacağınız dizgeler

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used, kvm-ok kaynağından. Modül yüklenmemiş veya bayrak (flag) dışa aktarılmamış olabilir. Öncelikle /proc/cpuinfo kontrol edilmelidir.

dmesg içinde kvm: disabled by bios. Fiziksel sunucularda (bare metal), firmware üzerinden VT-x/SVM ayarını etkinleştirin. Bir VPS içinde bu durum, L0 katmanının size bu uzantıları sağlamadığı anlamına gelir; konuk (guest) sistemde yapacağınız hiçbir değişiklik bunu düzeltmeyecektir.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. Çekirdeğinizin gördüğü işlemci vmx özelliğine sahip değildir; bu yine bir L0 kararıdır.

Could not access KVM kernel module: Permission denied. Donanım değil, izin sorunudur. ls -l /dev/kvm, kvm grubunu ve 660 modunu göstermelidir; kendinizi bu gruba ekleyin ve yeni bir oturum kabuğu başlatın, çünkü grup üyeliği halihazırda çalışan oturumlara uygulanmaz.

QEMU başlarken kvm: Device or resource busy. Başka bir hipervizör modülü işlemciyi tutmaktadır: lsmod komutunu çalıştırın, kvm_intel yanında vboxdrv veya VMware modüllerini arayın ve istemediğiniz modülü kaldırın.

virsh kaynağından /var/run/libvirt/libvirt-sock: No such file or directory. Servis (daemon) çalışmıyor: sudo systemctl enable --now libvirtd komutunu kullanın.

Proxmox: KVM virtualisation configured, but not available. Bir konuk sistem, KVM hızlandırmasını sağlayamayan bir ana makinede (host) bu özelliği etkinleştirmiştir. İç içe sanallaştırmayı (nesting) düzeltin veya özelliği devre dışı bırakıp emülasyonu kabul edin.

Android emulator: x86_64 emulation currently requires hardware acceleration! Yine /dev/kvm durumu; genellikle grup izinleri ile ilgilidir.

Hiçbir hata yok ancak her şey çok yavaş. Hızlandırıcı bayrağı olmayan QEMU, yazılım emülatörü olan TCG'ye geri döner. Doğru çalışır ancak yavaştır; saniyeler süren bir önyükleme süreci dakikalar sürmeye başlar. -accel kvm bayrağını açıkça belirtin; böylece QEMU sessizce emülasyon yapmak yerine bir hata ile duracaktır.

Konuk sistem çalışma sırasında kayboluyor. dmesg içinde Out of memory: Killed process ... qemu-system-x86_64 ifadesini arayın. Bir L2 konuğu, L1 üzerinde bir süreçtir (process) ve OOM killer onu diğer süreçler gibi değerlendirir. L2 belleği, L1'in sabit tahsisinden karşılanır; ana makineden ödünç alma yapılmaz.

İşletim: yedeklemeler, yükseltmeler, sınırlar

Yedeklemeler. Çalışan bir konuğun qcow2 dosyasını kopyalamak, konuk siz okuma yaparken yazmaya devam ettiği için tutarsız bir imaj riski taşır. Ya virsh shutdown guest1 komutunu çalıştırıp virsh domstate guest1 aracının shut off raporunu vermesini bekleyin (kapatma komutu konuk henüz dururken dönebilir) ve ardından kopyalayın; ya da harici bir snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) alın; böylece yazma işlemleri bir overlay dosyasına yönlendirilirken siz statik hale gelen ana dosyayı kopyalayabilir ve ardından virsh blockcommit guest1 vda --active --pivot ile birleştirebilirsiniz. Kopyaları VPS dışına taşıyın; aynı disk üzerindeki bir snapshot hiçbir şeye karşı koruma sağlamaz.

Yükseltmeler. apt full-upgrade yeni kvm_intel/kvm_amd modüllerini kurar, ancak çalışan çekirdek siz yeniden başlatana kadar eskilerini tutmaya devam eder. Önceki çekirdeği kurulu tutun ve her çekirdek değişikliğinden sonra kvm-ok komutunu yeniden çalıştırın: vmx olmadan açılan bir ana makine, çalışan bir duruma dönmek için sadece bir önyükleme girdisi uzağınızdadır.

Ölçeklemenin bittiği yer. Tek bir genel IP adresi, her L2 servisinin dünyaya bir proxy veya L1 üzerindeki bir DNAT kuralı aracılığıyla ulaştığı anlamına gelir. Canlı taşıma (live migration) seçenekler arasında değildir. CPU çekişmesi durumunda, iç içe geçmiş çıkış yolu (nested exit path) bunu ilk hisseden kısımdır. Birkaç konuğa sahip bir hipervizör, RAM'ini halihazırda harcamış olduğunuz bir makinedir; iç içe geçmiş sanal makineler sabit bir tahsisatın ötesine geçerek aşırı taahhütte (overcommit) bulunamazlar. Bir laboratuvar bu yapıyı aştığında, çözüm daha yüksek bir iç içe geçmiş yığın değildir; L0 olduğunuz ve bunların hiçbirinin geçerli olmadığı özel bir fiziksel sunucudur.

FAQ

Docker'ı bir VPS üzerinde çalıştırmak için iç içe sanallaştırmaya (nested virtualization) ihtiyacım var mı?

Hayır. Konteynerler VPS çekirdeğinizi paylaşır ve asla /dev/kvm açmazlar; bu nedenle vmx veya svm bayrağı olmayan standart bir örnek, Docker ve Docker Compose'u sorunsuz çalıştırır. İç içe sanallaştırma yalnızca ikinci bir çekirdeğe ihtiyaç duyduğunuzda gereklidir: Proxmox laboratuvarı, Windows konuk işletim sistemi, Firecracker microVM'ler, Android emülatörü veya VM imajlarını önyükleyen CI çalıştırıcıları gibi.

VPS'imin iç içe sanallaştırmayı destekleyip desteklemediğini nasıl kontrol ederim?

grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u komutunu, ardından cpu-checker paketinden kvm-ok komutunu çalıştırın. Kullanılabilir bir örnek vmx (Intel) veya svm (AMD) çıktısı verir, kvm-ok komutu KVM acceleration can be used raporlar ve /dev/kvm dosyası kvm grubu ve 660 modu ile mevcuttur. Bu soru için /sys/module/kvm_intel/parameters/nested dosyasını dikkate almayın; bu dosya sağlayıcının hipervizörünün size sunduğu özellikleri değil, kendi KVM modülünüzü tanımlar.

Çoğu VPS sağlayıcısı neden iç içe sanallaştırmayı devre dışı bırakır?

vmx özelliğini sunmak, konuğa bu bayrağı taşıyan bir CPU modeli vermek anlamına gelir. Bu CPU özelliklerine bağımlı olan bir konuk, bu özelliklere sahip olmayan bir makineye canlı olarak taşınamaz (live-migration). Müşterilerini taşıyarak düğümleri boşaltan bir sağlayıcı bu yetenekten vazgeçmiş olur. Ayrıca iç içe VMX/SVM kod yolları uzun bir CVE geçmişine sahiptir. Bazı barındırma sağlayıcıları bunu talep üzerine VM bazında etkinleştirir, bazıları ise iç içe sanallaştırmayı bir plan özelliği olarak belgeler.

İç içe sanallaştırılmış VM'imin genel köprüde (public bridge) ağı yok. Sorun nedir?

Sağlayıcının anahtarı, kendisine kiralamadığınız bir MAC adresinden gelen çerçeveleri düşürür. Bu nedenle genel NIC üzerine köprülenmiş bir L2 konuğu ARP gönderir ancak yanıt alamaz. br0 üzerinde hata ayıklamayı bırakın, libvirt'in NAT default ağını (virbr0, 192.168.122.0/24) kullanın, konuğa statik bir kiralama atayın ve genel erişime açık her şeyi VPS'in kendisi üzerinde bir reverse proxy veya DNAT kuralı aracılığıyla yayınlayın.

İç içe sanallaştırılmış bir VM ne kadar yavaştır?

Maliyet, VM çıkışlarına ve adres çevrimine yansır. EPT/NPT etkin olduğunda, L2 içindeki komutlar ve TLB isabetleri donanım hızında çalışır. Ancak bir TLB ıskalaması (miss) fazladan sayfa tablolarını tarar; G/Ç, zamanlayıcı kesmeleri, MMIO ve IPI'lar L0 tarafından işlenir ve L1 üzerinden geri döndürülebilir. Küçük bir çalışma kümesi üzerindeki CPU yoğun işler yerel hıza yakın görünür; büyük bellek içi çalışma kümeleri ile sistem çağrısı, paket ve disk yoğun iş yükleri her katmanı hissettirir. Her yerde virtio aygıtlarını ve konuk disklerinde cache=none kullanın, ardından kendi iş yükünüzü ölçün.