OpenVDDK jako zamiennik VMware VDDK: co oznacza niezależna biblioteka dysków dla backupu i migracji w polskich firmach

OpenVDDK to niezależna, open-source’owa implementacja biblioteki VDDK, którą narzędzia backupowe i migracyjne VMware ładują, żeby czytać dyski wirtualne. Projekt deklaruje, że jest „drop-inem” dla pliku libvixDiskLib.so.8.0.3 — tę samą nazwę pliku, te same funkcje, ten sam format zwracanych danych. Dla firm, które utrzymują łańcuch backupu lub migracji oparty na VDDK, oznacza to możliwość podmiany jednego pliku biblioteki bez przepisywania aplikacji.

Sprawa dotyczy przede wszystkim dostawców i integratorów oprogramowania backupowego, zespołów utrzymujących migracje VMware→KVM oraz administratorów, którzy sami składają narzędzia oparte na VDDK. Znaczenie jest praktyczne: VDDK jest komponentem własnościowym VMware (obecnie Broadcom), a jego warunki licencyjne i dostępność wpływają na to, jak zewnętrzne narzędzia mogą czytać dyski vSphere. Alternatywna implementacja na licencji Apache 2.0 zmienia układ zależności — ale wyłącznie w zakresie odczytu i tylko tam, gdzie aplikacja faktycznie korzysta z tego interfejsu.

Co dokładnie deklaruje projekt

Według strony projektu OpenVDDK jest napisany od zera, wyłącznie na podstawie publicznej dokumentacji i testów typu black-box, i nie zawiera kodu VMware. To kluczowe zastrzeżenie natury prawnej: deklaracja „nie zawiera kodu VMware” jest oświadczeniem dostawcy, a nie faktem zweryfikowanym przez niezależną stronę. Podobnie licencja Apache 2.0 i wersja 0.7.4 to informacje podane przez wydawcę.

Zakres funkcjonalny opisany na stronie:

• Transporty: HotAdd, NBDSSL oraz NBD. Projekt zapewnia, że używane są tylko transporty jawnie wskazane przez narzędzie — żądanie wyłącznie NBDSSL nie spada do nieszyfrowanego NBD.
• Tryb tylko do odczytu: wywołania zapisu zwracają ten sam błąd read-only, co biblioteka VMware.
• Wiele sesji NFC: parametr OpenVDDK.nbd.sessions w zakresie 1–16, domyślnie 1, pozwala jednemu czytelnikowi prowadzić równoległe transfery bez zewnętrznej nakładki.
• Brak telemetrii: biblioteka łączy się wyłącznie z vCenter i hostami ESXi wskazanymi przez narzędzie.
• Read-ahead dla czytelników sekwencyjnych, w tym programów czytających asynchronicznie.

Zgodność interfejsu — co to realnie znaczy

„Drop-in” w tym kontekście oznacza zgodność na poziomie nazwy pliku współdzielonego i eksportowanych funkcji VixDiskLib. Aplikacja, która dynamicznie ładuje libvixDiskLib.so.8.0.3, nie musi wiedzieć, którą implementację dostała. To nie to samo co pełna zgodność ze specyfikacją API w każdym scenariuszu — strona projektu nie publikuje kompletnej macierzy pokrycia funkcji. Wniosek, jaki można wyciągnąć z materiału: zgodność jest deklarowana dla ścieżki odczytu dysków, a nie dla całego API VDDK.

Tło techniczne prostym językiem

VDDK (Virtual Disk Development Kit) to biblioteka, dzięki której program backupowy nie musi rozumieć wewnętrznego formatu dysku VMware. Aplikacja wywołuje funkcje typu „otwórz dysk”, „czytaj blok”, „zamknij dysk”, a biblioteka zajmuje się resztą: dogaduje się z vCenter, znajduje snapshot, wybiera transport i pobiera dane.

Transporty różnią się drogą, jaką dane pokonują:

Transport	Jak działa	Kiedy ma sens
HotAdd	Dysk snapshotu jest podpinany do maszyny proxy, odczytywany lokalnie i zwracany	Gdy można postawić proxy VM blisko hosta źródłowego
NBDSSL	Odczyt bezpośrednio z hosta ESXi po sieci, połączenie szyfrowane	Gdy nie ma proxy albo sieć jest zaufana i szyfrowana
NBD	Odczyt po sieci bez szyfrowania	Środowiska izolowane; w innych przypadkach ryzykowne

Tryb tylko do odczytu nie jest ograniczeniem w backupie — kopia zapasowa z definicji czyta dane. W migracji jest podobnie: narzędzia typu VMware→KVM czytają dysk źródłowy i zapisują go w nowym formacie po swojej stronie. Barierą staje się dopiero tam, gdzie aplikacja chciałaby pisać do dysku przez VDDK — na przykład przy przywracaniu bezpośrednio do dysku wirtualnego. W takim scenariuszu OpenVDDK nie zastąpi biblioteki VMware.

Deklarowane pomiary — jak je czytać

Wszystkie liczby wydajnościowe pochodzą z laboratoriów dostawcy. Sam projekt wyraźnie to zaznacza i pisze wprost, że nie jest to niezależny benchmark, że wyniki zależą od storage’u, sieci, CPU i aplikacji, oraz że w ich własnym środowisku obie biblioteki mogą wypadać tak samo. To uczciwe zastrzeżenie i trzeba je traktować poważnie.

Scenariusz	OpenVDDK (deklaracja dostawcy)	VMware VDDK 8.0.3 (deklaracja dostawcy)
Odczyt dysku 200 GiB (HotAdd)	2 488 MiB/s	1 441 MiB/s
Otwarcie dysku 40 GB	1,0 s	19,1 s
Zwolnienie dysku	0,3 s	12,6 s
Migracja VM 200 GiB (kopiowanie)	537 MiB/s	282 MiB/s
Cała migracja 200 GiB	7 min 24 s	15 min 2 s

Dostawca podaje też, że dane odczytane przez obie biblioteki miały identyczny SHA-256 — dla całego dysku i dla 800 zakresów. To ważniejsza informacja niż sama przepustowość: sugeruje, że różnica dotyczy czasu, a nie zawartości. Podobnie w migracji 200 GiB pliki qcow2 po obu przebiegach były identyczne według qemu-img compare.

Dlaczego część różnic może mieć inne źródło

W opisie pomiarów migracji pojawia się szczegół, który warto wyodrębnić: w laboratorium dostawcy każde rozwiązywanie nazwy na maszynach roboczych czekało 5 sekund na nieodpowiadający serwer DNS. Biblioteka VMware miała wykonywać cztery takie zapytania przy każdym otwarciu dysku, a OpenVDDK — żadnego. To wyjaśnia część różnicy w czasie otwierania i zamykania dysku, ale nie w przepustowości odczytu.

Drugi szczegół dotyczy mechaniki: według dostawcy biblioteka VMware pobiera pojedynczy blok 1 MiB na raz, a OpenVDDK utrzymuje kilka żądań po 2 MiB w locie. Wyższe opóźnienie pojedynczego żądania przy większej liczbie żądań naraz to klasyczny efekt kolejkowania, a nie „szybszy dysk”. To tłumaczy, dlaczego zysk wydajnościowy może się nie przenieść na środowisko z innym storage’em lub innym wąskim gardłem.

Deklarowane pomiary są punktem wyjścia do własnych testów, nie podstawą decyzji produkcyjnej. Projekt sam zachęca do pomiarów we własnym środowisku i do pytania o metodę w zgłoszeniu na GitHubie.

Realne konsekwencje dla organizacji

Najważniejsza konsekwencja jest prawno-operacyjna, nie wydajnościowa. Jeśli biblioteka nie zawiera kodu VMware i jest na Apache 2.0, to organizacja budująca własne narzędzie nie musi opierać się na warunkach licencyjnych VDDK przy samej bibliotece. To deklaracja dostawcy — przed wdrożeniem w firmie warto ją potwierdzić w repozytorium i, przy większym ryzyku, skonsultować z działem prawnym.

Druga konsekwencja dotyczy łańcucha dostaw. Podmiana pliku biblioteki w istniejącym narzędziu to zmiana w komponencie, który zwykle nie jest aktualizowany razem z aplikacją. Jeżeli dostawca backupu sam dostarcza VDDK, podmiana „własnoręczna” może wyjść poza wspierany przez niego scenariusz i wpłynąć na gwarancję wsparcia.

Trzecia to ograniczenie funkcjonalne: tylko odczyt. Wszędzie tam, gdzie proces wymaga zapisu przez VDDK, OpenVDDK nie jest zamiennikiem.

Scenariusze ryzyka

• Ryzyko zgodności: deklaracja „bez kodu VMware” i licencja Apache 2.0 pochodzą od dostawcy. Brak niezależnej weryfikacji prawnej w materiale źródłowym.
• Ryzyko wsparcia: podmiana biblioteki w produkcie komercyjnym może unieważnić wsparcie dostawcy backupu.
• Ryzyko wydajnościowe: zyski z pomiarów dostawcy mogą nie wystąpić w innym środowisku; możliwe też regresje w scenariuszach nieobjętych testami.
• Ryzyko pokrycia: brak publicznej, pełnej macierzy zgodności funkcji VDDK. Aplikacja korzystająca z mniej typowych wywołań może zachować się inaczej.
• Ryzyko wersji: README w wersji 0.7.4 wymienia vSphere 6.7, 7.0 i 8.0; vSphere 9.1.1 testowano po wydaniu. To nie to samo co oficjalnie wspierana konfiguracja.
• Ryzyko bezpieczeństwa transportu: NBD bez szyfrowania przenosi dane dysku otwartym kanałem. Projekt nie wymusza NBDSSL, jeśli narzędzie zażąda NBD.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

1. Ustal, czy którekolwiek z używanych narzędzi ładuje libvixDiskLib.so.8.0.3 lub inną wersję VDDK. Szukaj w katalogach instalacyjnych oprogramowania backupu i migracji.
2. Sprawdź, czy narzędzie korzysta wyłącznie z odczytu, czy także z zapisu przez VDDK. Jeśli zapisuje — OpenVDDK nie jest opcją.
3. Zidentyfikuj wersje vSphere w środowisku i porównaj je z listą w README wydania, które rozważasz.
4. Ustal, czy dostawca narzędzia wspiera podmianę biblioteki. Sprawdź umowę wsparcia i dokumentację.
5. Zbierz baseline wydajności obecnego rozwiązania: czas otwarcia dysku, przepustowość odczytu, czas pełnej kopii lub migracji.

Plan reakcji krok po kroku

Krótkoterminowo (testy, bez produkcji)

1. Pobierz wydanie z repozytorium projektu i zweryfikuj sumy SHA-256 podane przez wydawcę.
2. Zbuduj środowisko testowe odwzorowujące produkcję: te same wersje vSphere, ten sam typ storage’u, podobna sieć.
3. Wykonaj pomiary na obu bibliotekach przy identycznym buildzie aplikacji, tej samej VM i tym samym workerze — zmieniaj wyłącznie plik biblioteki.
4. Porównaj nie tylko czasy, ale i sumy kontrolne odczytanych danych oraz wynikowe obrazy po migracji.
5. Przetestuj każdy transport, którego faktycznie używasz: HotAdd, NBDSSL i NBD osobno.
6. Uruchom testy negatywne: przerwane zadanie, restart workera, niedostępny vCenter w trakcie odczytu.

Długoterminowo

1. Utrzymuj własny, powtarzalny zestaw testów porównawczych obu bibliotek przy każdej aktualizacji.
2. Śledź wydania projektu i zmiany w liście wspieranych wersji vSphere.
3. Uzgodnij z dostawcą narzędzia backupu status wsparcia dla podmienionej biblioteki.
4. Udokumentuj decyzję o ewentualnym wdrożeniu wraz z podstawą prawną i wynikami testów.

Typowe błędy

• Traktowanie pomiarów dostawcy jako gwarancji. To wyniki z jednego laboratorium, w większości pojedyncze przebiegi lub pary.
• Pomiar bez kontroli zmiennych. Zmiana biblioteki i jednoczesna zmiana workera, storage’u lub ustawień aplikacji unieważnia porównanie.
• Pomijanie weryfikacji danych. Sam szybszy odczyt nic nie znaczy, jeśli dane się różnią — a to trzeba sprawdzić samodzielnie.
• Podmiana pliku w produkcie bez zgody dostawcy. Ryzyko utraty wsparcia.
• Zakładanie pełnej zgodności API. „Drop-in” dotyczy nazwy pliku i eksportowanych funkcji, nie każdego możliwego scenariusza użycia.
• Ignorowanie trybu read-only. Próba użycia tam, gdzie potrzebny jest zapis, skończy się błędem read-only.
• Mylenie wersji testowanej z wersją wspieraną. vSphere 9.1.1 testowano po wydaniu 0.7.4, a README tego wydania go nie wymienia.

Checklista przed wdrożeniem

• Potwierdzona wersja pliku biblioteki wymagana przez aplikację.
• Potwierdzony zakres użycia: tylko odczyt czy także zapis.
• Zgodność wersji vSphere z listą w README wybranego wydania.
• Zweryfikowane sumy SHA-256 pobranego wydania.
• Wyniki własnych testów wydajności na obu bibliotekach.
• Porównane sumy kontrolne odczytanych danych i obrazów po migracji.
• Przetestowane wszystkie używane transporty, w tym zachowanie przy wymuszonym NBDSSL.
• Stanowisko dostawcy narzędzia backupu wobec podmiany biblioteki.
• Ocena prawna deklaracji „bez kodu VMware” i licencji Apache 2.0.
• Plan wycofania zmiany i przywrócenia oryginalnej biblioteki.

Co powinien zrobić właściciel firmy / administrator

Administrator powinien najpierw ustalić, czy problem w ogóle go dotyczy — czyli czy w środowisku działa narzędzie ładujące VDDK i czy korzysta ono wyłącznie z odczytu. Następnie powinien zbudować środowisko testowe i wykonać pomiary porównawcze z kontrolą zmiennych, łącznie z weryfikacją sum kontrolnych. Dopiero po pozytywnych wynikach warto rozważać wdrożenie, i to najlepiej w porozumieniu z dostawcą narzędzia.

Właściciel firmy powinien spojrzeć na trzy rzeczy: czy podmiana biblioteki nie narusza umowy wsparcia, czy deklaracja licencyjna projektu została potwierdzona w repozytorium, oraz czy zespół ma zasoby na utrzymanie własnych testów porównawczych przy kolejnych aktualizacjach. OpenVDDK nie jest produktem komercyjnym z gwarancją SLA — to projekt open source, którego jakość i tempo rozwoju trzeba oceniać samodzielnie.

Wniosek z materiału źródłowego jest ostrożny: projekt opisuje konkretny, wąski przypadek użycia (odczyt dysków do backupu i migracji), deklaruje zgodność na poziomie pliku i funkcji, publikuje własne pomiary z wyraźnym zastrzeżeniem, że nie są niezależne. To wystarczająca podstawa, by przeprowadzić własne testy — nie wystarczająca, by wdrażać bez nich.

Praktyczna weryfikacja przed wdrożeniem: jak zaprojektować test, który coś udowodni

Weryfikacja OpenVDDK nie polega na powtórzeniu pomiarów dostawcy, lecz na zbudowaniu własnego, powtarzalnego testu, w którym jedyną zmienną jest plik biblioteki. Materiał źródłowy podaje konkretne warunki, które trzeba odtworzyć: ten sam build aplikacji, ta sama VM, ten sam worker, ten sam storage i ta sama sieć, a podmieniany jest wyłącznie plik libvixDiskLib.so.8.0.3. Każde odstępstwo od tej zasady unieważnia porównanie.

Krok 1: inwentaryzacja tego, co faktycznie ładuje bibliotekę

Zanim powstanie jakikolwiek test wydajnościowy, trzeba ustalić, które narzędzia w środowisku ładują libvixDiskLib.so.8.0.3 lub inną wersję VDDK. Szukaj w katalogach instalacyjnych oprogramowania backupu i migracji. Dla każdego znalezionego przypadku zapisz: nazwę i wersję narzędzia, wersję wymaganej biblioteki, tryb pracy (odczyt czy zapis) oraz używane transporty. Bez tej mapy nie da się ocenić, czy problem w ogóle dotyczy organizacji.

Krok 2: odtworzenie środowiska pomiarowego

Środowisko testowe musi odwzorowywać produkcję w zakresie, który wpływa na wynik: te same wersje vSphere (ESXi i vCenter), ten sam typ storage’u, podobna sieć, podobna konfiguracja workera. Warto pamiętać, że pomiary dostawcy powstały w konkretnych warunkach: HotAdd na fizycznych hostach ESXi 8.0.3, worker z 3 vCPU i 4 GiB przy NFS 4.1 na RAM przez 100 GbE, a osobno worker z 8 vCPU przy VMFS na LUN iSCSI. To nie jest uniwersalny wzorzec — to opis konkretnego laboratorium.

Krok 3: pomiar z kontrolą zmiennych

Dla każdej pary pomiarów wykonaj dwa przebiegi: jeden z biblioteką VMware, drugi z OpenVDDK, zmieniając wyłącznie plik. Mierz co najmniej:

• czas otwarcia dysku (dla dysku o znanym rozmiarze, np. 40 GB),
• czas zwrotu dysku po zakończeniu odczytu,
• przepustowość odczytu sekwencyjnego na dysku o znanym rozmiarze (np. 200 GiB),
• czas pełnej kopii lub migracji wraz z podziałem na fazy (kopiowanie, oczekiwanie na odczyty, finalny przebieg).

Pojedynczy przebieg to za mało — materiał źródłowy sam przyznaje, że większość pomiarów to pojedyncze przebiegi lub pary. Własny test powinien mieć co najmniej kilka powtórzeń, aby odróżnić różnicę realną od szumu.

Krok 4: weryfikacja danych, nie tylko czasu

Szybszy odczyt bez zgodności danych jest bezwartościowy. W materiale źródłowym weryfikacja polegała na porównaniu SHA-256 całego dysku i wszystkich 800 zakresów oraz na sprawdzeniu, że zmienione pliki w obu zmigrowanych VM mają identyczny hash. Własny test powinien zawierać analogiczny element: sumy kontrolne odczytanych danych oraz wynikowych obrazów po migracji. Dodatkowo warto sprawdzić, czy aplikacja nie zgłasza błędów przy mniej typowych wywołaniach — pełna macierz zgodności funkcji VDDK nie jest publicznie dostępna.

Krok 5: testy każdego transportu osobno

HotAdd, NBDSSL i NBD to trzy różne ścieżki i każdą trzeba przetestować niezależnie. Szczególnie istotne jest zachowanie przy wymuszonym NBDSSL: materiał źródłowy deklaruje, że żądanie tylko NBDSSL nigdy nie spada do nieszyfrowanego NBD. To warto potwierdzić w praktyce, bo NBD bez szyfrowania przenosi dane dysku otwartym kanałem. Osobno przetestuj też wiele sesji NFC naraz (OpenVDDK.nbd.sessions, zakres 1–16, domyślnie 1), jeśli narzędzie ma z tego korzystać.

Krok 6: testy negatywne i odporność

Materiał źródłowy wspomina, że przerwany przebieg jest sprzątany przez następny. To deklaracja, którą trzeba sprawdzić: przerwij zadanie w trakcie odczytu, zrestartuj workera, odłącz vCenter w trakcie odczytu. Sprawdź, czy kolejne uruchomienie kończy się powodzeniem i czy nie pozostają osierocone snapshoty lub zawieszone dyski na hoście ESXi.

Monitoring po wdrożeniu: co obserwować i jak wykryć regresję

Po wdrożeniu OpenVDDK monitoring musi odpowiadać na trzy pytania: czy zadania kończą się poprawnie, czy dane są zgodne, oraz czy wydajność nie odbiega od baseline’u zebranego przed zmianą. Sam brak błędów w logach nie wystarcza — biblioteka read-only zwraca błąd przy próbie zapisu, więc narzędzie, które wcześniej zapisywało, może zgłaszać błędy dopiero przy konkretnym scenariuszu.

Metryki obowiązkowe

• Czas otwarcia i zwrotu dysku dla każdego zadania — porównuj z baseline’em; wydłużenie może sygnalizować problem z vCenter lub hostem ESXi, bo te czasy zależą właśnie od nich.
• Przepustowość odczytu w rozbiciu na transport (HotAdd, NBDSSL, NBD) — mieszanie transportów w jednym wskaźniku ukrywa regresję w jednym z nich.
• Czas fazy kopiowania i czas oczekiwania na odczyty — w pomiarach dostawcy oczekiwanie na odczyty zajmowało około 182 s przy 200 GiB, więc ten wskaźnik jest czuły na wąskie gardło storage’u.
• Liczba i wynik weryfikacji sum kontrolnych — jeśli narzędzie je liczy, raportuj odsetek zgodnych przebiegów.
• Liczba nieudanych zadań i ich przyczyny, w szczególności błędy read-only.

Progi alertów i reakcja

Progi ustaw względem własnego baseline’u, nie względem liczb dostawcy. Praktyczna reguła: alert przy odchyleniu czasu otwarcia dysku lub przepustowości przekraczającym wartość, którą uznasz za istotną dla okna backupowego. Przy alertcie sprawdź kolejno: stan vCenter i hostów ESXi, stan storage’u i sieci, konfigurację transportu w narzędziu, a na końcu wersję pliku biblioteki — czy nikt nie podmienił jej z powrotem lub na inną.

Monitoring zmian wersji

Śledź wydania projektu i zmiany w liście wspieranych wersji vSphere. README w wersji 0.7.4 wymienia vSphere 6.7, 7.0 i 8.0, a vSphere 9.1.1 testowano po wydaniu — to nie to samo co oficjalnie wspierana konfiguracja. Przy każdej aktualizacji vSphere i przy każdym nowym wydaniu biblioteki uruchom ponownie własny zestaw testów porównawczych. Pamiętaj też, że wydane pliki nie są zmieniane, więc ich sumy SHA-256 pozostają ważne — nowa lista wspieranych wersji pojawi się dopiero w kolejnym wydaniu.

Monitoring łańcucha dostaw

Utrzymuj rejestr, gdzie w środowisku znajduje się plik biblioteki, kto nim zarządza i jaka jest jego wersja oraz suma SHA-256. Zmiana w komponencie, który zwykle nie jest aktualizowany razem z aplikacją, łatwo umyka — a podmiana biblioteki w produkcie komercyjnym może wpłynąć na gwarancję wsparcia dostawcy backupu. Każdą taką zmianę powinna poprzedzać aktualizacja rejestru i wpis w dokumentacji decyzji.

Checklista operacyjna po wdrożeniu

1. Zapisana wersja pliku biblioteki i jej suma SHA-256, zgodna z wydaniem pobranym z repozytorium.
2. Potwierdzony zakres użycia: wyłącznie odczyt; żadne zadanie nie wymaga zapisu przez VDDK.
3. Baseline wydajności z okresu przed zmianą i po zmianie, dla każdego używanego transportu osobno.
4. Wyniki weryfikacji sum kontrolnych odczytanych danych i obrazów po migracji.
5. Przetestowane scenariusze negatywne: przerwane zadanie, restart workera, niedostępny vCenter w trakcie odczytu.
6. Potwierdzone zachowanie przy wymuszonym NBDSSL — brak fallbacku do nieszyfrowanego NBD.
7. Stanowisko dostawcy narzędzia backupu wobec podmiany biblioteki, udokumentowane.
8. Ocena prawna deklaracji „bez kodu VMware” i licencji Apache 2.0, potwierdzona w repozytorium.
9. Plan wycofania zmiany: kopia oryginalnej biblioteki i procedura przywrócenia.
10. Harmonogram ponownego uruchomienia testów porównawczych przy każdej aktualizacji vSphere i każdej nowej wersji biblioteki.

Checklista szybkiej weryfikacji w 30 minut

Gdy trzeba wstępnie ocenić, czy temat dotyczy organizacji, wystarczy krótka ścieżka:

• Znajdź plik libvixDiskLib.so.8.0.3 w katalogach instalacyjnych narzędzi backupu i migracji.
• Ustal, czy narzędzie tylko czyta, czy także zapisuje przez VDDK — jeśli zapisuje, temat jest zamknięty.
• Porównaj wersje vSphere w środowisku z listą w README rozważanego wydania.
• Sprawdź w umowie wsparcia i dokumentacji dostawcy, czy podmiana biblioteki jest wspierana.
• Zanotuj obecne czasy otwarcia dysku, przepustowość odczytu i czas pełnej kopii jako punkt odniesienia.
• Zweryfikuj sumy SHA-256 pobranego wydania, jeśli planujesz testy.

Wynik tej ścieżki nie jest decyzją wdrożeniową — jest filtrem, który mówi, czy warto zainwestować w pełny test porównawczy. Materiał źródłowy jest w tym względzie jednoznaczny: deklaracje dostawcy i jego własne pomiary to wystarczająca podstawa, by przeprowadzić własne testy, ale niewystarczająca, by wdrażać bez nich.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. OpenVDDK – Independent Virtual Disk Library (openvddk.com)

Zdjęcie wyróżniające: Jakub Zerdzicki / Pexels.