KVM, Xen ve LXC farkları: VPS altyapısı nasıl anlaşılır?

VPS planınızın gerçekte ne sunduğu

KVM, Xen ve LXC, bir VPS planının üzerine inşa edildiği üç sanallaştırma ailesidir ve bu seçim, sağlayıcının kabinindeki bir detaydan ibaret değildir. Bu seçim, kendi çekirdeğinize (kernel) sahip olup olmayacağınızı belirler. Bir alıcının önemsediği her şey bu tek gerçeğe dayanır: modül yükleme, swap kontrolü, iç içe sanallaştırma (nested virtualisation) çalıştırma, /proc ifadesinin sizin sunucunuzu mu yoksa başkasınınkini mi tanımladığı ve steal time değerinin ölçülebilir olup olmadığı.

Tam sanallaştırma (KVM ve Xen HVM), her kiracıya bir çekirdek ve bir sanal makine sağlar. Paravirtualized Xen de size bir çekirdek sunar, ancak bu çekirdek bir konuk olduğunun farkındadır ve ayrıcalıklı işlemleri gerçekleştirmesi için hipervizöre başvurur. Bir konteyner planı (LXC veya OpenVZ ve Virtuozzo serisi) ise size bir dosya sistemi ve sağlayıcının çekirdeği üzerinde bir dizi isim alanı (namespace) sağlar. Her üçü de aynı üç harf altında satılmaktadır.

KVM ve Xen ile LXC karşılaştırması: çekirdek başına bir sistem mi, paylaşımlı çekirdek mi

KVM ve Xen üzerinde uname -r kendi çekirdeğinizi tanımlar. Farklı bir çekirdek kurabilir, içine modül yükleyebilir ve sistemi bu çekirdek ile yeniden başlatabilirsiniz. Burada yaptığınız hiçbir işlem başka bir kiracıyı etkilemez. Konteyner planında ise uname -r, ana makinede çalışan ve o makinedeki diğer tüm konteynerlerle paylaşılan sağlayıcı çekirdeğini tanımlar. Bu çekirdeği değiştiremezsiniz; apt install linux-image-generic ise asla önyüklenmeyecek dosyaları açacaktır.

Bu tek fark, herhangi bir teknik özellik listesinden daha değerlidir. Bu kılavuzun geri kalanını, bu farkın bir sonucu olarak okuyun.

Tam sanallaştırma: KVM ve Xen HVM

KVM (kernel-based virtual machine), Linux çekirdeği içinde yer alan ve CPU üzerinde yerleşik olarak bulunan Intel VT-x veya AMD-V komut setlerini kullanarak standart bir Linux sunucusunu hipervizöre dönüştüren bir modüldür. QEMU, bu yapının çevresindeki disk, ağ kartı ve seri konsol gibi sanal donanımları sağlar. Xen ise farklı bir tasarıma sahiptir. Xen kendi başına bir hipervizördür ve Linux'tan önce önyükleme yapar. Yönetim yığınını çalıştıran dom0 adlı ayrıcalıklı bir kontrol etki alanı bulunur ve her kiracı bir domU olarak tanımlanır. Xen HVM (hardware virtual machine), KVM ile aynı CPU uzantılarını kullanır; ancak emüle edilen donanımlar yavaş olduğu için genellikle disk ve ağ için paravirtual sürücülerden yararlanır. Bu kombinasyona PVHVM adı verilir.

Bir kiracı açısından her iki yapı da neredeyse aynı şekilde davranır. Bir çekirdek, bir önyükleyici, gerçek bir blok aygıtı, çalışan bir modprobe, gerçek bir /proc, size özel bir takas alanı (swap) ve gerçekten yeniden başlatma gerçekleştiren bir sistem elde edersiniz. Eğer sağlayıcı bir ISO dosyası bağlamanıza izin veriyorsa, sunulmayan bir dağıtımı bile kurabilirsiniz.

Bu esnekliğin bedeli yoğunluktur. 4 GB belleğiniz makinenize tahsis edilmiştir ve siz boşta beklerken komşunuza ödünç verilemez; ayrıca her konuk sistem kendi QEMU sürecini, kendi sayfa tablolarını ve kendi sayfa önbelleğini taşır. KVM planlarının, aynı kaynak değerlerini gösteren konteyner planlarından daha yüksek fiyatlandırılmasının nedeni bu maliyettir.

Paravirtualized Xen ve bunu nasıl tanıyacağınız

Xen PV, işlemcilerin sanallaştırma komut setlerine sahip olmadığı dönemde ortaya çıkmıştır. Ayrıcalıklı komutları yakalamak yerine, konuk çekirdek doğrudan hipervizörü çağıracak şekilde değiştirilir. VT-x olmadan çalışır; 2005 yılındaki temel amaç da buydu. Çekirdek, kendi disk imajınızın içinden pygrub veya pvgrub tarafından yüklenir; yani çekirdek size aittir ancak PV konuk desteğiyle derlenmiş olması gerekir.

Bu yapıda olduğunuzun işaretleri şunlardır: lscpu, sanallaştırma türünü full yerine para olarak raporlar, /sys/hypervisor/type mevcuttur ve Xen adını taşır, diskleriniz ise vda veya sda yerine xvda olarak görünür. SMBIOS veya DMI tablolarını okuyan araçlar hiçbir veri bulamaz; çünkü bir PV konuğunun bunları yayınlayacak bir aygıt yazılımı (firmware) yoktur.

Bunun size maliyeti, kalıcı olarak iç içe sanallaştırmadan (nested virtualization) mahrum kalmanızdır. Bir PV konuğuna hiçbir zaman işlemci sanallaştırma uzantıları gösterilmez, bu nedenle içinde başka bir hipervizör çalışamaz. Xen'in kendisi ölü değildir. Özellikle Xen PV, popülerliğini yitiren kısımdır ve projenin kendi yönelimi PVH ve HVM'ye kaymıştır. Eğer bir plan "Xen" ifadesini kullanıyorsa, hangisi olduğunu sorun. HVM, modern ve standart bir VPS'tir. PV ise daha düşük fiyatlandırmanız gereken bir plandır.

Container VPS: LXC ve OpenVZ hattı

Container VPS, sağlayıcının çekirdeği üzerinde çalışan bir Linux namespace (süreç kimlikleri, mount noktaları, ağ arayüzleri, ana makine adı ve kullanıcıların ayrı görünümleri) ve cgroup (kontrol grupları, çekirdeğin kaynak sınırları) kümesidir. init, ana makine üzerinde bir süreçtir. ls, herhangi bir emülasyon veya ikinci bir zamanlayıcı olmadan doğrudan ana makinenin çekirdeği üzerinde çalışır. Container yapılarının hızlı ve yoğun olmasının nedeni budur.

Sipariş sayfasındaki isimler LXC, Proxmox VE container (LXC tabanlıdır), OpenVZ ve Virtuozzo'dur. OpenVZ 7 ve Virtuozzo, aynı fikrin ticari devamlarıdır.

Sizin için dört şey değişir:

• Modüller. modprobe herhangi bir modül yükleyemez. Eğer WireGuard, ZFS veya belirli bir netfilter modülü sağlayıcının çekirdeğinde halihazırda yoksa, bunları kullanamazsınız.
• sysctl. /proc/sys kısmının çoğu salt okunurdur. Ağ yönetimi gerçek bir namespace olduğundan, net.ipv4.ip_forward ve komşuları genellikle yazılabilirdir. vm.swappiness veya fs.file-max gibi makine genelindeki ayarlar ana makineye aittir.
• İç içe container yapıları. LXC container içinde Docker kullanımı, yalnızca sağlayıcı nesting özelliğini etkinleştirdiğinde ve depolama sürücüsü uyumlu olduğunda çalışır. Varsaymak yerine satın almadan önce test edin.
• Çekirdek sürümü. Yeniden başlatmalar dahil olmak üzere, sağlayıcının güncelleme takvimine tabi olursunuz.

Hangi sürümü satın aldığınızı anlama

Bu komutları sunucu üzerinde çalıştırın ve yanıtları birlikte değerlendirin. Tek bir komut kesin sonuç vermez.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt, sabit bir sözlükten kısa bir tanımlayıcı yazdırır. Makine tarafı kvm, qemu, xen, amazon ve vmware değerlerini içerir. Konteyner tarafı ise lxc, lxc-libvirt, openvz, docker ve systemd-nspawn değerlerini içerir. Herhangi bir tespit yapamadığında none çıktısını verir ve sıfırdan farklı bir hata koduyla sonlanır. -c formu yalnızca konteyner teknolojileri için yanıt verir; bu nedenle orada none dışında herhangi bir yanıt alınması, satış sayfasında ne yazarsa yazsın konuyu netleştirir.

lscpu, hipervizör sağlayıcısının adını belirtir ve sanallaştırma türünün tam (full) mı yoksa yarı (para) mı olduğunu bildirir; Xen HVM ile Xen PV arasındaki ayrım bu şekilde yapılır. /sys/hypervisor/type yalnızca Xen altında mevcuttur.

/lib/modules kontrolü, insanların atladığı ancak en doğrudan sonuç veren yöntemdir. Sistem o çekirdek üzerinde çalışıyor olmasına rağmen, çalışan çekirdek sürümüne ait dizin eksik veya boşsa, çekirdek sizin dosya sisteminizden gelmiyor demektir. Çekirdek ana makineden (host) gelmiştir ve modül ağacı imajınıza hiçbir zaman kurulmamıştır. Bu bir konteynerdir.

Bağımsız bir ikinci görüş için sudo apt install -y virt-what && sudo virt-what, tespit testlerini özel bir araç olarak çalıştırır. Root yetkisi gerektirir ve fiziksel sunucularda (bare metal) hiçbir çıktı vermez.

Neden /proc bir container içinde yanlış makineyi tanımlar

Bir KVM veya Xen konuğunda, /proc/meminfo, hipervizörün size tahsis ettiği belleğin kendi çekirdeğiniz tarafından tutulan muhasebesidir. Bu değer kendi makineniz için doğrudur ve ana makine (host) hakkında hiçbir bilgi vermez. Sanal makinenin amacı da budur.

Bir container içinde bu muhasebeyi yapan ikinci bir çekirdek yoktur, bu nedenle /proc, ana makinenin /proc değeridir. LXCFS, bu dosyaların bazılarını cgroup limitlerinizle eşleşecek şekilde yeniden yazan küçük bir dosya sistemidir ve /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats ve /sys/devices/system/cpu/online dosyalarını kapsar. Proxmox bunu varsayılan olarak mount eder. Birçok küçük sağlayıcı bunu yapmaz; bu durumda free -m ana makinenin toplam belleğini raporlar, nproc makinedeki her çekirdeği raporlayabilir ve uptime ana makinenin ne kadar süredir çalıştığını raporlar.

Bu durum sadece kozmetik değildir, çünkü yazılımlar boyutlarını bu dosyalara bakarak belirler. worker_processes auto kullanan nginx, görebildiği çekirdek sayısını sayar. 64 çekirdekli bir ana makinede 2 çekirdek kotası ile çalışan make -j$(nproc), 64 derleyici başlatır. MemTotal üzerinden önbellek boyutunu seçen bir JVM veya veritabanı, cgroup'unuzun reddedeceği bir değer seçer ve limit aşıldığında çekirdek süreci sonlandırır. Bu sonlandırma işlemi, okuyamayacağınız ana makine çekirdek günlüğüne kaydedilir.

Yetkili değerler /proc içinde değil, cgroup içindedir:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

Bunlar, güncel dağıtımların kullandığı cgroup v2 yollarıdır. max dosyasını okurken görülen memory.max, o seviyede bir limit belirlenmediği anlamına gelir. cpu.max, mikrosaniye cinsinden bir kota ve periyot yazdırır; dolayısıyla 200000 100000, her periyot için iki çekirdekli CPU süresi anlamına gelir. Daha eski bir cgroup v1 ana makinesinde aynı değerler /sys/fs/cgroup/memory/memory.limit_in_bytes ve /sys/fs/cgroup/cpu/cpu.cfs_quota_us altında bulunur.

Swap ve gerçek sahibi

KVM ve Xen üzerinde swap alanı size aittir. Bu alan diskinizdeki bir dosya veya bölüntüdür (partition) ve sayfalama (paging) işlemini çekirdeğiniz yönetir.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

swapon --show komutu artık dosyayı boyutu ve önceliğiyle listelemelidir. Eğer swapon dosyayı kabul etmezse, bunun yerine dd if=/dev/zero of=/swapfile bs=1M count=2048 ile oluşturun; çünkü yazılmamış kapsamları (extents) olan önceden ayrılmış dosyalar bazı dosya sistemlerinde reddedilir. /swapfile none swap sw 0 0 satırını /etc/fstab dosyasına ekleyin, aksi takdirde swap alanı bir sonraki yeniden başlatmadan sonra kaybolur.

Konteynerlerde bunların hiçbiri size ait değildir. swapon yetkisiz bir konteynerin sahip olmadığı bir yeteneğe ihtiyaç duyar, bu nedenle kendi swap dosyanızı oluşturma girişimi izin hatası nedeniyle başarısız olur ve diske asla ulaşmaz. Planın swap olarak adlandırdığı şey, ana makine (host) üzerindeki bir cgroup ayarıdır; cgroup v2 altında memory.swap.max olarak geçer ve ana makinenin kendi swap aygıtları tarafından desteklenir. Eski OpenVZ planları, diskten ziyade ani yük kredisine (burst credit) daha yakın davranan bir "vswap" kotası satardı. Üst sınırı okuyabilirsiniz ancak altındaki aygıtı kontrol edemezsiniz.

İç içe sanallaştırma ve yanıltıcı CPU bayrağı

İç içe sanallaştırma (nested virtualisation), VPS'niz içinde bir hipervizör çalıştırmak anlamına gelir: bir QEMU konuğu, bir Vagrant kutusu veya kendi sanal makinelerine sahip bir iç içe sanallaştırma laboratuvarı. İki koşulun aynı anda sağlanması gerekir. Sağlayıcının ana makinede (host) iç içe sanallaştırmayı etkinleştirmesi ve konuğunuza CPU'nun sanallaştırma uzantılarını göstermesi şarttır.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

İç içe sanallaştırmanın etkin olduğu bir KVM konuğunda /dev/kvm mevcuttur ve kvm-ok, hızlandırmanın kullanılıp kullanılamayacağını açıkça rapor eder. Xen HVM üzerinde bu teknik olarak mümkündür ancak nadiren sunulur. Xen PV üzerinde ise bu gerçekleşemez.

Bir konteyner içinde bu kontrol, öğretici bir şekilde başarısız olur. /proc/cpuinfo ana makinenin dosyasıdır, bu nedenle vmx veya svm bayrağı mevcuttur ve bu bayrak gerçekten doğrudur: altınızdaki fiziksel CPU bu komut setlerine gerçekten sahiptir. Ancak bu yine de size ait değildir. İsim alanınızda (namespace) /dev/kvm yoktur, kvm_intel modülünü yükleyemezsiniz ve okuduğunuz bayrak, kontrol ettiğiniz bir makineyi değil, konuğu olduğunuz makineyi tanımlar. Bu, genel kuralın en net örneğidir. Bir konteyner içinde /proc, sahip olduğunuz bir sunucuyu değil, isim alanını ve çevresindeki donanımı tanımlar.

AES-NI ve planınızın sunduğu CPU özellikleri

AES-NI (advanced encryption standard new instructions), AES şifrelemesini yazılım tabanlı hesaplamalara göre birkaç kat daha hızlı hale getiren bir CPU komut setidir. TLS termination, disk şifreleme, SSH ve yedekleme süreçlerinin tamamı bu komut setine dayanır.

KVM üzerinde, sanal makinenizin gördüğü özellikler, sağlayıcının QEMU için yapılandırdığı CPU modeli tarafından belirlenir. Host passthrough kullanıldığında gerçek bayrakları (flags) görürsünüz. qemu64 gibi genel bir model veya misafir makinelerin farklı donanımlar arasında taşınabilmesi için kasten seçilmiş eski bir temel yapılandırma kullanıldığında, aes bayrağı eksik olabilir ve OpenSSL sessizce yazılım tabanlı yola geri döner.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

Üçüncü komut, OpenSSL kılavuzunda bu komutların kütüphane içerisinde devre dışı bırakılmasına dair örnektir: AES-NI bitini ve VAES bitini temizler, geri kalanına dokunmaz. İki çıktı değerini karşılaştırın. Eğer birbirlerine yakın çıkarlarsa, hızlı yol zaten kullanılmıyor demektir ve bir plana taahhüt vermeden önce bir VPS üzerinde AES-NI kontrolünü doğru şekilde yapmak için harcayacağınız beş dakikaya değer.

Bir container'ın önünde herhangi bir CPU modeli bulunmaz, bu nedenle /proc/cpuinfo içerisindeki bayraklar ana makinenin gerçek bayraklarıdır ve doğrudan size uygulanır. Bu, container planlarının gerçek bir avantajıdır ve paylaşımlı çekirdeğin (shared kernel) sizin lehinize çalıştığı bu kılavuzdaki tek noktadır.

Steal time değerinin kaynağı ve container yapılarında neden bulunmadığı

Steal time, sanal CPU'nuzun çalışmaya hazır olduğu ancak hypervisor başka bir işi yürüttüğü için çalışamadığı süredir. Bu değer st içerisinde top ve vmstat olarak, /proc/stat dosyasındaki cpu satırının sekizinci alanı olarak görünür.

Bir konuk sistem, bu süreyi kendi başına ölçemez; çünkü süre çalındığı sırada sistem yürütme yapmamaktadır. Hypervisor'ın bu bilgiyi iletmesi gerekir. KVM, toplam süreyi konuğun paravirtual clock arayüzü aracılığıyla kaydettiği bir sayfaya yazar; Xen ise aynı iş için her vCPU başına bir çalışma durumu alanı tutar. Okuduğunuz sayı, hypervisor'ın kendi beyanıdır; bu nedenle mevcuttur ve güvenilirdir.

Yüksek steal değeri, ana makinenin (host) aşırı yüklendiğini ve komşularınızın o an meşgul olduğunu gösterir. Bu değer, satılan vCPU sayısı ile fiziksel çekirdekler arasındaki oranın görünür yüzüdür ve gürültülü komşuyu tespit etmek için steal time okuma yöntemi, bir planın vaat ettiği kapasiteyi gerçekten sunup sunmadığını anlamanızı sağlayan tek ölçümdür.

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

Bir container içerisinde bu sütun değişmeyecektir; çünkü sizinle zamanlayıcı (scheduler) arasında bir hypervisor bulunmaz. Süreçleriniz, ana makinenin kendi CPU zamanlayıcısında sıradan görevler olarak diğer tüm kiracıların süreçleriyle birlikte kuyruğa girer. Çekişme (contention), işlerin sadece daha uzun sürmesiyle kendini belli eder ve nedenini belirten bir sayaç bulunmaz. Bunun en yakın karşılığı kota kısıtlamasıdır (quota throttling): Sağlayıcı cpu.max değerini ayarladığında, /sys/fs/cgroup/cpu.stat aracı nr_throttled periyotlarını ve bir sonraki kota penceresini beklerken harcanan throttled_usec mikrosaniyeyi sayar. Bu yalnızca kendi kotanızı kapsar, komşulardan kaynaklanan rekabeti asla içermez. Bir uyarı: Eğer sağlayıcının container ana makinesi kendisi de bir sanal makine ise, /proc/stat içerisinde bir steal değeri görünebilir; ancak bu değer size değil, o ana makineye aittir.

Aşırı satış (overselling) ve container planlarının neden daha ucuz olduğu

Dürüst cevap kısadır. Bir container planı daha az maliyetlidir çünkü sağlayıcı, aynı makineyi daha fazla kişiyle paylaşmaktadır.

Bellek, farkın en çok açıldığı noktadır. Bir KVM misafirinin RAM'i ona tahsis edilmiştir; bu nedenle 256 GB belleğe sahip bir ana makine, sistem yükü (overhead) düşüldükten sonra yaklaşık 256 GB'lık misafir satar. Bir container'ın bellek sınırı ise bir rezervasyondan ziyade bir tavan değeridir. Bir container'ın kullanmadığı bellek, diğerleri için anında kullanılabilir hale gelir. Bu sayede sağlayıcı, toplamı fiziksel RAM'in birkaç katına ulaşan limitler satabilir ve çoğu zaman bu durum sorunsuz işler. Burada sahte bir durum yoktur. Yeterli sayıda kiracı aynı anda yoğunlaşana kadar sistem çalışır; o noktadan sonra ise herkes için performans düşer.

CPU, KVM dahil her plan türünde, çekirdek sayısından daha fazla vCPU satılarak aşırı satılır. Disk ise neredeyse her yerde ince yapılandırma (thin provisioning) ile sunulur. Container'lar bunun üzerine ekstra yoğunluk ekler: tek bir çekirdek, tek bir sayfa önbelleği (page cache) ve misafir başına QEMU süreci olmaması sayesinde bir ana makine, çok daha fazla kiracıyı barındırabilir.

Burada feragat ettiğiniz şey izolasyondur ve bu, korkutma amaçlı bir hikaye değil, gerçek bir mühendislik takasıdır. Aynı çekirdeği paylaşırsınız; bu nedenle bir çekirdek hatası ortak bir sorundur ve bir container'dan kaçış doğrudan ana makineye erişim sağlar. Bir sanal makineden kaçmak ise çok daha küçük ve çok daha zor bir hedef olan bir hipervizör hatası gerektirir. Ayrıca sağlayıcının çekirdek yükseltme ve yeniden başlatma takvimine de tabi olursunuz. Bunlardan herhangi biri sizin için önemliyse, yalnızca fiyata göre karar vermeden önce VPS barındırmanın gerçekte ne kadar güvenli olduğu konusunu okuyun.

Hangisi satın alınmalı

Kendi çekirdeğinize (kernel) ihtiyaç duyduğunuzda KVM satın alın: WireGuard veya ZFS modülleri, belirli bir çekirdek sürümü, iç içe sanallaştırma (nested virtualisation), swap üzerinde gerçek kontrol veya bir denetçiye açıklayabileceğiniz bir sınır gerekiyorsa bu yöntem tercih edilmelidir. Bütçe dahilinde standart servisleri çalıştırıyorsanız, sağlayıcının çekirdeği güncelse ve bağımlı olduğunuz özelliklerin çekirdeğe halihazırda derlenmiş olduğunu doğruladıysanız bir container planı satın alın. Xen HVM'yi çoğu amaç için KVM ile eşdeğer kabul edin; hala Xen PV olarak satılan herhangi bir ürünü satın almadan önce ise mutlaka sorgulayın.

İki yapı bu ayrımın dışında kalır. Firecracker microVM yapıları, her kiracıya bir container'a yakın başlatma maliyetiyle gerçek bir çekirdek sunar; serverless platformlarının çalışma mantığı budur. Incus sistem container yapıları, container modelini kontrolünüz altındaki donanımda kendiniz çalıştırmanıza olanak tanır; bu, size satılan bir hizmeti kullanmaktan farklı bir konumdur. Eğer terminoloji kafa karıştırıyorsa, bir VPS'in gerçekte ne olduğu ve VPS, VM ve VPC arasındaki fark başlıklı içerikler, bu rehberin halihazırda bildiğinizi varsaydığı terimleri kapsamaktadır.

FAQ

VPS'imin KVM mi yoksa container mı olduğunu nasıl anlarım?

systemd-detect-virt -c komutunu çalıştırın. none dışındaki her türlü yanıt, planın adı ne olursa olsun bir container içinde olduğunuz anlamına gelir. Algılama yöntemleri yanıltılabileceği için durumu iki farklı yolla daha doğrulayın. lscpu bir hipervizör satıcısının adını belirtir ve sanallaştırma türünün tam (full) mu yoksa yarı (para) mı olduğunu gösterir. ls /lib/modules/$(uname -r) bir container üzerinde eksik veya boştur; çünkü çalışan çekirdek ana makineden (host) gelir ve modül ağacı dosya sisteminize hiçbir zaman kurulmamıştır. sudo virt-what, yalnızca bu soru için yazılmış bir araçtan bağımsız bir yanıt verir.

Neden free -m, planımın içerdiğinden çok daha fazla bellek gösteriyor?

LXCFS mount edilmemiş bir container planındasınız; bu nedenle /proc/meminfo ana makinenin dosyasıdır ve free ana makinenin belleğini olduğu gibi raporlamaktadır. Gerçek sınırınız cgroup'tur. Sınırı görmek için /sys/fs/cgroup/memory.max, mevcut kullanımı görmek için /sys/fs/cgroup/memory.current veya daha eski bir cgroup v1 ana makinesinde /sys/fs/cgroup/memory/memory.limit_in_bytes dosyasını okuyun. Önbellek veya işçi havuzu boyutlandıran her türlü servisi, free yerine bu değer üzerinden yapılandırın.

LXC VPS üzerinde Docker veya WireGuard çalıştırabilir miyim?

Bazen çalıştırabilirsiniz, ancak bu sizin kurduğunuz bir şeye bağlı değildir. Her ikisi de sağlayıcının çekirdeğine bağımlıdır çünkü çekirdeğe modül yükleyemezsiniz. WireGuard, modül ana makinede zaten mevcutsa ve size sunulmuşsa çalışır; modül mevcut değilse kullanıcı alanı (userspace) wireguard-go uygulaması yedek seçenek olarak kullanılır. Docker, sağlayıcının iç içe yerleştirmeye (nesting) izin vermesini ve container içinde çalışan bir depolama sürücüsüne sahip olmasını gerektirir. Satın almadan önce sorun veya kolayca vazgeçebileceğiniz bir dönemde test edin.

Container VPS'im neden hiçbir zaman steal time raporlamıyor?

Steal time yalnızca bir hipervizör sanal bir CPU'yu zamanladığında mevcuttur ve hipervizör bu rakamı çekirdeğinizin okuduğu bir sayfaya yazdığı için raporlanır. Bir container'ın altında hipervizör yoktur. Süreçleriniz ana makinenin zamanlayıcısındaki sıradan görevlerdir; bu nedenle çekişme (contention), işaret edecek bir sayaç olmaksızın her şeyin daha uzun sürmesi şeklinde kendini gösterir. Bunun yerine /sys/fs/cgroup/cpu.stat dosyasını okuyun: nr_throttled ve throttled_usec, cgroup'unuzun bir sonraki CPU kota penceresini bekleyerek geçirdiği süreyi sayar; bu, bir container'ın sahip olduğu steal time kavramına en yakın değerdir.