XBoot
Bardzo przydatne narzędzie, którym postanowiłem się z Wami podzielić :)
Wybieramy obrazy ISO (np. hiren’s, memtest86+, antyvirusy, windows i ubuntu), generujemy nowe iso albo od razu bootwalnego pendrive-a z multibootem.
Scenariusz:
trzeba przygotować laba gdzie jest kilka maszyn. dla oszczędności przygotowane zostały dyski macierzyste dla systemów i na nich utworzone kilka maszyn. Export/Import jest trywialny – w GUI są proste wizardy pozwalające na taką operację.
[export –> na wyłączonej maszynie RMB –> export, import dostępny w ‘Action pane’ w dowolnym momencie]
Problem:
dyski dyferencyjne mają na celu oszczędzić trochę miejsca. sporo miejsca. podczas Exportu, aby zuniwersalizować proces, dysk macierzysty jest kopiowany do katalogu maszyny. w efekcie jeśli exportuje się kilka maszyn opartych na tym samym dysq macierzystym, jego kopia jest w każdej z wirtualek.
w zasadzie nie byłoby większego problemu [może poza miejscem], gdyby choćby import był trochę sprytniejszy i to rozpoznawał. efekt jest jednak taki, że podczas importu następuje próba kopiowania dysq. ten zawsze kopiowany jest do ‘root directory’ katalogu zdefiniowanego dla maszyn wirtualnych. następuje błąd ‘file already exists’ i z importu pupa.
chciałoby się to jakoś zautomatyzować.
Rozwiązanie:
informacja o wyexportowanej maszynie znajduje się w pliq <kat gdzie był robiony export><katalog o nazwie maszyny>Virtual Machines<bardzo długi GUID>.EXP
ten plik EXP można wyedytować za pomocą dowolnego edytora textowego. należy znaleźć sekcję
<VALUE.OBJECT><INSTANCE CLASSNAME="Msvm_VirtualHardDiskInfo">
[…]nazwa_pliku.vhd[…]
</INSTANCE></VALUE.OBJECT>
dotyczącą maszyny macierzystej – najlepiej przeszukać plik po jej nazwie. należy usunąć całą sekcję. można też usunąć sam plik, znajdujący się w Virtual Hard Disks. oczywiście należy pamiętać aby zostawić plik macierzysty w chociaż jednej maszynie!! (; a import zacząć właśnie od niej.
I jeszcze o pamięci
ponieważ nie wiadomo jakie będą parametry hosta docelowego, może mu brakować pamięci RAM dla maszyn. warto wykorzystać ‘Dynamic Memory’ dostępne od wersji R2, ustawiając minimalną i sugerowaną ilość RAM, oraz wybierając priorytet dla maszyny. dzięki temu przygotowany lab będzie możliwie uniwersalny i zapewni optymalność.
**UPDATE
ciekawe – podczas exportu maszyny z pamięcią dynamiczną pojawia się ostrzeżenie, że maszyna musi być wyexportowana z wyłączoną tą funkcją. ale wszystko działa i zaimportowała się i ustawienia zostały… co co c’mon?
eN.
ciekawy przypadek – użytkownicy nie mogą zalogować się do serwera terminalowego, ponieważ sesja zawiesza się na przetwarzaniu polis grupowych. serwer w2k8R2.
kilka ciekawostek:
jak widać debugowanie jest dość upierdliwe. szczęśliwie szybko wpadłem na pomysł jak sobie z tym poradzić [w dużym środowisq by to nie wyszło q: ] i zlokalizowałem polisę, która powodowała zawieszanie – chodziło o polisę mapująca drukarki mechanizmem Group Policy Preferences.
biorąc pod uwagę, że użytkownicy normalnie pracują a problem jest tylko na serwerze RDS, udało mi się dojść o co chodzi:
robiło się jakieś sprzężenie zwrotne, serwer reagował w głupi sposób, zawieszając cały proces przetwarzania polis.
rozwiązanie:
pacjent uratowany.
eN.
uptime
uptime systemu można sprawdzić narzędziem systemowym ‘net’:
net statistics server
eN.