KVM कैसे काम करता है — पर्दे के पीछे
KVM /dev/kvm कैरेक्टर डिवाइस को उजागर करके Linux कर्नेल को एक Type-1 हाइपरवाइज़र में बदल देता है। एक यूज़र-स्पेस प्रक्रिया (आमतौर पर QEMU) उस डिवाइस को खोलती है, कर्नेल से एक वर्चुअल CPU बनाने के लिए कहती है, और फिर हार्डवेयर वर्चुअलाइज़ेशन एक्सटेंशन का उपयोग करके भौतिक CPU पर सीधे अतिथि निर्देश चलाती है। कर्नेल विशेषाधिकार प्राप्त घटनाओं को संभालता है; बाकी सब कुछ नेटिव गति पर निष्पादित होता है।
तीन घटक KVM को काम करने योग्य बनाते हैं। पहला, kvm.ko कर्नेल मॉड्यूल CPU और मेमोरी वर्चुअलाइज़ेशन का प्रबंधन करता है और /dev/kvm इंटरफ़ेस को उजागर करता है। दूसरा, एक आर्किटेक्चर-विशिष्ट मॉड्यूल — Intel VT-x के लिए kvm-intel.ko या AMD-V के लिए kvm-amd.ko — जेनेरिक KVM API और अंतर्निहित CPU के वर्चुअलाइज़ेशन निर्देशों के बीच अनुवाद करता है। तीसरा, QEMU, cloud-hypervisor, या Firecracker जैसी एक यूज़र-स्पेस हाइपरवाइज़र प्रक्रिया डिवाइस एमुलेशन प्रदान करती है: वर्चुअल डिस्क, NIC, USB नियंत्रक, और BIOS या UEFI फ़र्मवेयर। चूँकि Linux कर्नेल स्वयं हाइपरवाइज़र है, हर Linux शेड्यूलर, मेमोरी मैनेजर, और सुरक्षा सुविधा VM पर उसी तरह लागू होती है जैसे यह नेटिव प्रक्रियाओं पर लागू होती है। एक KVM अतिथि कर्नेल के दृष्टिकोण से बस एक भारी प्रक्रिया है, यही कारण है कि top, perf, और cgroups जैसे टूल बिना किसी संशोधन के उस पर काम करते हैं।
KVM बनाम OpenVZ बनाम VMware ESXi बनाम Hyper-V
KVM हर VM के लिए एक अलग अतिथि कर्नेल के साथ पूर्ण हार्डवेयर वर्चुअलाइज़ेशन प्रदान करता है। OpenVZ OS-स्तर कंटेनरीकरण का उपयोग करता है जहाँ हर कंटेनर होस्ट कर्नेल साझा करता है। VMware ESXi अपने स्वयं के कर्नेल (VMkernel) के साथ एक मालिकाना बेयर-मेटल Type-1 हाइपरवाइज़र है। Hyper-V Microsoft का Windows-आधारित Type-1 हाइपरवाइज़र है। केवल KVM, ESXi, और Hyper-V आपको एक वास्तविक, पृथक अतिथि कर्नेल देते हैं।
OpenVZ (और इसका उत्तराधिकारी Virtuozzo) एक कंटेनर तकनीक है, हाइपरवाइज़र नहीं। हर OpenVZ कंटेनर होस्ट का Linux कर्नेल साझा करता है, जिसका अर्थ है कि आप एक अलग कर्नेल संस्करण नहीं चला सकते, आप कस्टम कर्नेल मॉड्यूल लोड नहीं कर सकते, और आप एक गैर-Linux ऑपरेटिंग सिस्टम नहीं चला सकते। व्यापार-बंद घनत्व है: चूँकि कोई प्रति-VM कर्नेल ओवरहेड नहीं है, एक OpenVZ होस्ट उसी हार्डवेयर पर अधिक कंटेनर ठूस सकता है, यही कारण है कि कम-अंत साझा-VPS योजनाएँ अक्सर इसका उपयोग करती थीं। VMware ESXi Type-1 वर्चुअलाइज़ेशन के लिए एंटरप्राइज़ मानक है लेकिन प्रति-सॉकेट लाइसेंसिंग वाले एक बंद-स्रोत उत्पाद के रूप में शिप होता है जिसने ऐतिहासिक रूप से इसे कमोडिटी VPS होस्टिंग से बाहर मूल्यवान बना दिया। Hyper-V Windows-सर्वर वातावरण पर हावी है और Active Directory और System Center के साथ कसकर एकीकृत है लेकिन Linux-भारी होस्टिंग बेड़े के लिए एक कम सामान्य विकल्प है। KVM आधुनिक VPS होस्टिंग के लिए डिफ़ॉल्ट बन गया है क्योंकि यह ओपन सोर्स है, कर्नेल-मेनलाइन है, x86_64 या aarch64 पर चलने वाले किसी भी अतिथि OS का समर्थन करता है, और इसका एक परिपक्व प्रबंधन पारिस्थितिकी तंत्र (libvirt, oVirt, Proxmox, OpenStack Nova) है।
क्यों KVM VPS के लिए आधुनिक डिफ़ॉल्ट है
KVM प्रमुख VPS तकनीक बन गया क्योंकि यह VMware-शैली लाइसेंसिंग का भुगतान किए बिना हर ग्राहक को एक वास्तविक, पृथक कर्नेल देता है। यह Linux, Windows, BSD, और Solaris अतिथियों का समर्थन करता है, कमोडिटी x86_64 और ARM हार्डवेयर पर चलता है, और हर प्रमुख क्लाउड ऑर्केस्ट्रेशन स्टैक में एकीकृत है — OpenStack, Proxmox VE, KubeVirt के माध्यम से Kubernetes, और AWS Nitro सभी इस पर निर्माण करते हैं।
तीन ताकतें मिलकर KVM को मानक बनाती हैं। पहला, हार्डवेयर वर्चुअलाइज़ेशन एक्सटेंशन सार्वभौमिक हो गए: Intel VT-x 2006 में Core 2 चिप्स में शिप हुआ और AMD-V शुरुआती Athlon 64s में, इसलिए 2010 के दशक की शुरुआत तक अनिवार्य रूप से हर सर्वर CPU निकट-नेटिव गति पर KVM होस्ट कर सकता था। दूसरा, Linux समुदाय ने मेनलाइन में Xen-शैली पैरावर्चुअलाइज़ेशन को अपनाने से इनकार कर दिया, लेकिन 2007 में KVM को मेनलाइन किया, तुरंत हर वितरण को एक अंतर्निहित हाइपरवाइज़र दिया। तीसरा, सार्वजनिक क्लाउड पारिस्थितिकी तंत्र ने भारी निवेश किया: Google Cloud Engine KVM पर लॉन्च हुआ, AWS Xen से KVM-आधारित Nitro आर्किटेक्चर में माइग्रेट हुआ, और OpenStack ने KVM को संदर्भ हाइपरवाइज़र के रूप में मानकीकृत किया। छोटे VPS प्रदाता इस गुरुत्वाकर्षण खिंचाव से लाभान्वित होते हैं क्योंकि वही टूलिंग जो हाइपरस्केलर बेड़े चलाती है — libvirt, virtio ड्राइवर, cloud-init — कमोडिटी सर्वरों के एक रैक पर भी चलती है।
वास्तविक प्रदर्शन विशेषताएँ: CPU स्टील, IO, और ओवरहेड
एक उचित रूप से प्रावधानित KVM होस्ट पर, बेयर मेटल बनाम सिंगल-डिजिट-प्रतिशत CPU ओवरहेड, स्थानीय-नेटवर्क पथ पर जोड़ी गई सब-मिलीसेकंड नेटवर्क लेटेंसी, और जब virtio-blk या virtio-scsi का उपयोग पैरावर्चुअलाइज़्ड ड्राइवर के साथ किया जाता है तो नेटिव डिस्क IOPS का 80-95% अपेक्षा करें। 5% से ऊपर निरंतर CPU स्टील समय होस्ट ओवरकमिट का कैनोनिकल संकेत है और एक मजबूत अपग्रेड सिग्नल है।
उत्पादन में एक KVM अतिथि के लिए तीन संख्याएँ मायने रखती हैं। CPU स्टील समय, /proc/stat में आठवें फ़ील्ड के रूप में उजागर, उस समय का प्रतिशत मापता है जिसमें वर्चुअल CPU चलने के लिए तैयार था लेकिन भौतिक CPU अन्य अतिथियों को निष्पादित करने में व्यस्त था। 1-2% से नीचे कुछ भी सामान्य पृष्ठभूमि शोर है; 5% से ऊपर निरंतर मान का मतलब है कि होस्ट ओवरकमिट है और आपका वर्कलोड थ्रॉटल हो रहा है। IO वेट, iostat और top जैसे टूल द्वारा सामने लाया जाता है, उस समय का प्रतिशत मापता है जो CPU ने डिस्क या नेटवर्क पर अवरुद्ध बिताया। virtio पैरावर्चुअलाइज़्ड ड्राइवरों और आधुनिक NVMe बैकिंग स्टोरेज के साथ, एक वर्कलोड पर 20% से ऊपर निरंतर IO वेट जो CPU-बाउंड होना चाहिए, यह एक मजबूत संकेत है कि डिस्क उपप्रणाली संतृप्त है। virtio-net पर नेटवर्क थ्रूपुट को भौतिक NIC की लाइन दर के 80-95% तक पहुँचना चाहिए; उससे काफी नीचे कुछ भी एक गलत-कॉन्फ़िगर ऑफ़लोड या एक पुराने एमुलेटेड e1000 ड्राइवर की ओर इशारा करता है।
कब KVM का उपयोग नहीं करना चाहिए
KVM तीन स्थितियों में गलत विकल्प है: अल्ट्रा-उच्च-घनत्व कंटेनरीकृत वर्कलोड जहाँ प्रति-VM कर्नेल ओवरहेड हावी है, Windows-लाइसेंसिंग-संवेदनशील तैनाती जहाँ Hyper-V का SPLA मूल्य निर्धारण काफी सस्ता है, और कुछ कम-लेटेंसी हार्डवेयर-पासथ्रू परिदृश्य जहाँ SR-IOV या GPU पासथ्रू आपके विशिष्ट NIC या GPU मॉडल पर खराब समर्थित है।
कंटेनरीकृत माइक्रोसर्विसेज़ के लिए जिन्हें कर्नेल आइसोलेशन की आवश्यकता नहीं है, बेयर मेटल पर सीधे चलने वाले Linux कंटेनर (Docker, Podman, Kubernetes) किसी भी KVM-आधारित VPS की तुलना में 3-5x अधिक पैक करेंगे क्योंकि प्रत्येक कंटेनर बस नेमस्पेस और cgroups वाला एक प्रक्रिया समूह है। घनत्व-संवेदनशील कम-लागत वाले VPS प्रदाताओं ने ऐतिहासिक रूप से इसी कारण से OpenVZ चुना। Windows-भारी तैनाती — विशेष रूप से वे जो SPLA के माध्यम से खरीदे गए Windows Server लाइसेंस चलाती हैं — कभी-कभी KVM की तुलना में Hyper-V पर काफी कम भुगतान करती हैं क्योंकि Microsoft प्रतिस्पर्धी हाइपरवाइज़रों पर अतिथि लाइसेंस की कीमत कैसे लगाता है। अंत में, कुछ हार्डवेयर-पासथ्रू परिदृश्य अभी भी KVM पर दर्दनाक हैं: GPU पासथ्रू को IOMMU समूहों को साफ-सुथरे रूप से अलग किए जाने की आवश्यकता है, कुछ उपभोक्ता NIC में SR-IOV समर्थन नहीं है, और NVMe ड्राइव का PCIe पासथ्रू कभी-कभी रीसेट-बग वर्कअराउंड को ट्रिगर करता है। 95% सामान्य-उद्देश्य Linux VPS वर्कलोड के लिए, इनमें से कोई भी लागू नहीं होता है और KVM सही डिफ़ॉल्ट है।
कैसे सत्यापित करें कि एक VPS वास्तव में KVM-आधारित है
एक Linux अतिथि के अंदर, `systemd-detect-virt` चलाएँ — इसे `kvm` प्रिंट करना चाहिए। `lscpu` (the 'Hypervisor vendor' लाइन को 'KVM' पढ़ना चाहिए) और `dmesg | grep -i kvm` के साथ क्रॉस-चेक करें। यदि आप इसके बजाय 'OpenVZ', 'lxc', या 'VMware' देखते हैं, तो आपका प्रदाता एक अलग तकनीक का उपयोग कर रहा है, भले ही मार्केटिंग विपरीत दावा करे।
एक अनुबंध पर हस्ताक्षर करने से पहले, एक ट्रायल VPS पर एक छोटी डायग्नोस्टिक बैटरी चलाएँ। कैनोनिकल डिटेक्शन आउटपुट के लिए `systemd-detect-virt` चलाएँ। यह पुष्टि करने के लिए `cat /proc/cpuinfo | grep -E 'vmx|svm'` चलाएँ कि हार्डवेयर वर्चुअलाइज़ेशन एक्सटेंशन पास हो रहे हैं (कुछ प्रदाता उन्हें हटा देते हैं, नेस्टेड वर्चुअलाइज़ेशन को तोड़ देते हैं)। यह सत्यापित करने के लिए `uname -r` चलाएँ कि आप एक साझा होस्ट कर्नेल के बजाय एक अतिथि-विशिष्ट कर्नेल देख रहे हैं — एक वास्तविक KVM VPS पर आप `apt install linux-image-...` या `dnf install kernel-...` के माध्यम से एक अलग कर्नेल स्थापित कर सकते हैं और इसमें रिबूट कर सकते हैं। OpenVZ पर आप नहीं कर सकते। अंत में, `/proc/user_beancounters` जाँचें — यदि वह फ़ाइल मौजूद है, तो होस्ट OpenVZ चला रहा है, चाहे मार्केटिंग कॉपी कुछ भी कहे।