KVM vs Xen vs LXC: आपका VPS कौन सा वर्चुअलाइजेशन है?

आपका VPS प्लान वास्तव में क्या बेच रहा है

KVM, Xen और LXC वे तीन वर्चुअलाइजेशन परिवार हैं जिन पर VPS प्लान आधारित होता है, और यह चुनाव प्रदाता के रैक का कोई मामूली विवरण नहीं है। यह तय करता है कि आपको अपना खुद का kernel मिलता है या नहीं। एक खरीदार जिन चीजों की परवाह करता है, वे सब इसी एक तथ्य से निकलती हैं: kernel modules लोड करना, swap को नियंत्रित करना, nested virtualisation चलाना, क्या /proc आपके सर्वर का वर्णन करता है या किसी और के, और क्या steal time को मापा जा सकता है।

Full virtualisation (KVM और Xen HVM) हर किराएदार को एक kernel और एक virtual machine देता है। Paravirtualised Xen भी आपको एक kernel देता है, लेकिन वह ऐसा kernel होता है जिसे पता होता है कि वह एक guest है और वह privileged कार्य करने के लिए hypervisor से अनुरोध करता है। एक container प्लान (LXC, या OpenVZ और Virtuozzo लाइन) आपको प्रदाता के kernel पर एक filesystem और namespaces का एक सेट देता है। ये तीनों एक ही तीन अक्षरों (VPS) के तहत बेचे जाते हैं।

KVM बनाम Xen बनाम LXC: प्रत्येक के लिए एक kernel या साझा kernel

KVM और Xen पर, uname -r आपके kernel का नाम निर्धारित करता है। आप एक अलग kernel install कर सकते हैं, उसमें module load कर सकते हैं, और उसे reboot कर सकते हैं। वहाँ आप जो भी करते हैं, उसका प्रभाव किसी अन्य tenant पर नहीं पड़ता। container plan पर, uname -r host पर चल रहे provider के kernel का नाम निर्धारित करता है, जो उस मशीन पर मौजूद हर दूसरे container के साथ साझा होता है। आप इसे बदल नहीं सकते, और apt install linux-image-generic ऐसी files को unpack करेगा जो कभी boot नहीं होंगी।

यह एक अंतर किसी भी spec sheet से अधिक महत्वपूर्ण है। इस guide के बाकी हिस्से को इसके परिणामों के रूप में पढ़ें।

Full virtualisation: KVM और Xen HVM

KVM (kernel-based virtual machine) Linux kernel के भीतर एक module है जो CPU में निर्मित Intel VT-x या AMD-V instructions का उपयोग करके एक सामान्य Linux host को hypervisor में बदल देता है। QEMU इसके चारों ओर virtual hardware प्रदान करता है: disk, network card, serial console। Xen एक अलग design है। Xen स्वयं एक hypervisor है और Linux के boot होने से पहले boot होता है। dom0 नामक एक privileged control domain management stack को चलाता है, और प्रत्येक tenant एक domU होता है। Xen HVM (hardware virtual machine) उन्हीं CPU extensions का उपयोग करता है जिनका KVM करता है, आमतौर पर disk और network के लिए paravirtual drivers के साथ, क्योंकि emulated hardware धीमा होता है। इस संयोजन को PVHVM कहा जाता है।

एक tenant के लिए, दोनों लगभग एक समान व्यवहार करते हैं। आपको एक kernel, एक bootloader, एक वास्तविक block device, एक कार्यशील modprobe, एक ईमानदार /proc, अपना स्वयं का swap, और एक ऐसा reboot मिलता है जो वास्तव में boot होता है। यदि provider आपको ISO attach करने की अनुमति देता है, तो आप एक ऐसा distribution install कर सकते हैं जिसे उन्होंने कभी offer नहीं किया था।

आप इसकी कीमत density के रूप में चुकाते हैं। आपका 4 GB आपकी machine के लिए आरक्षित होता है और जब आप idle होते हैं तो इसे किसी पड़ोसी को उधार नहीं दिया जा सकता है, और प्रत्येक guest के साथ एक QEMU process, उसकी अपनी page tables और उसका अपना page cache होता है। यही कारण है कि KVM plan की कीमत समान numbers दिखाने वाले container plan से अधिक होती है।

Paravirtualised Xen और इसे पहचानने का तरीका

Xen PV का विकास CPU में वर्चुअलाइजेशन निर्देश (virtualisation instructions) आने से पहले हुआ था। privileged निर्देशों को trap करने के बजाय, guest kernel को इस तरह संशोधित किया जाता है कि वह सीधे hypervisor को कॉल कर सके। यह बिना VT-x के चलता है, जो 2005 में इसका मुख्य उद्देश्य था। kernel को आपके अपने disk image के भीतर से pygrub या pvgrub द्वारा लोड किया जाता है, इसलिए यह आपका अपना kernel होता है, लेकिन इसे PV guest support के साथ build किया जाना अनिवार्य है।

इसके संकेतों को पहचानने का तरीका: lscpu वर्चुअलाइजेशन प्रकार को full के बजाय para के रूप में रिपोर्ट करता है, /sys/hypervisor/type मौजूद होता है और Xen का नाम दर्शाता है, और आपकी disks vda या sda के बजाय xvda होती हैं। SMBIOS या DMI tables को पढ़ने वाले tools को कुछ भी नहीं मिलता, क्योंकि PV guest के पास उन्हें प्रकाशित करने के लिए कोई firmware नहीं होता।

इसकी कीमत आपको nested virtualisation के रूप में चुकानी पड़ती है, जो इसमें स्थायी रूप से अनुपलब्ध है। एक PV guest को कभी भी CPU वर्चुअलाइजेशन एक्सटेंशन नहीं दिखाए जाते, इसलिए इसके अंदर कोई भी hypervisor नहीं चल सकता। Xen स्वयं समाप्त नहीं हुआ है। विशेष रूप से Xen PV वह हिस्सा है जो अब कम हो गया है, और प्रोजेक्ट की दिशा अब PVH और HVM की ओर मुड़ गई है। यदि कोई प्लान "Xen" का उल्लेख करता है, तो पूछें कि वह कौन सा प्रकार है। HVM एक सामान्य आधुनिक VPS है। PV एक ऐसा प्लान है जिसकी कीमत कम होनी चाहिए।

Container VPS: LXC और OpenVZ लाइन

Container VPS Linux namespaces (process IDs, mounts, network interfaces, hostname और users के अलग-अलग दृश्य) और cgroups (control groups, kernel की resource limits) का एक समूह है, जो provider के kernel पर चलता है। आपका init host पर एक process है। आपका ls सीधे host के kernel पर चलता है, जिसमें कोई emulation नहीं होता और बीच में कोई दूसरा scheduler नहीं होता। यही कारण है कि containers तेज और dense होते हैं।

Order page पर दिखने वाले नाम LXC, Proxmox VE containers (जो LXC ही हैं), OpenVZ और Virtuozzo हैं। OpenVZ 7 और Virtuozzo एक ही विचार के व्यावसायिक वंशज हैं।

आपके लिए चार चीजें बदल जाती हैं:

• Modules. modprobe कोई भी चीज़ insert नहीं करेगा। यदि WireGuard, ZFS या कोई विशिष्ट netfilter module provider के kernel में पहले से मौजूद नहीं है, तो आप उसे इस्तेमाल नहीं कर सकते।
• sysctl. /proc/sys का अधिकांश हिस्सा read-only होता है। Networking एक वास्तविक namespace है, इसलिए net.ipv4.ip_forward और इसके पड़ोसी आमतौर पर writable होते हैं। Machine-wide knobs जैसे कि vm.swappiness या fs.file-max host के अंतर्गत आते हैं।
• Nested containers. LXC container के अंदर Docker तभी काम करता है जब provider ने nesting को enable किया हो और storage driver सहयोग करे। इसे खरीदने से पहले test करें, न कि मान लें कि यह काम करेगा।
• Kernel version. आप provider के upgrade schedule को अपनाते हैं, जिसमें reboots भी शामिल हैं।

यह कैसे पता करें कि आपने क्या खरीदा है

इन commands को सर्वर पर चलाएं और उत्तरों का मिलान करें। कोई भी एक command अकेले यह स्पष्ट नहीं कर सकती।

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 एक निश्चित शब्दावली से एक छोटा पहचानकर्ता (identifier) प्रिंट करता है। मशीन साइड में kvm, qemu, xen, amazon और vmware शामिल हैं। कंटेनर साइड में lxc, lxc-libvirt, openvz, docker और systemd-nspawn शामिल हैं। जब यह कुछ भी डिटेक्ट नहीं करता है, तो यह none प्रिंट करता है और non-zero exit code के साथ बंद हो जाता है। -c फॉर्म केवल कंटेनर तकनीकों के लिए उत्तर देता है, इसलिए वहां none के अलावा कोई भी उत्तर इस प्रश्न का समाधान कर देता है, चाहे सेल्स पेज पर कुछ भी लिखा हो।

lscpu हाइपरवाइजर वेंडर का नाम बताता है और यह स्पष्ट करता है कि वर्चुअलाइजेशन का प्रकार full है या para, जिससे आप Xen HVM और Xen PV के बीच अंतर कर सकते हैं। /sys/hypervisor/type केवल Xen के अंतर्गत मौजूद होता है।

/lib/modules जांच वह है जिसे लोग छोड़ देते हैं, और यह सबसे सीधा तरीका है। यदि चल रहे kernel version के लिए डायरेक्टरी गायब है या खाली है, जबकि सिस्टम स्पष्ट रूप से उस kernel पर चल रहा है, तो kernel आपके filesystem से नहीं आया है। यह होस्ट से आया है, और इसका मॉड्यूल ट्री आपकी इमेज में कभी इंस्टॉल नहीं किया गया था। वह एक कंटेनर है।

एक स्वतंत्र दूसरी राय के लिए, sudo apt install -y virt-what && sudo virt-what डिटेक्शन टेस्ट को एक समर्पित टूल के रूप में चलाता है। इसे root की आवश्यकता होती है, और bare metal पर यह कुछ भी प्रिंट नहीं करता है।

कंटेनर में /proc गलत मशीन की जानकारी क्यों देता है

KVM या Xen guest पर, /proc/meminfo आपके अपने kernel द्वारा उस मेमोरी का हिसाब है जो hypervisor ने आपको दी है। यह आपकी मशीन के बारे में सही जानकारी है, और यह host के बारे में कुछ नहीं बताता। वर्चुअल मशीन का उद्देश्य ही यही है।

कंटेनर में ऐसा कोई दूसरा kernel नहीं होता जो यह हिसाब रखे, इसलिए /proc वास्तव में host का /proc होता है। LXCFS एक छोटा filesystem है जो इनमें से कुछ फाइलों को आपके cgroup limits के अनुसार फिर से लिखता है, और यह /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats तथा /sys/devices/system/cpu/online को कवर करता है। Proxmox इसे डिफ़ॉल्ट रूप से mount करता है। कई छोटे प्रदाता ऐसा नहीं करते, और तब free -m host की कुल मेमोरी रिपोर्ट करता है, nproc मशीन के सभी cores की जानकारी दे सकता है, और uptime यह बताता है कि host कितनी देर से चल रहा है।

यह केवल दिखावटी समस्या नहीं है, क्योंकि सॉफ्टवेयर इन फाइलों से ही अपना आकार निर्धारित करता है। nginx के साथ worker_processes auto उन cores की गिनती करता है जिन्हें वह देख सकता है। 64 core वाले host पर 2 core के कोटा के साथ make -j$(nproc) चलाने पर वह 64 compilers शुरू कर देता है। एक JVM या डेटाबेस जो MemTotal से cache size चुनता है, वह ऐसी संख्या चुन लेता है जिसे आपका cgroup अस्वीकार कर देगा, और limit तक पहुँचने पर kernel उस process को kill कर देता है। वह kill host के kernel log में दर्ज होता है, जिसे आप पढ़ नहीं सकते।

आधिकारिक संख्याएँ cgroup में होती हैं, न कि /proc में:

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

ये cgroup v2 paths हैं, जिनका उपयोग वर्तमान distributions करते हैं। memory.max द्वारा max पढ़ने का मतलब है कि उस स्तर पर कोई limit सेट नहीं है। cpu.max microseconds में कोटा और अवधि प्रिंट करता है, इसलिए 200000 100000 का अर्थ प्रति अवधि दो cores का CPU समय है। पुराने cgroup v1 host पर यही मान /sys/fs/cgroup/memory/memory.limit_in_bytes और /sys/fs/cgroup/cpu/cpu.cfs_quota_us के अंतर्गत होते हैं।

Swap, और इसका वास्तविक स्वामी कौन है

KVM और Xen पर, swap आपका होता है। यह आपकी डिस्क पर एक फाइल या पार्टीशन होता है, और आपका kernel ही paging का कार्य करता है।

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

swapon --show को अब फाइल को उसके आकार और प्राथमिकता के साथ सूचीबद्ध करना चाहिए। यदि swapon फाइल को स्वीकार नहीं करता है, तो इसे dd if=/dev/zero of=/swapfile bs=1M count=2048 के साथ बनाएँ, क्योंकि कुछ filesystems पर unwritten extents वाली preallocated फाइल को अस्वीकार कर दिया जाता है। /swapfile none swap sw 0 0 को /etc/fstab में जोड़ें, अन्यथा अगले reboot के बाद swap हट जाएगा।

Container में इनमें से कुछ भी आपका नहीं होता है। swapon को ऐसी capability की आवश्यकता होती है जो एक unprivileged container के पास नहीं होती है, इसलिए अपनी खुद की swap फाइल बनाने का प्रयास permission error के कारण विफल हो जाता है और डिस्क तक कभी नहीं पहुँचता है। जिसे plan में swap कहा जाता है, वह host पर एक cgroup setting है, जो cgroup v2 के अंतर्गत memory.swap.max है, और यह host के अपने swap devices द्वारा समर्थित होता है। पुराने OpenVZ plans में "vswap" allowance दी जाती थी जो डिस्क के बजाय burst credit की तरह अधिक व्यवहार करती थी। आप इसकी सीमा (ceiling) पढ़ सकते हैं। आप इसके अंतर्गत आने वाले device को नियंत्रित नहीं करते हैं।

Nested virtualisation और CPU flag जो धोखा देता है

Nested virtualisation का अर्थ है अपने VPS के भीतर एक hypervisor चलाना: जैसे एक QEMU guest, एक Vagrant box, या अपनी खुद की VMs वाला nested virtualisation lab। इसके लिए दो शर्तों का पूरा होना आवश्यक है। प्रदाता (provider) को host पर nesting सक्षम करनी चाहिए, और आपके guest को CPU के virtualisation extensions दिखाई देने चाहिए।

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

Nesting सक्षम होने पर KVM guest पर /dev/kvm मौजूद होता है और kvm-ok स्पष्ट रूप से रिपोर्ट करता है कि acceleration का उपयोग किया जा सकता है या नहीं। Xen HVM पर यह तकनीकी रूप से संभव है लेकिन शायद ही कभी प्रदान किया जाता है। Xen PV पर यह संभव नहीं है।

Container में यह जाँच एक शिक्षाप्रद तरीके से विफल होती है। /proc/cpuinfo host की फ़ाइल है, इसलिए vmx या svm flag मौजूद होता है, और यह वास्तव में सत्य है: आपके नीचे मौजूद physical CPU में वास्तव में वे निर्देश (instructions) हैं। फिर भी, यह आपका नहीं है। आपके namespace में कोई /dev/kvm नहीं है, आप kvm_intel module लोड नहीं कर सकते, और जो flag आपने अभी पढ़ा है वह उस मशीन का वर्णन करता है जिस पर आप guest हैं, न कि उस मशीन का जिसे आप नियंत्रित करते हैं। यह सामान्य नियम का सबसे स्पष्ट उदाहरण है। Container में, /proc उस namespace और उसके आसपास के hardware का वर्णन करता है, न कि उस सर्वर का जिसे आप own करते हैं।

AES-NI और आपके प्लान द्वारा एक्सपोज़ किए गए CPU फीचर्स

AES-NI (advanced encryption standard new instructions) CPU निर्देशों का एक सेट है जो AES एन्क्रिप्शन को सॉफ्टवेयर में होने वाली समान गणनाओं की तुलना में कई गुना तेज बना देता है। TLS termination, डिस्क एन्क्रिप्शन, SSH और बैकअप पाइपलाइन सभी इसी पर निर्भर करते हैं।

KVM पर, आपका गेस्ट क्या देखता है, यह उस CPU मॉडल द्वारा तय होता है जिसे प्रोवाइडर ने QEMU के लिए कॉन्फ़िगर किया है। host passthrough के साथ आप वास्तविक फ्लैग्स देख सकते हैं। qemu64 जैसे जेनेरिक मॉडल, या माइग्रेशन की सुविधा के लिए चुने गए किसी पुराने बेसलाइन के साथ, aes फ्लैग अनुपस्थित हो सकता है, और OpenSSL चुपचाप अपने सॉफ्टवेयर पाथ पर वापस चला जाता है।

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

तीसरी कमांड OpenSSL मैनुअल का उदाहरण है जो लाइब्रेरी के भीतर उन निर्देशों को बंद करने के लिए है: यह AES-NI बिट और VAES बिट को क्लियर कर देती है और बाकी को वैसा ही छोड़ देती है। दोनों थ्रूपुट आंकड़ों की तुलना करें। यदि वे एक-दूसरे के करीब हैं, तो इसका मतलब है कि फास्ट पाथ का उपयोग पहले से नहीं हो रहा था, और VPS पर AES-NI की सही जांच करना किसी प्लान को लेने से पहले पांच मिनट का समय देने लायक है।

कंटेनर के सामने कोई CPU मॉडल नहीं होता है, इसलिए /proc/cpuinfo में मौजूद फ्लैग्स होस्ट के वास्तविक फ्लैग्स होते हैं और वे आप पर लागू होते हैं। यह कंटेनर प्लान का एक वास्तविक लाभ है, और यह इस गाइड का एकमात्र स्थान है जहां साझा कर्नल आपके पक्ष में काम करता है।

Steal time कहाँ से आता है, और container में यह क्यों नहीं होता

Steal time वह समय है जब आपका virtual CPU चलने के लिए तैयार था लेकिन नहीं चल सका, क्योंकि hypervisor किसी और का काम कर रहा था। यह st में top और vmstat के रूप में, और /proc/stat में cpu लाइन के आठवें field के रूप में दिखाई देता है।

एक guest इसे स्वयं नहीं माप सकता, क्योंकि जिस समय यह समय लिया जा रहा होता है, उस समय guest execute नहीं हो रहा होता। Hypervisor को ही इसे बताना पड़ता है। KVM एक running total को उस page में लिखता है जिसे guest अपने paravirtual clock interface के माध्यम से register करता है, और Xen इसी काम के लिए प्रति vCPU एक run state area रखता है। जो संख्या आप पढ़ते हैं, वह hypervisor का अपना स्वीकारोक्ति है, इसीलिए यह मौजूद है और भरोसेमंद है।

High steal का अर्थ है कि host oversubscribed है और आपके पड़ोसी उस समय व्यस्त हैं। यह बेचे गए vCPUs और physical cores के बीच के अनुपात का दृश्य रूप है, और noisy neighbour का पता लगाने के लिए steal time पढ़ना वह एकमात्र माप है जो आपको बताता है कि क्या कोई plan उतना ही बड़ा है जितना उसका page दावा करता है।

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

एक container में वह column नहीं हिलेगा, क्योंकि आपके और scheduler के बीच कोई hypervisor नहीं होता। आपकी processes host के अपने CPU scheduler में सामान्य tasks के रूप में अन्य सभी tenants की processes के साथ कतार में खड़ी होती हैं। Contention तब सामने आता है जब काम बस अधिक समय लेने लगता है, और कोई counter इसका कारण नहीं बताता। इसका निकटतम विकल्प quota throttling है: जब provider cpu.max सेट करता है, तो /sys/fs/cgroup/cpu.stat उन nr_throttled periods और throttled_usec microseconds को गिनता है जो अगले quota window की प्रतीक्षा में व्यतीत हुए। यह केवल आपके अपने quota को कवर करता है, पड़ोसियों से होने वाली प्रतिस्पर्धा को नहीं। एक सावधानी: यदि provider का container host स्वयं एक virtual machine है, तो /proc/stat में steal figure दिखाई दे सकता है, और यह आपके बजाय उस host से संबंधित है।

Overselling और container plan सस्ता क्यों है

इसका ईमानदार जवाब संक्षिप्त है। एक container plan की लागत कम होती है क्योंकि प्रदाता एक ही मशीन को अधिक लोगों के साथ साझा कर रहा होता है।

Memory वह जगह है जहाँ अंतर सबसे अधिक होता है। KVM guest की RAM उसके लिए आरक्षित (committed) होती है, इसलिए 256 GB वाला host लगभग 256 GB के guests बेचता है, जिसमें से overhead घटा दिया जाता है। Container की memory limit एक सीमा (ceiling) है, न कि कोई आरक्षण। जो memory container उपयोग नहीं कर रहा है, वह तुरंत दूसरों के लिए उपलब्ध हो जाती है। इसलिए प्रदाता physical RAM से कई गुना अधिक की सीमाएं बेच सकते हैं और लगभग हर समय यह सही भी रहता है। इसमें कुछ भी फर्जी नहीं है। यह तब तक काम करता है जब तक कि एक साथ पर्याप्त tenants व्यस्त न हो जाएं, और फिर यह सभी के लिए काम करना बंद कर देता है।

CPU को हर plan प्रकार पर oversell किया जाता है, जिसमें KVM भी शामिल है, क्योंकि इसमें cores की संख्या से अधिक vCPUs बेचे जाते हैं। Disk लगभग हर जगह thin provisioned होती है। Containers इसके ऊपर अतिरिक्त घनत्व (density) जोड़ते हैं: एक kernel, एक page cache, और प्रति guest कोई QEMU process नहीं, इसलिए एक host कई गुना अधिक tenants को संभाल सकता है।

आप जो खोते हैं वह isolation है, और यह एक वास्तविक इंजीनियरिंग समझौता है, न कि कोई डराने वाली कहानी। आप एक kernel साझा करते हैं, इसलिए kernel bug एक साझा समस्या है, और container escape सीधे host पर पहुँच जाता है। Virtual machine से बाहर निकलने के लिए hypervisor bug की आवश्यकता होती है, जो कि बहुत छोटा और बहुत कठिन लक्ष्य है। आप प्रदाता के kernel upgrade और reboot schedule को भी अपनाते हैं। यदि इनमें से कोई भी बात आपके लिए मायने रखती है, तो केवल कीमत के आधार पर निर्णय लेने से पहले VPS hosting वास्तव में कितनी सुरक्षित है पढ़ें।

किसे खरीदें

जब आपको अपने स्वयं के kernel की आवश्यकता हो, तो KVM खरीदें: जैसे WireGuard या ZFS modules, कोई विशिष्ट kernel version, nested virtualisation, swap पर वास्तविक नियंत्रण, या ऐसी सीमा जिसे आप किसी auditor को समझा सकें। जब आप सीमित बजट पर सामान्य services चला रहे हों, provider का kernel अद्यतित (current) हो, और आपने पुष्टि कर ली हो कि जिन features पर आप निर्भर हैं, वे पहले से ही उसमें compiled हैं, तो container plan खरीदें। अधिकांश उद्देश्यों के लिए Xen HVM को KVM के समान मानें, और अभी भी Xen PV के रूप में बेची जाने वाली किसी भी चीज़ को खरीदने से पहले सवाल पूछें।

दो प्रकार इस विभाजन से बाहर हैं। Firecracker microVMs प्रत्येक tenant को एक वास्तविक kernel देते हैं, जिसकी startup लागत container के करीब होती है, और serverless platforms इसी पर चलते हैं। Incus system containers आपको अपने नियंत्रण वाले hardware पर स्वयं container model चलाने की सुविधा देते हैं, जो कि किसी से container खरीदने की स्थिति से बिल्कुल अलग है। यदि शब्दावली समझने में कठिनाई हो, तो VPS वास्तव में क्या है और VPS, VM और VPC के बीच का अंतर उन शर्तों को कवर करते हैं जिन्हें यह guide मानती है कि आप पहले से जानते हैं।

FAQ

मेरा VPS KVM है या container, यह कैसे पता करें?

systemd-detect-virt -c चलाएँ। यदि उत्तर none के अलावा कुछ भी है, तो आप एक container के अंदर हैं, चाहे आपके प्लान का नाम कुछ भी हो। इसकी पुष्टि दो और तरीकों से करें, क्योंकि detection को धोखा दिया जा सकता है। lscpu एक hypervisor vendor का नाम बताता है और यह स्पष्ट करता है कि virtualization का प्रकार full है या para। container पर ls /lib/modules/$(uname -r) गायब या खाली होता है, क्योंकि चल रहा kernel host से आता है और उसका module tree आपके filesystem में कभी install नहीं किया गया था। sudo virt-what केवल इसी प्रश्न के लिए लिखे गए एक tool से स्वतंत्र उत्तर देता है।

free -m मेरे प्लान में शामिल memory से कहीं अधिक क्यों दिखाता है?

आप बिना LXCFS mounted वाले container प्लान पर हैं, इसलिए /proc/meminfo host की file है और free host की memory की सटीक रिपोर्ट दे रहा है। आपकी वास्तविक सीमा cgroup है। सीमा जानने के लिए /sys/fs/cgroup/memory.max और वर्तमान उपयोग के लिए /sys/fs/cgroup/memory.current पढ़ें, या पुराने cgroup v1 host पर /sys/fs/cgroup/memory/memory.limit_in_bytes देखें। किसी भी ऐसी service को configure करें जो cache या worker pool का आकार free के बजाय उस संख्या से निर्धारित करती है।

क्या मैं LXC VPS पर Docker या WireGuard चला सकता हूँ?

कभी-कभी, लेकिन यह आपके द्वारा install की गई किसी चीज़ पर निर्भर नहीं करता। दोनों provider के kernel पर निर्भर करते हैं, क्योंकि आप उसमें कोई module load नहीं कर सकते। WireGuard तब काम करता है जब module पहले से host पर मौजूद हो और आप तक पहुँचाया गया हो, और जब ऐसा न हो तो userspace wireguard-go implementation एक विकल्प के रूप में काम करता है। Docker के लिए आवश्यक है कि provider nesting की अनुमति दे और ऐसा storage driver हो जो container के अंदर काम करे। खरीदने से पहले पूछें, या ऐसे term पर test करें जिसे आप कभी भी छोड़ सकें।

मेरा container VPS कभी steal time की रिपोर्ट क्यों नहीं देता?

Steal time केवल तब मौजूद होता है जब hypervisor एक virtual CPU को schedule कर रहा हो, और इसकी रिपोर्ट इसलिए दी जाती है क्योंकि वह hypervisor उस आंकड़े को एक ऐसी page पर लिखता है जिसे आपका kernel पढ़ता है। container के नीचे कोई hypervisor नहीं होता। आपकी processes host के scheduler में सामान्य tasks होती हैं, इसलिए contention का मतलब है कि सब कुछ अधिक समय ले रहा है, लेकिन इसे दर्शाने के लिए कोई counter नहीं है। इसके बजाय /sys/fs/cgroup/cpu.stat पढ़ें: nr_throttled और throttled_usec उस समय को गिनते हैं जो आपके cgroup ने अपनी अगली CPU quota window की प्रतीक्षा में बिताया है, जो container में steal time के सबसे करीब है।