इस लेख में
- Broadcom ने बिना बताए VMware से निकलने का टूल हटा दिया
- VDDK क्या है, और अगर आपने इसके बारे में कभी नहीं सुना तब भी यह क्यों मायने रखता है
- असल में क्या हुआ
- कोई वैकल्पिक रास्ता क्यों नहीं है
- असली सबक: निकासी लागत ही लॉक-इन का पैमाना है
- व्यवहार में अपनी निकासी लागत कैसे मापें
- Origami में हम इसे कैसे संभालते हैं
- स्रोत
Broadcom ने बिना बताए VMware से निकलने का टूल हटा दिया
अगस्त 2026 के आखिर से, Broadcom के डेवलपर पोर्टल पर VMware की VDDK लाइब्रेरी के डाउनलोड पेज 404 लौटा रहे हैं — न कोई घोषणा, न बंद किए जाने की कोई सूचना, और न ही कोई बताया गया विकल्प। यह लाइब्रेरी ज़्यादातर लोगों के लिए अनजानी है, लेकिन इस पर निर्भर टूल अनजाने नहीं हैं: VMware सर्वरों के लिए इमेज-स्तर के बैकअप उत्पाद, और VMware से दूसरे प्लेटफ़ॉर्म पर जाने के लिए इस्तेमाल होने वाले टूल। व्यावहारिक नतीजा यह है कि VMware से निकलने पर विचार कर रही एक कंपनी ने पाया कि निकलने का आधिकारिक रास्ता बंद है। और यह सबक हर सिस्टम मालिक पर लागू होता है, चाहे वह VMware इस्तेमाल करता हो या नहीं: किसी वेंडर पर आपकी निर्भरता सब्सक्रिप्शन की कीमत से नहीं मापी जाती। यह इससे मापी जाती है कि छोड़ने में आपको कितना समय, पैसा और विशेषज्ञता लगेगी।
VDDK क्या है, और अगर आपने इसके बारे में कभी नहीं सुना तब भी यह क्यों मायने रखता है
VDDK का पूरा नाम Virtual Disk Development Kit है। यह वह लाइब्रेरी है जो हाइपरवाइज़र के बाहर के सॉफ़्टवेयर को VMware की वर्चुअल डिस्क पढ़ने और लिखने देती है। सरल शब्दों में: यह वह पुल है जिसे हर प्रोग्राम पार करता है जब वह किसी वर्चुअल सर्वर की कॉपी लेना या उसे कहीं और ले जाना चाहता है।
इसीलिए यह उन टूल के केंद्र में है जिनका Broadcom से कोई स्पष्ट संबंध नहीं है। ओपन-सोर्स रूपांतरण इंजन virt-v2v, जिस पर VMware से KVM माइग्रेशन का ज़्यादातर काम टिका है, इसे इनपुट ट्रांसपोर्ट के रूप में सपोर्ट करता है। Apache CloudStack का माइग्रेशन मार्ग पहले पूरी OVF फ़ाइल निर्यात करने के बजाय डिस्क ब्लॉक सीधे स्ट्रीम करने के लिए इसका उपयोग करता है। और vSphere वर्चुअल मशीन की इमेज-स्तर की कॉपी लेने वाला हर बैकअप उत्पाद शृंखला में कहीं न कहीं इससे होकर गुज़रता है।
मुख्य बात: VMware चलाते रहने के लिए आपको VDDK की ज़रूरत नहीं है। इसकी ज़रूरत तेज़ी से छोड़ने के लिए, और फ़ैसला लेते समय जो चल रहा है उसे सुरक्षित रखने के लिए है।
असल में क्या हुआ
ShapeBlue ने 25 अगस्त 2026 को इस बदलाव को दर्ज किया: Apache CloudStack की आधिकारिक प्रशासन गाइड लाइब्रेरी डाउनलोड करने के लिए जिस पेज की ओर इशारा करती है, वह त्रुटि लौटाता है, और पोर्टल पर बाकी हर VDDK पथ भी, जिनमें संस्करण 8 और संस्करण 9 के विशिष्ट पथ शामिल हैं। उन्होंने यूरोप से, और संयुक्त राज्य अमेरिका, ब्राज़ील, फ़िनलैंड और जापान के एग्ज़िट नोड के ज़रिए जाँच की, और हर जगह एक ही नतीजा मिला — इसलिए यह न कोई स्थानीय गड़बड़ी है और न ही भौगोलिक रोक।
इससे भी अजीब बात यह है कि बदलाव की व्याख्या करने वाली Broadcom की कोई घोषणा नहीं है। न चरणबद्ध तरीके से बंद करने की सूचना, न डेटा प्रतिधारण नीति, और न ही किसी ग्राहक या छोटे वेंडर के लिए लाइब्रेरी पाने का कोई बताया गया रास्ता। CloudStack की आधिकारिक गाइड अब भी उपयोगकर्ताओं को ऐसे लिंक की ओर भेजती है जो अब काम नहीं करता। यह लेख लिखते समय हमने खुद लिंक की जाँच की और 404 मिला, जबकि CloudStack गाइड का पेज सामान्य रूप से खुलता है।
सिस्टम चलाने के लिए आपको लाइब्रेरी की ज़रूरत नहीं है। छोड़ने के लिए उसकी ज़रूरत है। ठीक यही बात उसकी अनुपस्थिति को अहम बनाती है।
कोई वैकल्पिक रास्ता क्यों नहीं है
आमतौर पर जब कोई ऐसी फ़ाइल गायब होती है जिसकी सबको ज़रूरत है, तो तकनीकी समुदाय उसका रास्ता निकाल लेता है: कोई उसका मिरर बना देता है, कोई उसे पैकेज कर देता है, और कहानी किसी दस्तावेज़ पेज पर एक फ़ुटनोट बनकर खत्म हो जाती है। लेकिन VDDK का लाइसेंस सामान्य पुनर्वितरण की अनुमति नहीं देता। कोई Linux वितरण इसे शामिल नहीं करता, कोई कंटेनर इमेज इसे बंडल नहीं करती, और हस्ताक्षरित पुनर्वितरण समझौते के बिना कोई भी बैकअप वेंडर इसे अपने इंस्टॉलर में नहीं रख सकता।
इससे तस्वीर पूरी हो जाती है: एक अकेला URL पूरे सॉफ़्टवेयर इकोसिस्टम के लिए कठोर निर्भरता बन गया, और जिस लाइसेंस ने यह निर्भरता बनाई, वही स्पष्ट उपाय को रोकता है। बाइनरी फ़ाइलों का कहीं और मिरर बनाने से कुछ ठीक नहीं होता — इससे कानूनी जोखिम बस उन्हें होस्ट करने वाले पर चला जाता है।
नुकसान भी बराबर नहीं बँटता। साझेदारी वाले बड़े बैकअप वेंडर के पास फ़ोन करने के लिए कोई है। तीन लोगों की एक माइग्रेशन कंसल्टेंसी, एक ओपन-सोर्स प्रोजेक्ट, या अपने ही वर्कलोड को बदल रहे ग्राहक के पास बस एक फ़ोरम पोस्ट और एक त्रुटि पेज है।
असली सबक: निकासी लागत ही लॉक-इन का पैमाना है
सिस्टम खरीदने के ज़्यादातर फ़ैसले कीमतों और सुविधाओं की तुलना करके लिए जाते हैं। यह आधा मूल्यांकन है। बाकी आधा एक सवाल है: अगर तीन साल बाद हम इस वेंडर को छोड़ने का फ़ैसला करें, तो इसकी हमें क्या कीमत चुकानी होगी?
VDDK के साथ जो हुआ, वह दिखाता है कि निकासी लागत तय नहीं होती। वेंडर इसे बाद में, एकतरफ़ा तौर पर और कभी-कभी बिना किसी घोषणा के बढ़ा सकता है। पाँच साल पहले VMware के साथ अनुबंध करने वाली कंपनी ने कीमत और प्रदर्शन का मूल्यांकन किया था। उसे नहीं पता था कि उत्पाद का स्वामित्व बदल जाएगा, न ही यह कि निकासी का टूल पोर्टल से चुपचाप गायब हो जाएगा।
व्यवहार में अपनी निकासी लागत कैसे मापें
किसी भी नए अनुबंध से पहले, और किसी भी मौजूदा अनुबंध का नवीनीकरण करने से पहले, ये सवाल पूछें और उत्तर लिखित में लें:
- क्या मेरा डेटा खुले फ़ॉर्मेट में निर्यात किया जा सकता है? स्प्रेडशीट में आंशिक डंप नहीं — बल्कि डेटा और रिकॉर्ड के बीच संबंधों का पूरा निर्यात, ऐसे फ़ॉर्मेट में जिसे कोई दूसरा सिस्टम पढ़ सके।
- क्या निकासी का टूल खुद वेंडर का है? अगर बाहर निकलने का एकमात्र रास्ता उसी पक्ष के नियंत्रण वाले टूल से होकर जाता है जिसे आप छोड़ना चाहते हैं, तो आपके पास निकासी योजना नहीं है। आपके पास बस एक उम्मीद है।
- अगर अनुबंध अचानक रुक जाए तो मेरे पास क्या बचेगा? एक स्पष्ट शर्त माँगें जो संबंध किसी भी कारण से खत्म होने पर तय समय-सीमा के भीतर डेटा और दस्तावेज़ सौंपने की गारंटी दे।
- क्या हमने सचमुच छोड़कर देखा है? जिस निकासी योजना को कभी परखा न गया हो, वह योजना नहीं है। साल में कम से कम एक बार पूरा निर्यात करें, और पुष्टि करें कि वह कहीं और आयात हो जाता है।
- माइग्रेशन में कितना समय लगेगा, आँकड़ों में? दिनों और लागत का ईमानदारी से अनुमान लगाएँ। अगर उत्तर "हमें नहीं पता" है, तो वह भी एक उत्तर है — और इसका मतलब है कि आपकी निर्भरता आपकी सोच से ज़्यादा है।
Origami में हम इसे कैसे संभालते हैं
हम एक टेक्नोलॉजी कंपनी हैं, और हम ग्राहकों के सिस्टम इस सिद्धांत पर बनाते हैं कि कोड और डेटा ग्राहक के हैं। व्यवहार में इसका मतलब है एक मानक डेटाबेस जिसे कोई भी दूसरी टीम पढ़ सके, दस्तावेज़ जो माँगने पर नहीं बल्कि सिस्टम के साथ ही सौंपे जाएँ, और ऐसे API जो डेटा के टुकड़े नहीं बल्कि पूरा डेटासेट निर्यात करें। हम यह इसलिए नहीं कहते कि संबंध अस्थायी है — हम यह इसलिए कहते हैं कि जो ग्राहक जानता है कि वह छोड़ सकता है, वह अपनी मर्ज़ी से टिका रहता है।
और जब किसी तीसरे पक्ष के उत्पाद पर निर्भर रहना ज़रूरी हो, जो अक्सर होता है, तो हम डिज़ाइन दस्तावेज़ में लिखते हैं कि अगर वह पक्ष गायब हो जाए तो क्या होगा: विकल्प क्या है, बदलाव में कितना समय लगेगा, और सिस्टम के कौन से हिस्से प्रभावित होंगे। यह दस्तावेज़ में बस एक पेज है, लेकिन यही अचानक आई मुसीबत और योजनाबद्ध कदम के बीच का फ़र्क है।
स्रोत
सामान्य प्रश्न
मैं VMware का उपयोग नहीं करता — क्या यह खबर मुझ पर असर डालती है?
हाँ, क्योंकि यह सबक उत्पाद के बारे में नहीं, बल्कि सिद्धांत के बारे में है। आज आप जिस भी सिस्टम पर निर्भर हैं — लेखा, पॉइंट ऑफ सेल, होस्टिंग, कोई आर्टिफिशियल इंटेलिजेंस सेवा — उसकी एक निकासी लागत होती है। फर्क बस इतना है कि कुछ कंपनियाँ अपना आँकड़ा जानती हैं और कुछ उसे सबसे बुरे समय पर पता लगाती हैं। अपने डेटा को खुले फ़ॉर्मेट में निर्यात करने के बारे में अनुबंध पर हस्ताक्षर करने से पहले पूछें, बाद में नहीं।
VDDK असल में क्या है, और इसे हटाया जाना क्यों मायने रखता है?
यह VMware की एक लाइब्रेरी है जो हाइपरवाइज़र के बाहर के सॉफ़्टवेयर को वर्चुअल डिस्क पढ़ने और लिखने देती है। इमेज-स्तर के बैकअप उत्पाद और VMware से दूसरे प्लेटफ़ॉर्म पर माइग्रेशन के टूल इस पर निर्भर हैं। VMware चलाने के लिए आपको इसकी ज़रूरत नहीं है, लेकिन VMware छोड़ने के लिए, या फ़ैसला लेते समय अपने वर्कलोड को सुरक्षित रखने के लिए इसकी ज़रूरत है।
मैं अपने मौजूदा सिस्टम की निकासी लागत कैसे पता करूँ?
सचमुच छोड़कर देखें। अपने डेटा का किसी मानक फ़ॉर्मेट में पूरा निर्यात माँगें, पुष्टि करें कि वह किसी दूसरे सिस्टम में आयात हो जाता है, और दर्ज करें कि इसमें कितना समय लगा और कितना खर्च हुआ। बिना परखी गई योजना योजना नहीं होती, और "हमें नहीं पता" ऐसा उत्तर है जिसका मतलब है कि आपकी निर्भरता आपके अनुमान से ज़्यादा है।
क्या लॉक-इन से बचने का उपाय सब कुछ खुद बनाना है?
नहीं — सब कुछ खुद बनाना महँगा और धीमा है, और यह एक अलग तरह की निर्भरता पैदा करता है: अपनी ही टीम पर निर्भरता। उपाय है सोची-समझी निर्भरता। जहाँ उपयुक्त हों, तैयार उत्पादों का उपयोग करें, लेकिन डेटा के स्वामित्व और उसे निर्यात कर पाने की शर्त रखें, और अपने डिज़ाइन दस्तावेज़ में हर महत्वपूर्ण तीसरे पक्ष का विकल्प और बदलाव में लगने वाला समय लिखें।
Google पर Origami को फ़ॉलो करें
Origami को अपना पसंदीदा स्रोत बनाइए, तो हमारे लेख आपको Google Search और प्रमुख ख़बरों में सबसे पहले दिखेंगे।








