KVM में महारत हासिल करें: सामान्य मुद्दों और समस्या निवारण के लिए विशेषज्ञ गाइड

कुछ समय पहले, मैंने आपको दो Xen समस्या निवारण लेख दिए, जिनमें उन कुछ सामान्य समस्याओं पर चर्चा की गई थी जिनका आप Xen तकनीक का उपयोग करके अपने वातावरण को प्रावधान करने का प्रयास करते समय सामना कर सकते हैं। आज, हम KVM के साथ भी यही काम करेंगे।

व्यक्तिगत रूप से, मुझे लगता है कि KVM Python उल्टी वर्बोसिटी और समग्र जटिलता के मामले में कहीं अधिक सुंदर है, लेकिन आप अभी भी कभी-कभी बदसूरत त्रुटियों का सामना कर सकते हैं जो आपके जीवन को और अधिक कठिन बना देंगी। यह ट्यूटोरियल आपको सिखाएगा कि उनके आसपास कैसे काम करें, संभावित कॉन्फ़िगरेशन और सेटअप संघर्षों की पहचान कैसे करें, और कई अन्य साफ-सुथरी ट्रिक्स। मेरे पीछे आइए।

टिप 1: ब्रिज नेटवर्किंग इंटरफ़ेस दिखाई नहीं देता

मान लीजिए आप एक कस्टम ब्रिज डिवाइस का उपयोग करना चाहते हैं जिसे आपने बनाया है, जिसे br0 कहा जाता है। हालांकि, जब आप अपना नेटवर्क सेटअप करने का प्रयास करते हैं और अपने गेस्ट को विशिष्ट इंटरफ़ेस का उपयोग करने के लिए बनाते हैं, तो यह Virtual Machine Manager में ड्रॉपडाउन मेनू में दिखाई नहीं देता। नीचे दी गई छवि सटीक विपरीत दिखाती है, लेकिन कल्पना करें कि आपका वांछित डिवाइस उपलब्ध एडाप्टर्स की सूची में नहीं है। ऐसा हो सकता है, और मैंने ऐसा होते देखा है, इसलिए मुझ पर विश्वास करें, इंटरनेट के नागरिकों।

समाधान बहुत सरल है - अपने डोमेन के लिए कॉन्फ़िगरेशन फाइल को मैन्युअल रूप से संपादित करें। डिफ़ॉल्ट रूप से, KVM फाइलों को दो स्थानों में संग्रहीत करता है, या तो /etc/kvm/vm या /etc/libvirt/qemu, इसलिए आप अपने XML फाइलों को वहां ढूंढने की सबसे अधिक संभावना रखते हैं। प्रासंगिक को खोलें और <source bridge> के तहत ब्रिज्ड एडाप्टर विवरण को मैन्युअल रूप से बदलें। फाइल को बंद करें, वर्चुअल मशीन शुरू करें और आनंद लें।

टिप 2: Biosdevname और कोई नेटवर्क नहीं

Biosdevname एक उपयोगिता है जो उपकरणों को BIOS-दिए गए नाम असाइन करने का प्रयास करती है, सामान्यता को संरक्षित करती है और हार्डवेयर प्रशासन के तर्क को सरल बनाती है, विशेष रूप से नेटवर्क उपकरणों के साथ। यदि आपके पास उनमें से कई हैं, अद्वितीय क्षमताओं या कार्यों के साथ, तो आप उन्हें सामान्य ethX नामों से पहचानना कठिन पाएंगे, लेकिन यदि उन्हें अद्वितीय स्ट्रिंग दिए गए थे, तो आप आसानी से 1Gbps और 10Gbps एडाप्टर्स और ऐसे को अलग बता पाएंगे। स्वाभाविक रूप से, यह ज्यादातर एंटरप्राइज़ सिस्टम के लिए उपयोगी है, क्योंकि घर पर लोग शायद ही कभी इस दुविधा का सामना करते हैं।

हालांकि, biosdevname का उपयोग करने का दुष्प्रभाव यह है कि यदि इसका उपयोग आपके KVM-निर्मित वर्चुअल मशीनों में गेस्ट ऑपरेटिंग सिस्टम के अंदर किया जाता है, तो आप नेटवर्क के बिना समाप्त हो सकते हैं, क्योंकि वर्चुअलाइज्ड डिवाइस को भौतिक नाम मिलेंगे जो बिल्कुल मेल नहीं खाते।

समस्या के आसपास काम करने के कई तरीके हैं। एक, उपयोगिता के कुछ संस्करण यह पता लगाने में सक्षम हैं कि उन्हें वर्चुअल वातावरण के अंदर आह्वान किया जा रहा है और बिना कोई बदलाव किए बाहर निकल जाएंगे। दूसरा GRUB मेनू में एक कर्नेल आर्गुमेंट पास करना है; biosdevname=0 उपयोगिता को चलाने से अक्षम कर देगा।

एक तीसरा विकल्प नेटवर्क कार्ड को नाम असाइन करने के लिए उपयोग किए जाने वाले udev नियमों को हैक करना है। यहां एक बहुत ही प्रारंभिक उदाहरण है; यह एक सिंगल नेटवर्क एडाप्टर वाली मशीन के लिए डिज़ाइन किया गया है, इसलिए आपको कई कार्ड्स के लिए अधिक डायनामिक लॉजिक की आवश्यकता होगी। या, जैसा कि टिप्पणी पाठ कहता है, आपको प्रत्येक नियम के लिए एक अलग लाइन बनाने की आवश्यकता होगी।

आप क्लासिक असाइनमेंट प्राप्त करने के लिए मैन्युअल परिवर्तन कर सकते हैं:

vi /etc/udev/rules.d/70-persistent-net.rules

NAME स्ट्रिंग को "eth_biosname" से "ethX" या जो भी आपको चाहिए उसमें बदलें:

# PCI device ...
SUBSYSTEM=="net", ACTION=="add", ATTR(type)=="1",
KERNEL=="eth*", NAME="eth_biosname"

# PCI device ...
SUBSYSTEM=="net", ACTION=="add", ATTR(type)=="1",
KERNEL=="eth*", NAME="eth0"

आपको अपने वर्चुअल मशीनों में उपयोग किए जाने वाले वर्चुअल हार्डवेयर के आधार पर अलग-अलग नियम मिलेंगे। उदाहरण के लिए, आप Realtek, e1000 या virtio वर्चुअल हार्डवेयर का विकल्प चुन सकते हैं, जिसके परिणामस्वरूप अन्य स्ट्रिंग्स होंगे। ध्यान दें और सुनिश्चित करें कि आप समाधान को अपने विशिष्ट वातावरण से मेल खाते हैं।

टिप 3: डोमेन पहले से मौजूद है

क्या होता है यदि आप एक नए डोमेन को परिभाषित करने का प्रयास करते हैं और यह पहले से मौजूद है, सिवाय इसके कि आपको इसकी कॉन्फ़िगरेशन फाइल या घोषणा खोजने में परेशानी हो रही है। virsh list के पास नहीं है, virt-manager इसे कहीं नहीं दिखाता। तो आप क्या करते हैं?

virsh define machine.xml
error: Failed to define domain from machine.xml
error: operation failed: domain 'machine' already exists
with uuid 883ab02f-1a67-7430-ef9a-2b59af52210e7

आपको कॉन्फ़िगरेशन फाइल ढूंढनी होगी और इसे हटाना होगा। और फिर libvirtd सेवा को पुनरारंभ करें।

updatedb
locate machine.xml
rm <full path to machine.xml>
/etc/init.d/libvirtd restart

टिप 4: आंतरिक त्रुटि: cgroup खोजने में असमर्थ

यह समस्या libvirtd को पुनरारंभ करने के बाद प्रकट हो सकती है, जैसे ऊपर के उदाहरण में, या पूरी तरह से असंबंधित। एक पूर्ण त्रुटि संदेश इस तरह दिख सकता है:

virsh create machine.xml
error: Failed to create domain from machine.xml
error: internal error Unable to find cgroup for machine

इस बग का कारण systemd से संबंधित हो सकता है, जैसा कि Bugzilla रिपोर्ट में निर्दिष्ट है, लेकिन यह आपकी प्राचीन मशीनों पर भी हो सकता है जो systemd का उपयोग नहीं कर रहे हैं। ज्यादातर मामलों में, यह cgroups और libvirtd के बीच एक बहुत ही नाजुक दौड़ है, जो libvirtd सेवा के cgroups से पहले आने के कारण होती है, cgroups में से एक को हटाया जा रहा है या पहली जगह में मौजूद नहीं है।

आप libvirtd कॉन्फ़िगरेशन को संपादित करके समस्या को हल कर सकते हैं, /etc/libvirt/qemu.conf। इस फाइल के अंदर, आपको cgroups_controllers निर्देश को संपादित करने की आवश्यकता है ताकि यह किसी भी cgroups को सूचीबद्ध न करे, जिस स्थिति में, libvirtd उनके बिना चलने में सक्षम होगा।

cgroups_controllers = [ ]

इसके बाद, आपको libvirtd को फिर से पुनरारंभ करना होगा। वैकल्पिक रूप से, आपको मैन्युअल रूप से आवश्यक cgroups बनाने और libvirtd प्रक्रिया को प्रासंगिक सबसिस्टम में असाइन करना होगा।

टिप 5: हाल्ट/रीबूट पर VMM से वर्चुअल मशीन गायब हो जाती है

यह वास्तव में एक बहुत ही सरल मुद्दा हो सकता है। आपके द्वारा वर्चुअल मशीन को हाल्ट या रीबूट करने के बाद, वर्चुअल मशीन कंसोल बंद हो जाता है। आपके कॉन्फ़िगरेशन मौजूद हैं, लेकिन यह एक बड़ी असुविधा है, क्योंकि आपको मशीन प्रबंधन चक्र में हस्तक्षेप करना होगा।

आपको अपने वर्चुअल मशीन के लिए प्रासंगिक XML फाइल में on_reboot क्लॉज को देखना होगा और सुनिश्चित करना होगा कि कार्रवाई destroy के बजाय restart पर सेट है। वहां आप जाएं, बस इतना ही है।

<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>

टिप 6: कोई रीबूट एक्शन नहीं; फ़ंक्शन समर्थित नहीं है

फिर से, पिछली टिप से बहुत संबंधित। यदि आप restart के बजाय reboot निर्दिष्ट करते हैं, तो आप सीखेंगे कि यह एक अमान्य कमांड है जिसे KVM निष्पादित नहीं कर सकता। हालांकि, आपको एक बल्कि विपुल त्रुटि देखने की सबसे अधिक संभावना है:

libvirtError: this function is not supported by the hypervisor: virDomainReboot

यदि आप restart का उपयोग करते हैं, तो सब ठीक होगा।

टिप 7: इंस्टॉलेशन के बाद बूटलोडर त्रुटि

कभी-कभी, आप एक GRUB त्रुटि देख सकते हैं, सबसे अधिक संभावना नंबर 15, एक बाहरी मीडिया स्रोत से इंस्टॉलेशन के बाद पहले रीबूट पर। यह हो सकता है यदि आप CD/DVD इमेज को वर्चुअल मशीन से अटैच छोड़ देते हैं और इसे अपने XML फाइल में पहले बूट डिवाइस के रूप में चुनते हैं। समस्या इस VirtualBox बग के समान है, जो कुछ Linux डिस्ट्रीब्यूशन को प्रभावित करती है। उदाहरण के लिए:

root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz

Error 15: File not found

Press any key to continue...

आप ISO इमेज को अनमाउंट करके और गेस्ट को रीबूट करके हल कर सकते हैं। इस बार, यह अच्छा काम करना चाहिए। कृपया ध्यान दें कि यदि आप अपनी हार्ड डिस्क को पहले बूट करने योग्य डिवाइस के रूप में सेट करते हैं तो समस्या प्रकट नहीं होगी, क्योंकि KVM स्वचालित रूप से दूसरे उपलब्ध स्रोत पर कूद जाएगा, सबसे अधिक संभावना PXE या CD/DVD, यदि यह डिस्क पर एक वैध पार्टीशन टेबल नहीं ढूंढ पाता है, जो कि मामला होना चाहिए यदि आप अभी केवल इंस्टॉल कर रहे हैं।

और मुझे लगता है कि हम आज के लिए यहां कर चुके हैं।

अधिक पठन

आप कई और KVM लेखों में रुचि ले सकते हैं:

KVM स्टोरेज और नेटवर्क गाइड, प्लस ब्रिज्ड नेटवर्किंग

KVM + Virtualbox साइड-बाय-साइड उपयोग howto

KVM क्लोनिंग गाइड

निष्कर्ष

पहले समस्या निवारण गाइड के लिए आधा दर्जन टिप्स, बुरा नहीं मुझे लगता है। यह ट्यूटोरियल ब्रिज्ड नेटवर्किंग सेटअप, biosdevname के आसपास काम करना, cgroups + libvirtd समस्याएं, virt-manager द्वारा ऑटो-बनाए गए डुप्लिकेट डोमेन को अनरजिस्टर करना, और गेस्ट ऑपरेटिंग सिस्टम रीस्टार्ट संकटों को हल करने पर केंद्रित है।

अधिकांश काम कॉन्फ़िगरेशन फाइलों को संपादित करके और सेवाओं को पुनरारंभ करके किया जाता है। हम GUI पर भरोसा नहीं करते हैं, क्योंकि किसी भी कार्रवाई जिसे कमांड लाइन में अनुवादित किया जा सकता है, उसे आसान और पूरी तरह से स्वचालित प्रबंधन के लिए स्क्रिप्ट किया जा सकता है। वैसे भी, मुझे आशा है कि आपने इसे पसंद किया; यदि आपके पास सीक्वल के लिए विचार हैं, तो मुझे पिंग करें।

चीयर्स।