3 पॉइंट द्वारा GN⁺ 2026-02-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS SDK for Go v2 के अपडेट के साथ, वर्चुअल मशीन के भीतर एक और वर्चुअल मशीन चलाने की क्षमता जोड़ी गई
  • यह नया फीचर अब non-bare-metal EC2 instances पर भी nested VM चलाना संभव बनाता है
  • AWS EC2 में nested virtualization सपोर्ट का विस्तार डेवलपमेंट और टेस्टिंग environments में virtualization layers के उपयोग को बढ़ाने की आधारशिला बन सकता है

1 टिप्पणियां

 
GN⁺ 2026-02-13
Hacker News की राय
  • अब AWS VM के अंदर सीधे Firecracker या दूसरे microVM चलाना संभव हो गया है, यह बड़ा बदलाव है
    पहले ऐसा करने के लिए महंगे bare-metal instance की ज़रूरत पड़ती थी
    संदर्भ के लिए, GCP काफ़ी पहले से nested virtualization को सपोर्ट करता था
    • मैं इसी तरह की टिप्पणी का इंतज़ार कर रहा था। Firecracker जैसे microVM वास्तव में एक अच्छा use case हैं
      सिर्फ़ test या development environment को आसानी से सेटअप कर पाना भी एक फ़ायदा है
      nested virtualization का मतलब ज़रूरी नहीं कि केवल पूरा VM ही हो
    • मुझे जानना है कि ऐसे environment में performance degradation कितना होता है
  • nested virtualization सपोर्ट अब प्रमुख SDKs में जोड़ दिया गया है
    us-west-2 region में “Nested Virtualization” विकल्प पहले से दिख रहा है, और यह M8id / C8id / R8id instance types पर उपलब्ध है
    E2B जैसी micro-VM sandbox solution, जिसमें मैं शामिल हूँ, के लिए यह सच में बड़ी ख़बर है
  • क्या कोई समझा सकता है कि यह इतना बड़ा मामला क्यों है?
    पहले जब मैंने nested virtualization को आज़माया था, तब PoC स्तर से आगे यह ज़्यादा उपयोगी नहीं लगा था
    • isolation के लिहाज़ से यह बहुत उपयोगी है
      Kata Containers, gVisor, Firecracker जैसे VM-आधारित container solutions काफ़ी हैं
      उदाहरण के लिए, Kubernetes के pod को VM इकाई पर isolate किया जा सकता है
      साथ ही EC2 instances के बीच live migration संभव हो जाती है, जिससे लगातार चलने वाले workloads का maintenance आसान हो जाता है
      CI/CD environment में system images को सीधे EC2 पर build और test करना भी संभव हो जाता है, इसलिए यह काफ़ी सुविधाजनक है
      GCP, VMWare, KVM आदि पहले से यह सुविधा दे रहे थे, इसलिए EC2 का अब जाकर पहुँचना थोड़ा खलता था
    • अब पूरा bare-metal instance इस्तेमाल किए बिना, सस्ते AWS instances के अंदर VM चलाए जा सकते हैं
      QEMU के साथ network hardware को emulate करने वाली network simulation जैसी चीज़ों में यह ख़ास तौर पर उपयोगी है
  • ऐसा लग रहा है कि AWS अब जाकर 2018 में पहुँचा है
    • सही है, यह काफ़ी सामान्य बात है
      मैं घर पर भी बहुत पहले से libvirt के साथ consumer hardware पर यह इस्तेमाल करता रहा हूँ
      AWS ने अब आकर इस पुराने feature को catch up किया है
  • सोच रहा हूँ कि क्या यह openclaw या agents जैसी चीज़ों में भी उपयोगी होगा
    • संभव है, लेकिन actual deployment के लिए मैं शायद nested virtualization की जगह nix से image build करने का तरीका चुनूँगा
  • nested virtualization environment में performance numbers, ख़ासकर IO-केंद्रित workloads के लिए, जानने की उत्सुकता है
  • आम तौर पर nested virtualization का performance impact कितना होता है, यह जानना चाहता हूँ
    लगता है कि MMU overhead कई परतों में जुड़ जाएगा
    • यह workload और implementation पर निर्भर करता है
      pure CPU tasks पर लगभग कोई असर नहीं होता, लेकिन IO में implementation के हिसाब से लगभग कोई फ़र्क नहीं से लेकर बहुत ख़राब तक हो सकता है
      trap/vmexit जैसे events को एक अतिरिक्त layer से होकर गुजरना पड़ता है
    • जहाँ तक मुझे याद है, virtualization instructions खुद nested नहीं होतीं, बल्कि बाहरी virtualization hardware के साथ cooperative तरीके से काम करती हैं
      AWS की implementation भी यही तरीका अपनाती है या नहीं, यह पक्का नहीं है
    • व्यावहारिक रूप से देखें तो लगभग 5~15% performance degradation होता है
  • legacy apps के लिए यह महंगा पड़ने वाला काम लगता है
  • आखिरकार यह आ गया, यही सोच रहा हूँ, उत्साह चरम पर है