Zfs: फ़ीचर अनुरोध - ऑनलाइन विभाजन क्लोन

ऐसा लगता है कि zfs promote पहले से ही आपकी आवश्यकता है।

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

मैं देख रहा था zfs को बढ़ावा देने के लिए, लेकिन यह सिर्फ माता पिता के बच्चे के रिश्ते फ्लिप करने के लिए प्रतीत होता है ...

मैं सोच रहा था कि एक अंतिम स्थिति थी जहां दोनों फाइल सिस्टम एक दूसरे से पूरी तरह से स्वतंत्र हैं ...

इसके लिए कुछ उपयोग के मामले हो सकते हैं
VM टेम्प्लेट्स को क्लोन करना - एक बेस इमेज होना जो दूसरे VM को बनाने के लिए क्लोन किया गया हो, जो कि टेंपरेचर से अलग-अलग हों, ताकि टेम्प्लेट को अपडेट / नष्ट / रीक्रिएट किया जा सके।
डेटाबेस क्लोन - देव के लिए एक ठेस db का क्लोन करना जो बहुत सारे बदलावों से गुजरना होगा और जो बदले में एक परीक्षण क्लोन के लिए आधार हो सकता है, इस मामले में देव को ठेस से अलग करना अच्छा होगा क्योंकि आधार स्नैपशॉट बड़ा हो सकता है देव के लिए एक स्वतंत्र फाइल सिस्टम होने से

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

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

केवल इसके विपरीत यह है कि मूल @ स्नैपशॉट (= क्लोन का आधार) में आयोजित सभी _unique_ डेटा तब तक जारी नहीं किए जा सकते जब तक कि आप क्लोन (ओं) को नष्ट करने के लिए तैयार न हों या (क्लोन के प्रचार के बाद) मूल।

@ अंत में greg- हाइड्रोजन ने निर्धारित किया कि क्या zfs promote आपकी आवश्यकताओं को पूरा करते हैं? या यहाँ अभी भी एक संभावित सुविधा अनुरोध है।

इस पर टिप्पणी करने के लिए, यह अच्छा होगा यदि मूल-क्लोन संबंधों को एक काटे हुए रूप में बदलने के लिए एक कार्यक्षमता होगी: डेटासेट्स को व्यक्तिगत रूप से नष्ट होने से रोकने वाले तार्किक लिंक को हटा दिया जाएगा - जबकि अभी भी साझा की गई केवल एक प्रति बनाए रखना डेटा।

@behlendorf : यह लगभग निश्चित रूप से जरूरत को पूरा नहीं करता है।
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
समस्या को समझाने का अच्छा काम करता है।

यहां मैं वैचारिक रूप से करने की कोशिश कर रहा हूं:

उपयोगकर्ता @ बैकअप :

1. दिनांक आधारित स्नैपशॉट जनरेट करें
2. दर्पण के रूप में परीक्षण करने के लिए इसे बैकअप से भेजें

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

उपयोगकर्ता @ परीक्षण :

1. दर्पण को पवित्र करने के लिए एक जगह बनाएं
2. इसे पवित्र करें
3. इसे स्नैपशॉट
4. उपयोग के लिए स्वच्छता संस्करण का क्लोन
5. इसका इस्तेमाल करें

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

उपयोगकर्ता @ बैकअप :

1. आगे उत्पादन का उपयोग किया जा रहा है ...
2. एक अद्यतन स्नैपशॉट बनाएँ
3. परीक्षण करने के लिए ठेस से वृद्धिशील परिवर्तन भेजें
4. पिछले वृद्धिशील मार्कर को हटा दें (जो मेरे मामले में 70 जीबी को मुक्त करता है)

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

उपयोगकर्ता @ परीक्षण :

• यह वह जगह है जहाँ समस्याएं दिखाई देती हैं।
• काजोलिंग की कुछ मात्रा के साथ, कोई सैनिटाइजिंग वॉल्यूम को नष्ट कर सकता है।
• लेकिन, मैं test/mirror@20170901 साथ बचा हुआ हूं जो दो शेष चीजों के लिए मूल है: test/mirror@20170908 और test/test ।
• अगर मैं चाहता था कि मैं अपडेटेड मिरर ( test/mirror@20170908 ) को नष्ट कर दूं, लेकिन इससे मुझे कोई फायदा नहीं होगा (क्योंकि मेरा लक्ष्य उस डेटा का उपयोग करना है)।

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

Fwiw, इसका स्वाद पाने के लिए ...:

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

(संख्या वास्तव में गलत हैं, मेरे पास वास्तव में 4 निहित मात्राओं के साथ 1 मात्रा है, इसलिए पुनरावर्ती झंडे हैं ...)

अब, मैं समझता हूं कि मैं निर्भरता को तोड़ने के लिए zfs send | zfs recv का उपयोग कर सकता हूं, और छोटी चीजों के लिए जो ठीक है। लेकिन मेरे पूल का यह हिस्सा लगभग पूल में उपलब्ध स्थान से दोगुना है, और एक आधा शायद इससे बड़ा है, जिसका अर्थ है कि ऑपरेशन करना समस्याग्रस्त है। यह भी बाइट्स की एक बड़ी राशि है। स्नैपशॉट का उपयोग करने में मेरी आशा को गाय से लाभ होने में सक्षम होना था, लेकिन इसके बजाय, मुझे गाय के लिए शुल्क लिया जा रहा है, क्योंकि शाखा बिंदु जो अंततः मेरे ब्रांचिंग पेड़ के दोनों ओर से उपयोग किए गए डेटा के लिए अभी भी भुगतान किया जाना चाहिए।

@behlendorf हाय, इस पर कोई प्रगति? मूल फाइल सिस्टम से स्प्लिट क्लोनिंग VMs टेम्प्लेट और / या बड़े फ़ाइल-लेवल रिस्टोर के लिए वास्तव में बहुत अच्छा होगा। व्यावहारिक उदाहरण के लिए ऊपर दिए गए लिंक @jsoref को देखें।

@kpande : लक्ष्य क्या है (अंतरिक्ष और डेटा ट्रांसफर में) जो कि बदल गया है (गाय) के लिए, पूरे डेटासेट के लिए नहीं (हर बार जब यह ऑपरेशन होता है)।

अगर मेरे पास 10TB मूविंग डेटासेट है, और जिस डेटासेट को मैं स्थापित करना चाहता हूं, उसका एक वेरिएशन, निश्चित रूप से, मैं 10TB को कॉपी कर सकता हूं, भिन्नता लागू कर सकता हूं और 20TB के लिए भुगतान कर सकता हूं (यदि मेरे पास 20TB उपलब्ध है)। लेकिन, अगर मेरी भिन्नता वास्तव में मूल 10TB से केवल 10MB अलग है, तो मुझे 10TB + 10MB के लिए भुगतान करने में सक्षम क्यों नहीं होना चाहिए? - स्नैपशॉट + क्लोन मुझे वह देते हैं। जब तक 10TB पर्याप्त रूप से आगे नहीं बढ़ जाता है, तब तक मैं 10TB (लाइव + 10TB स्नैपशॉट + 10TB डायवर्जेड) के लिए भुगतान कर रहा हूं और मेरी 10MB भिन्नता चलती है, इसलिए यह अब अपना 10TB (लाइव और स्नैपशॉट दोनों से परिवर्तित) है। अंतरिम रूप से, मेरी 30TB समस्या को "ठीक" करने के लिए, मुझे एक और 10TB (= 40TB - अपने zfs सेंड + zfs recv के माध्यम से) खर्च करना होगा। यह आदर्श नहीं है। निश्चित रूप से, यह "काम" करेगा, लेकिन यह न तो "तेज" है और न ही दूरस्थ रूप से कुशल है।

Redacted भेजें / recv दिलचस्प लगता है (क्योंकि यह कम या ज्यादा मेरे उपयोग के मामले से मेल खाता है) - लेकिन जब मैं इसे स्थानों के एक समूह में उल्लिखित पा सकता हूं, तो मैं वास्तव में इसे कम करने के बारे में कोई उपयोगी स्पष्टीकरण नहीं पा सकता हूं।

Fwiw, हमारे सिस्टम के लिए, मैंने स्विच किया ताकि सैनिटाइजिंग सेंडिंग साइड (जो गोपनीयता के नजरिए से भी बेहतर हो) पर होता है, जो ज्यादातर हमें जंगल से बाहर निकलता है।

ऐसे उदाहरण हैं जहां डेटा भिन्नता "रिडक्टिंग" नहीं है और जहां सिस्टम में zfs स्नैपशॉट + zfs के लिए संसाधन हैं, लेकिन वास्तव में "म्यूटेशन" करने के लिए दूसरे डेटाबेस को होस्ट करने के लिए संसाधन आवंटित नहीं करना चाहते हैं - और प्राथमिक और द्वितीयक के बीच की पूरी मात्रा भेजने के लिए भुगतान नहीं करना चाहता (अर्थात यह सिस्टम में वृद्धिशील स्नैपशॉट भेजेगा जो पहले से ही स्नैपशॉट है)।

हां, मुझे पता है कि मैं डिडअप का उपयोग कर सकता हूं। हम अपने cpus / ram के लिए भुगतान कर रहे हैं, इसलिए निरंतर cpu + ram को एक दुर्लभ कार्य (ताज़ा उत्परिवर्तित क्लोन) बनाने के लिए समर्पित करना एक खराब ट्रेडऑफ़ की तरह महसूस किया (मैं थोड़ा और डिस्क स्थान के लिए भुगतान करता हूं)।

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

लेकिन मुझे और अधिक व्यावहारिक उदाहरण दें।

दैनिक आधार पर लिए गए स्नैपशॉट के साथ kvm/vmimages को कई वर्चुअल डिस्क छवियों के लिए एक डेटस्टोर कंटेनर होने दें। मुझे पता है कि डिफ़ॉल्ट उत्तर "प्रत्येक डिस्क के लिए एक डेटासेट का उपयोग" होगा, लेकिन libvirt पूल इसके साथ अच्छी तरह से नहीं खेलते हैं। तो हमारे पास कुछ इस प्रकार है:

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

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

क्लोन एक संभावित समाधान के रूप में दिमाग में आते हैं: आप प्रभावित वीएम के लिए तुरंत सेवा बहाल करने के लिए kvm/vmimages@snap3 kvm/restored क्लोन कर सकते हैं। तो अब आपके पास है:

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

प्रभावित VM kvm/restored से चलता है, जबकि अन्य सभी kvm/vmimages । इस बिंदु पर, आप kvm/restored से सभी अतिरिक्त डिस्क को हटाते हैं और kvm/vmimages से मूल, दूषित डिस्क। सब कुछ ठीक लगता है, जब तक आपको एहसास नहीं होता है कि पुरानी दूषित डिस्क छवि अभी भी असली डिस्क स्थान का उपयोग कर रही है, और kvm/restored में किसी भी ओवरराइट को पुराने, अपरिवर्तनीय kvm/vmimages@snap3 कारण अतिरिक्त स्थान की खपत होती है। आप अपने क्लोन भी निकाले बिना ही इस पुराने स्नैपशॉट नहीं निकाल सकते हैं, और आप बस प्रचार नहीं कर सकते kvm/restored और हटाने के kvm/vmimages क्योंकि यह केवल सच "आधिकारिक" डेटा स्रोत नहीं है (यानी: वास्तविक डेटा कर रहे हैं दोनों डाटासेट के अंदर संग्रहीत)।

अपने स्रोत से एक क्लोन को विभाजित करने से ऊपर की समस्या पूरी तरह से हल हो जाएगी। मेरे लिए यह स्पष्ट नहीं है कि इस मामले में कैसे भेजा / वापस लाया जाएगा।

@kpande पहले, अपने विचार और आपके समाधान को साझा करने के लिए धन्यवाद (जो दिलचस्प है!)। मैं पूरी तरह से सहमत हूं कि एक सावधान, और बहुत विशिष्ट, अतिथि कॉन्फ़िगरेशन (और होस्ट डेटा ट्री) ऊपर बताई गई समस्या से बच सकता है।

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

चक्कर की वर्तमान स्थिति के साथ, कि ऐसा करने से भारी आबंटित स्थान में, कर के रूप में आप कभी भी मूल स्नैपशॉट दूर करने के लिए, संभावित अप्रचलित, सक्षम नहीं होगा होगा। क्या आश्चर्य की बात है कि, ZFS एक CoW फाइलसिस्टम होने के नाते, यह एक रिश्तेदार सरल ऑपरेशन होना चाहिए: जब मूल स्नैपशॉट को हटा दिया जाता है, तो किसी भी गैर-संदर्भित ब्लॉक के रूप में "बस" निशान और माता-पिता / बच्चे के संबंध को हटा दें। दूसरे शब्दों में, किसी भी स्रोत स्नैपशॉट से अछूता क्लोन वास्तविक फाइलसिस्टम होने दें।

ध्यान दें कि मैंने दुनिया को "बस" उद्धरणों के अंदर इस्तेमाल किया: जबकि यह वास्तव में एक सरल तार्किक ऑपरेशन है, मुझे यकीन नहीं है कि यह / या फिर यह अंतर्निहित zfs फाइल सिस्टम में कितना अच्छा है।

@kpande ठीक है, पर्याप्त - अगर कोई वास्तविक तकनीकी समस्या मौजूद है, तो मुझे इसे स्वीकार करना चाहिए। लेकिन यह बताते हुए कि विशिष्ट उपयोग मामला अमान्य है, से अलग है।

यदि यह दृश्य (यानी: "पौराणिक" बीपीआर को शामिल किए बिना अपने मूल माता-पिता के स्नैपशॉट से एक क्लोन को विभाजित करने की असंभवता को zfs डेवलपर्स द्वारा साझा किया गया है, तो मुझे लगता है कि यह FR बंद हो सकता है।

धन्यवाद।

इस सुविधा की आवश्यकता पर +1। हां, सेंड / रिकव का उपयोग किया जा सकता है, लेकिन उस डेटासेट का उपयोग करने के लिए पुराने (क्लोन) से नए डेटासेट पर स्विच करने के लिए जो भी उपयोग करना होगा, की आवश्यकता होगी।

मैं एलएक्सडी के साथ स्थितियों में भाग गया हूं जहां एक कंटेनर की प्रतिलिपि बनाई गई है (क्लोन किया गया है), लेकिन इससे मेरे अलग-अलग प्रबंधित स्नैपशॉट के साथ समस्याएं होती हैं।

@kpande : फिर से, मेरे उपयोग के मामले में संपूर्ण डेटासेट एक डेटाबेस है, और डेटाबेस के कुछ रूपांतर हैं।

मैंने जो देखा है, उससे ऐसा नहीं लगता है कि फ़ाइल सिस्टम के रूप में ओवरलेफ़्स ने अच्छी तरह से w / zfs खेला है (यह आपके नोट्स के अनुसार खुश w / zvols और ext4 / xfs लगता है)। यह _sounds_ इस दृष्टिकोण की तरह ज्यादातर मामलों को कवर करेगा, जिसमें ओवरलेफ़्स w / ext4 / xfs को सेट करने के तरीके का वर्णन करने वाले प्रलेखन का स्वागत किया जाएगा।

उस ने कहा, हममें से कुछ लोग zfs का उपयोग न केवल वॉल्यूम प्रबंधन के लिए बल्कि acl / allow / Snapshot व्यवहार / ब्राउज़िंग के लिए भी कर रहे हैं, और ext4 / xfs के बजाय overlayfs w / zfs का उपयोग करने में सक्षम होना चाहते हैं, इसलिए यदि वह 'संभव है, क्या इसके लिए कोई बग है? अगर वहाँ है, तो यह अच्छा होगा अगर उस पर प्रकाश डाला गया (यहाँ से), यदि नहीं, यदि आप ओवरलेफ़्स दृष्टिकोण का समर्थन कर रहे हैं, तो शायद आप इसे दर्ज कर सकते हैं (यदि आप जोर देते हैं, तो मैं शायद इसे लिख सकता हूं, लेकिन मैं डॉन ' टी ओवरलेफ़्स के बारे में कुछ भी नहीं जानते हैं, और यह राइटअप में एक महत्वपूर्ण तकनीक की तरह लगता है)।

मैंने जो देखा है, उससे ऐसा नहीं लगता है कि फ़ाइल सिस्टम के रूप में ओवरलेफ़्स ने अच्छी तरह से w / zfs खेला है (यह आपके नोट्स के अनुसार खुश w / zvols और ext4 / xfs लगता है)। यह _sounds_ इस दृष्टिकोण की तरह ज्यादातर मामलों को कवर करेगा, जिसमें ओवरलेफ़्स w / ext4 / xfs को सेट करने के तरीके का वर्णन करने वाले प्रलेखन का स्वागत किया जाएगा।

overlayfs दृष्टिकोण एक बहुत ही महत्वपूर्ण और सामान्य, उपयोग के मामले में काम नहीं करेगा: एक आभासी छवि को एक दूसरे से शुरू करना (या "गोल्ड मास्टर" टेम्पलेट)। ऐसी स्थिति में, क्लोन को विभाजित करने से मूल / क्लोन की गई छवियों को हटाने के रूप में व्यर्थ स्थान से बचने के लिए महत्वपूर्ण होगा।

@ ptx0 यह केवल तभी काम करता है जब अतिथि OS overlayfs (इसलिए कोई Windows VMs समर्थन) का समर्थन करता है और यदि अंतिम उपयोगकर्ता (यानी: हमारे ग्राहक) अपने VM छवियों को प्रोविज़न / इंस्टालेशन में महत्वपूर्ण रूप से बदलने के लिए तैयार हैं। एक साइड नोट के रूप में, जबकि मैं पूरी तरह से समझता हूं - और स्वीकार करता हूं - यह पीआर तकनीकी आधार पर बंद हो गया (उदाहरण: यदि इसमें बीपीआर शामिल है), तो वैध उपयोगकर्ता मामले को "अमान्य" के रूप में मुद्रांकित करना काफी निराशाजनक है। यदि यह आपके उपयोग का मामला नहीं है, तो ठीक है। लेकिन कृपया यह न मानें कि इस सुविधा के लिए किसी के पास वैध उपयोग का मामला नहीं है।

विंडोज को ओवरलेफ की जरूरत नहीं है, यह फ़ोल्डर पुनर्निर्देशन और रोमिंग प्रोफाइल में बनाया गया है।

NT के बाद से मौजूद फ़ोल्डर पुनर्निर्देशन, हमेशा सॉफ़्टवेयर के रूप में भरोसेमंद रूप से कार्य नहीं करता है क्योंकि सॉफ़्टवेयर अस्पष्ट है (अस्पष्ट कारणों से) पुनर्निर्देशित फ़ोल्डरों को सही ढंग से हैंडल नहीं करता है और पुनर्निर्देशित डेस्कटॉप या दस्तावेज़ों के साथ सामना करने पर बस विफल हो जाता है। इसके अलावा, विंडोज इंस्टॉलेशन के क्लोन डायवर्ज करते हैं, सभी अपने आप से, बड़े पैमाने पर और मूल से बहुत जल्दी, विंडोज अपडेट के सौजन्य से - अलग-अलग उपयोगकर्ताओं को लॉग ऑन करने और बंद करने के बाद ही इसे गति मिलती है।