यह आलेख xvc0 के संचालन के सिद्धांत से संबंधित है, दोनों domU के दृष्टिकोण से और dom0 के दृष्टिकोण से, और यह भी बताता है कि इस कंसोल के साथ आगे क्या किया गया है।
मैं आपको तुरंत चेतावनी देता हूं, यह विषय केवल उन लोगों के लिए दिलचस्प है जो एक्सईएन के साथ मिलकर काम करते हैं।

ज़ेन के दृष्टिकोण से कंसोल

कंसोल और XenStore वर्चुअल मशीन में दो डिवाइस हैं, जिन्हें XenStore के माध्यम से घोषित नहीं किया जाता है, लेकिन पवित्र के पवित्र के लिए लिखा जाता है - डोमेन का प्रारंभ जानकारी पृष्ठ। अन्य सभी उपकरणों के लिए मानक तंत्र एक्सनस्टोर में उनकी घोषणा है। यह स्पष्ट है कि XenStore में XenStore की घोषणा करना कुछ असुविधाजनक है, इसलिए यह उपकरण "बहुत शुरुआत से होना चाहिए"।

कंसोल को "साधारण" उपकरणों की सूची में रखा जा सकता है। लेकिन उन्हें एक विशेष वर्ग में ले जाया गया और डिबगिंग और निदान की सुविधा के लिए "एक्सनस्टोर के बराबर" बनाया गया। जितनी जल्दी कर्नेल कंसोल को लिख सकता है (और हम इसे पढ़ सकते हैं), अधिक संभावना है कि कंसोल पर जानकारी टूटने के कारण को निर्धारित करने के लिए पर्याप्त होगी।

बहुत कम स्तर पर, कंसोल एक रिंग बफर का उपयोग करता है, जिसके एक पृष्ठ का आकार मेमोरी (i386 / x86_64 के लिए 4k) होता है। इस रिंग बफर को 1024/2048 के अनुपात में विभाजित किया गया है, पहली छमाही का उपयोग इनपुट के लिए किया जाता है ("दबाए गए" बटन के लिए एक बफर), आउटपुट के लिए दूसरा छमाही (वर्ण और एस्क कोड जो स्क्रीन पर प्रदर्शित होते हैं)।

रिंग बफर क्या है? यह एक डेटा संरचना है जिसमें पता स्थान बंद है (4095 के बाद 0, 1, 2 ..., 4095, 0, 1 ... और इसी तरह अनन्तता के लिए)। बफर में दो मार्कर हैं - कतार की शुरुआत और अंत। जाहिर है, नया डेटा अंत तक लिखा गया है, लेकिन शुरुआत से पढ़ा जाता है। या इसके विपरीत (यह शब्दों का सवाल है)। केवल एक स्थिति की जांच की जाती है - अंत शुरुआत तक नहीं पहुंचा है। या शुरुआत अंत तक नहीं पहुंची है।

मैं एल्गोरिथम भाग को एक तरफ छोड़ दूंगा। बहुत अधिक महत्वपूर्ण यह है कि रिंग बफर के लिए उपयोग किया जाने वाला मेमोरी पेज एक साथ dom0 और domU द्वारा पहुँचा जा सकता है (सामान्य स्थिति में, यह दो डोमेन के लिए उपलब्ध है, लेकिन हमारे विशेष मामले में डोमेन में से एक डोम 0 है)।

इस बिंदु को समझना कठिन है (और इसकी व्याख्या "कंसोल" के वर्णन से बहुत आगे जाती है), लेकिन संक्षेप में यह इस तरह दिखता है: एक ही भौतिक मेमोरी पेज (मोटे तौर पर, मेमोरी बार पर बिट्स) के दो पते हैं। एक dom0 में, दूसरा domU में। एक्सन जब मशीन एक्सेस करता है तो मेमोरी भौतिक में वर्चुअल एड्रेस का अनुवाद करती है। और यह ऐसा करता है ताकि दोनों डोमेन एक ही भौतिक पृष्ठ पर लिख सकें। उसी समय, प्रत्येक पृष्ठ का अपना पता होता है।

"हर किसी का अपना है," वैसे, यह सिर्फ एक सनक नहीं है। यदि domU के लिए मेमोरी पेज का पता तय किया जा सकता है, तो यह dom0 के लिए काम नहीं करेगा - चारों ओर domU का एक गुच्छा है, और यह स्पष्ट है कि प्रत्येक कंसोल कंसोल के लिए अपने स्वयं के मेमोरी पेज का उपयोग करता है।

इसलिए, हमारे पास डेटा को domU से dom0 और इसके विपरीत में स्थानांतरित करने के लिए एक तंत्र है (यह तंत्र वास्तव में लगभग हर जगह उपयोग किया जाता है, लेकिन हमारे विशेष मामले में यह कंसोल ऑपरेशन के लिए भी उपयोग किया जाता है)।

इंटरैक्शन का दूसरा तंत्र इवेंट चैनल है, पीवी मोड में एक तरह का व्यवधान। वास्तव में, ये दो तंत्र, प्लस हाइपरसेल, वे सभी हैं जो एक्सएन में अतिथि मशीनों के लिए हैं, इसलिए कंसोल नेटवर्क ड्राइवर से बहुत अलग नहीं है, उदाहरण के लिए।

डोमू को इसके कंसोल के बारे में कैसे पता चलता है?

डोमू के संदर्भ में सांत्वना

जब वर्चुअल मशीन शुरू होती है, तो dom0 में एक विशेष प्रोग्राम अपना डोमेन बनाता है। इस प्रोग्राम को domain_builder कहा जाता है। कर्नेल कोड को लोड करने के अलावा, यह स्टार्ट इंफो पेज भी भरता है, जिसके आधार पर डोमेन सब कुछ पा सकता है। ईएसआई रजिस्टर में इस पृष्ठ का पता (x86 के मामले में) पारित किया गया है। अन्य आर्किटेक्चर पर, निश्चित रूप से, तरीके अलग हैं।

यह बहुत महत्वपूर्ण है कि यह जानकारी (कंसोल की स्थिति और घटनाओं की चैनल संख्या के बारे में) स्थिर नहीं है - डोमेन किसी भी समय माइग्रेट कर सकता है, जो वास्तव में, का अर्थ है कि start_info_page की सामग्री अचानक बदल जाती है।

इस बिंदु पर रिंग चैनल और इवेंट चैनल पर काम करने के लिए बाध्य होने के बारे में 50-60kb की व्याख्या होनी चाहिए थी, लेकिन पाठक की अनुमति से, मैं इस हिस्से को छोड़ दूंगा, क्योंकि कहानी कंसोल के बारे में है, और इसके बारे में नहीं एक्सएम कैसे काम करता है। प्रत्येक खंड के स्रोत पाठ तक एक अधिक विस्तृत विश्लेषण अद्भुत पुस्तक "एक्सपी हाइपरवाइजर के लिए निश्चित मार्गदर्शिका" में है।

कंसोल ड्राइवर का क्या होता है?

अधिकांश एक्सना उपकरणों की तरह, ड्राइवर को दो हिस्सों में विभाजित किया गया है: बैकएंड और फ्रंटेंड।

फ्रंटेंड डोमू में काम करता है, और यही हम देखेंगे। यह ड्राइवर, start_info_page में संबंधित डेटा पाता है, एक कैरेक्टर डिवाइस बनाता है (सटीक होने के लिए, यह udeg द्वारा बनाया गया है)। इस उपकरण का नाम नौसिखिया एक्सईएन प्रशासकों के लिए एक अच्छी मात्रा में सिरदर्द का स्रोत है, जैसा कि हाइपरविजर के अस्तित्व के दौरान, यह कई बार बदल गया है, और नेतृत्व इस मामले में काफी बकवास कर सकता है।

नाम / देव / xvc0, / dev / hvc0, / dev / ttyS0 हो सकता है। पहला एक्सन वर्चुअल कंसोल है, दूसरा एच है? वर्चुअल कंसोल "लिनक्स में वर्चुअलाइजेशन वर्चुअल कंसोल का सामान्य नाम है (मैं यह नहीं कह सकता कि कैसे h खड़ा है), ttyS0 एक प्रारंभिक युग की विरासत है जब वर्चुअल कंसोल खुद को सीरियल पोर्ट के रूप में प्रच्छन्न करता है।

तो, डिवाइस बनाया गया है। और क्या? स्टार्टअप पर कर्नेल "जानता है" जहां बूट समय के संदेश लिखने के लिए - वर्चुअल कंसोल पर।

डाउनलोड समाप्त होता है ... और नौसिखिए प्रशासक आतंकित होते हैं, क्योंकि "यह लटका हुआ है।" मुकुट शुरू होता है - और वह है, वर्चुअल मशीन बटन पर प्रतिक्रिया करना बंद कर देती है और लॉगिन के लिए नहीं पूछती है।

यह समझने के लिए कि क्या होता है (और क्या होना चाहिए), आइए विचार करें कि डाउनलोड पूरा होने पर एक नियमित कंसोल पर क्या होता है। Init प्रक्रिया इनटैब पढ़ती है और इसमें निर्दिष्ट प्रक्रियाओं को शुरू करती है (गेटी और लाइक)। गेट्टी कंसोल (या सीरियल पोर्ट) को कॉन्फ़िगर करता है और रन / बिन / लॉगिन करता है, जो लंबे समय से प्रतीक्षित "लॉगिन:" प्रदर्शित करता है। यदि गेटी शुरू नहीं हुई है, तो इसका मतलब है कि लॉगिन करने के लिए कोई नहीं है। "यह लटका हुआ है।"

समाधान सरल है: 0:12345:respawn:/sbin/getty xvc0 9600 in / etc / inittab।

ध्यान दें कि xvc0 नाम से मेल खाना चाहिए कि ड्राइवर क्या बनाता है। और चालक बनाता है कि कर्नेल कमांड लाइन तर्कों (कंसोल = xvc0) के माध्यम से इसे अतिरिक्त के रूप में क्या पारित किया गया था। यदि आपने इसे पारित नहीं किया है, तो यह डिफ़ॉल्ट रूप से उपयोग किया जाता है, और इसे खाड़ी से अनुमान लगाना काफी कठिन है।

तो, हम रजिस्टर करते हैं, लोड करते हैं, पोषित लॉगिन देखते हैं, रूट के साथ लॉग इन करने का प्रयास करते हैं, और ... हमें बताया जाता है कि नाम गलत है।

तथ्य यह है कि लॉगिन यह निर्धारित करने के लिए / आदि / सिक्योरिटी फ़ाइल पढ़ता है कि कौन से उपकरण लॉग इन कर सकते हैं। कुछ वितरणों में xvc0 पंजीकृत नहीं है, और हमें इसे हाथ से पंजीकृत करने की आवश्यकता है। लिखिए, जयकार। Loginov।

क्षमा करें, मैंने अपनी शैली खो दी है, मैं एक गाइड नहीं लिख रहा हूं "कंसोल को कैसे देखें", लेकिन जो हो रहा है उसका विवरण।

तो एक ठीक से कॉन्फ़िगर डोमू में क्या होता है?

1. ड्राइवर start_info_page से डेटा पढ़ता है
2. ड्राइवर एक कैरेक्टर डिवाइस बनाता है
3. init इस डिवाइस के लिए गेटी लॉन्च करता है (यह init नहीं हो सकता है, वैसे, आप rtylocal से भी आवश्यक मापदंडों के साथ getty चला सकते हैं, यहां तक ​​कि ssh के माध्यम से भी)।
4. getty ने लॉगिन शुरू किया
5. लॉगिन स्टार्ट -बैश, जो अन्य सभी प्रक्रियाओं के लिए जिम्मेदार नियंत्रण टर्मिनल बन जाता है (मोटे तौर पर बोलकर, यह Ctrl-C, Ctrl-Z, आदि को उचित रूप से संभालता है)।
6. बैश एक सामान्य जीवन जीते हैं, कार्यक्रम चलाते हैं। कार्यक्रम उनके लिए सामान्य रूप से लिखने के लिए लिखे जाते हैं, स्टड से पढ़े जाते हैं, आदि, यह सब ड्राइवर को मिलता है, ड्राइवर से ब्लॉक बफर तक, जहां से यह डोम 0 पर जाता है ...

xenconsoled

(dom0 के संदर्भ में सांत्वना)
यहां हम दूसरे पर आते हैं, एक्सन कंसोल का बहुत अधिक दिलचस्प हिस्सा।

Dom0 में, यह एक विशेष xenconsoled डेमॉन को सुनता है (वैसे, IBM से, XenSource नहीं)। आप शायद उसके लिए एक विकल्प लिख सकते हैं, लेकिन मैंने अभी तक ऐसे डेयरडेविल्स नहीं देखे हैं।

Xenconsoled रिंग बफ़र की सामग्री प्राप्त करने और ईवेंट चैनल पर ईवेंट भेजने में शामिल सभी बकवास करता है।

डोमेन व्यवस्थापक को कंसोल तक पहुंच देने के लिए, xenconsoled एक pseudo-टर्मिनल बनाने के लिए unix98 तंत्र का उपयोग करता है। अधिक सटीक रूप से, दो डिवाइस बनाए जाते हैं, एक अदृश्य लूपबैक द्वारा एक दूसरे से जुड़े होते हैं। उनमें से एक डिवाइस के रूप में भी प्रकट नहीं होता है, लेकिन एक फ़ाइल हैंडलर के साथ एक अमूर्त बना रहता है, और दूसरा / dev / pty / में दिखाई देता है। वास्तव में, जो कुछ भी / dev / pty / X को लिखा जाएगा वह पढ़ते समय इस हैंडलर से बाहर निकल जाएगा। आक्षेप भी सत्य है - इस हैंडलर को क्या लिखा जाएगा / देव / पीटी / एक्स से बाहर निकल जाएगा। मुझे लगता है कि यह स्पष्ट है कि xenconsoled हैंडलर के डेटा के साथ क्या करता है। उन्हें रिंग बफर कंसोल में लिखता है। और वहीं से पढ़ता है, उसी हैंडलर को लिखता है।

जब एक नया डोमेन दिखाई देता है, तो xenconsoled xenstore में इसके लिए / dev / pty / X का पथ लिखता है (उदाहरण के लिए, / dev / pty / 0, / dev / pty / 1)। जैसे ही डोमेन गायब हो जाता है (रिबूट, शटडाउन, माइग्रेशन), छद्म टर्मिनल गायब हो जाता है।

इससे क्या लेना-देना / देव / दया? ठीक है, वास्तव में, किसी भी कॉम-पोर्ट के समान, जिसके पीछे एक कंप्यूटर, राउटर, आदि है। एक टर्मिनल के साथ कनेक्ट करें। दोस्त पोटीन या किसी अन्य ग्राफिक टर्मिनल का उपयोग कर सकते हैं, अन्य लोग मिनिकॉम के साथ मिल सकते हैं। Xena के लिए एक विशेष टर्मिनल xenconsole (/ usr / (local) / lib / xen / bin / xenconsole लिखा गया है, जो आपको Ctrl-] संयोजन का उपयोग करके डिस्कनेक्ट करने की अनुमति देता है।

यह उसकी तरह से है, कि xm कंसोल लॉन्च होता है (xl कंसोल भी)।

जादू का पता चला है? हां। इसके बाद शुरू होता है 'मूल्य वर्धित सेवाएं'। अगर हम वर्चुअलाइजेशन सेवाएं प्रदान करते हैं और हम लोगों को डोमिन के लिए प्रशासक के अधिकार दिए बिना उनकी वर्चुअल मशीन के कंसोल को देखने का अवसर देना चाहते हैं ...

तब सब कुछ बहुत सरल है। Xenconsole का एक विकल्प vncterm है (एक विशेष कार्यक्रम जो एक चरित्र डिवाइस को "लेता है" और उससे एक वीएनसी कनेक्शन बनाता है), जिससे आप वीएनसी के माध्यम से कंसोल को देख सकते हैं। VNCterm एक छद्म टर्मिनल से जुड़ा हुआ है, वहां से बाइट्स प्राप्त करता है, उन्हें (कंसोल_कोड) खींचता है और, यदि कोई उपयोगकर्ता VNC से जुड़ा है, तो उसे एक वीडियो स्ट्रीम भेजता है। उससे, वह उन्हें छद्म टर्मिनल (और आगे श्रृंखला के साथ) भेजने के लिए बटन प्राप्त करता है।

ग्राहकों के लिए कंसोल तक पहुंचने की इस पद्धति में कई कमियां हैं: सबसे पहले, वीएनसी को आमतौर पर एन्क्रिप्ट नहीं किया जाता है। दूसरे, इसे कनेक्ट करने के लिए एक अलग पासवर्ड की आवश्यकता होती है। तीसरा, कंप्यूटर के माइग्रेट या रिबूट होने पर कनेक्शन टूट जाता है (क्योंकि डोमेन नया है, यह पूरी तरह से अलग VNCterm के लिए "सुनना" है)।

ग्राफिकल कंसोल?

ज़ेन ग्राफिकल कंसोल के लिए एक पूरी तरह से अलग तंत्र का उपयोग करता है - फ्रेमबफ़र। पिक्सेल क्षेत्र जिसमें वर्चुअल मशीन लिख सकता है, और जहां कंसोल ड्राइवर इस डेटा को पढ़ता है। कंसोल डेटा (रिज़ॉल्यूशन और कलर डेप्थ) की घोषणा एक्सनस्टोर के माध्यम से की जाती है। चिकना और कॉम्पैक्ट टेक्स्ट कंसोल के विपरीत, फ़्रेमबफ़र बहुत बड़ा है। उदाहरण के लिए, 1920x1050 के रिज़ॉल्यूशन में, यह 8 मेगाबाइट जितना है। इसके अलावा, सभी त्वरण की, केवल छवियों को ऊपर स्क्रॉल करना उपलब्ध है।

दरअसल, Xen फ्रेमबफ़र को विशेष रूप से HVM मोड (इस लेख के दायरे से परे) के लिए जोड़ा गया था, और एचवीएम मोड स्वयं काफी हद तक माइक्रोसॉफ्ट विंडोज के अस्तित्व के कारण था, जो कि कोर सर्वर में अभी भी पाठ कंसोल में बूट करना नहीं सीख पाया था। हालांकि, एचवीएम को लिनक्स के लिए भी सफलतापूर्वक उपयोग किया जाता है, लेकिन एचवीएम की क्षमता और प्रदर्शन पीवी मोड से नीच हैं।

फ़्रेमबफ़र में एक और सिरदर्द माउस है। जाहिर है, माउस के बिना, विंडोज स्क्रू अच्छा नहीं है, इसलिए आपको अलग से कीबोर्ड के लिए, माउस के लिए, और फ्रेमबफ़र अपडेट के लिए रिंग बफर बनाना होगा। एक ही समय में, अपेक्षाकृत शांत कीबोर्ड के विपरीत, एक माउस को बहुत अधिक गति की आवश्यकता होती है (दोनों माउस आंदोलन के बारे में संदेश प्रसारित करने और प्रतिक्रिया देने में देरी के संदर्भ में)।

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

तीसरा तरीका

बस पूर्णता के लिए, मुझे इसका भी उल्लेख करना चाहिए - डोमु में आप भौतिक उपकरणों को "आगे" कर सकते हैं। उदाहरण के लिए, एक वीडियो कार्ड। इस मामले में, डोमेन सामान्य वीडियो कार्ड के साथ एक पर एक होता है और इसके साथ जो चाहें वह कर सकता है। जिसमें ओपेंग्ल और अन्य डायरेक्टेक्स शामिल हैं। हालाँकि, वीडियो कार्ड केवल एक डोमेन (दो वीडियो कार्ड - दो डोमेन, आदि) के लिए उपलब्ध है, इसके अलावा, आपको प्रवासन के बारे में भूल जाना चाहिए, क्योंकि इस संभावना के बाद कि ड्राइवर निलंबित हो जाएगा वीडियो कार्ड को प्रारंभिक रूप से ठीक करने में सक्षम है कुछ विवादास्पद है। वास्तविक जीवन में (सर्वर वर्चुअलाइजेशन में), इस पद्धति का उपयोग नहीं किया जाता है।

पाठ कंसोल का भविष्य

वर्तमान में, Xen4 सक्रिय रूप से कई कंसोल के लिए समर्थन पूरा कर रहा है। "डिबग" के विपरीत, मुख्य कंसोल, उन्हें एक्सनस्टोर के माध्यम से घोषित किया जाएगा, और उनके काम के सिद्धांतों से वे मौजूदा "केवल" एक से बहुत अलग नहीं होंगे।