Pamiętam, że jakiś czas temu zrobiłem podejście pod Linuksa pod VPC ale w trybie graficznym była sieczka. Tym razem było tak samo, z tym, że zagłębiłem się w temat nieco bardziej. Okazuje się, że wystarczy zmodyfikować palete kolorów z 24 na 16 bitów. W Debianie można to zrobic kreatorkiem:

dpkg-reconfigure xserver-xorg

Albo poprostu wyedytować sobie plik xorg.conf czy jakiś tam inny zależy kto z czego korzysta i znalesć sekcje od kolorów i zmienić na 16 bitów.

Gorzej, że sieć nie działa do końca jak trzeba, i tu sprawa jest ciekawa. Rzecz jasna nie jest to wina Debiana, tylko VPC, bo wkoncu oficjalnie MS nie supportuje Linuksa. Chociaż jak VPC nazywało się jeszcze Connexant Virtual costam.. nim MS ich wykupił to działało wszystko jak marzenie.

Tak czy owak skorzystałem z trybu instalacji Network Install, bo nie chciało mi się sciągać całego ISO, zamiast tego wybrałem sobie co chciałem i gra. Pierwszym problemem była firmowa ISA która wymuszała autoryzacje, to było proste stworzyłem sobie custom regułkę bez autoryzacji i tyle.  Domyślnie jak chyba większośc systemów Debian skonfigurował się na DHCP, i w trybie instalacji działało to bez najmniejszych problemów (VM karta skonfigurowana w tryb Bridged z fizyczną sieciówką). Pechowo gdy system już pobrał wszystko zainstalował i się zresetował to działać przestało. Adres raz dostawał raz nie. Nawet jak dostawał to komunikacji nie było w żadną stronę. Przełączyłem odrazu w VPC w tryb Local Only, a więc wirtualna sieć, tam DHCP działało bez pudła - innych trybów nie używam więc nie sprawdzałem. Żeby nie było w trybie Bridged też się da, trzeba poprostu przejść na adresacje statyczną i wszystko gra - można pracować.

Słowem podsumowania jeszcze, skoro działa pod VPC, to obstawiam, że na VS też zadziała, jak z Hyper-V to jeszcze nie wiem, ale myśle ze i tam sie da.

Znów bedzie o VHD, nie, żeby w mojej firmie wszystko bylo zwirtualizowane – ale wiekszość jest ;) Tak czy owak tak naprawde nie ma chyba jakiegoś porządnego narzędzia do robienia stosownych backupow plików VHD w rozsądnym czasie a jak jest to napewno jest cholernie drogie.

Istota problemu jak zapewne wszyscy wiedzą polega na tym, że te pliki potrafią zależnie od tego co w nich jest sporo ważyć, żeby strzelic kopie wszystkich ręcznie troche czasu to zajmuje i przy okazji mamy downtime. Tak czy owak mój manager wygooglował  naprawde niezłe rozwiązanie tego problemu i do tego darmowe.

W skrócie metoda przedstawiona w tym artykule zakłada za pomocą takich narzędzi jak vbscript i mechanizmu shadow copies strzelenie kopii pliku VHD z możliwie minimalnym downtimem – bo takim jaki potrzeba na zatrzymanie (Save State) i wznowienie pracy vma. (Nie wiem moze z 2-3 min w sumie)  Jednym slowem polecam.

Jak to w życiu bywa zdarza się czasem ze coś pojdzie nie tak na jakimś serwerze X, który przypadkiem hostujemy na maszynie Y - Virtual Serwerze R2 SP1. Przykładowy scenariusz w połowie dnia pracy okazuje sie ze jeden z plików VHD urósł  z 10GB do 65GB. Rowiązujemy problem usuwamy wygenerowane gigabajty plikow – fajnie. Problem w tym, że plik VHD nadal ma 65GB mimo ze tak naprawde w środku jest pusty oprocz tego cały wirtualny serwerX chodzi zauważalnie wolnej.

Co z tym zrobić żeby chodź część problemów rozwiązać szybciej i jednocześnie nie ryzykująć rozwaleniem pliku VHD, przestojem firmy jak i znacznym spadkiem wydajnośći pozostałych wirtuali. Potrzebne będzie narzędzie contig. Najpierw szybka analiza pliku VHD odpalona rzecz jasna na maszynie Y:  

>contig –a c:\vmstore\serwerX.vhd 

Summary:
     Number of files processed   : 1
     Average fragmentation       : 272 frags/file

Wszystko jasne w miare jak plik rósł zaczął się fragmentować po całym dysku przez to spadła wydajność.

>contig –v c:\vmstore\serwerX.vhd

Polecenie powyżej rozpocznie nam process defragmentacji, nie ma problemu żeby wykonać to w trybie on-line serweraX. Podczas procesu defragmentacji wydajność serweraX jeśli będzie serwerem plików lub SQL znacznie spadnie ale nic złego się nie stanie, pozatym i tak chodził wolno ;) Na koniec otrzymamy coś takiego:

Summary:

     Number of files processed   : 1

     Number of files defragmented: 1

     Average fragmentation before: 272 frags/file

     Average fragmentation after : 5 frags/file 

Po tej operacji serwerX zacznie działać zacznie lepiej, należy jednak pamiętać, że środek pliku VHD nadal będzie pofragmentowany i nadal zajmuje 65GB. Aby uporać się z tym problemem trzeba będzie serwerX niestety wyłączyć.(Próbowałem on-line ale nie dośc, że kompaktowanie nic nie kompaktuje to VHD sie naogół rozwala i system ma tendencje do BSOD) Potem najlepiej zgrać sobie gdzieś (najlepiej na workstacje na której mamy VPC2007 i VS2005) plik VHD żeby nie narażać pozostałych wirtualek na spadek wydajności i tam przeprowadzić operacje kompaktowania:

1. Zdefragmentować serwerX korzystajać z wbudowanego defraga

2. Wyposażyć sie w plik .iso dostępny katalogu VPC Aditions o nazwie: Virtual Disk Precompactor.iso

3. Zamontowac uruchomi się sam i przygotuje plik vhd do kompaktowania, nie trwa to zbyt długo.

4. Zkompaktować plik VHD korzystając z narzędzia z VS2005 dostępnego na stronie administracyjnej (Inspect VHD -> Compact)

5. Wkopiować naprawiony plik VHD tam gdzie by i uruchomić serwerX.