Archiwum kategorii: VMware

Monitorowanie hostów ESXi w CheckMK

Co należy zrobić aby monitorować hosty w CheckMK? Dowiecie się z tego poradnika.

Przede wszystkim należy wiedzieć, iż można monitorować nasze serwery ESXi na kilka sposobów:

  1. Przez zwykłe SNMP
  2. Przez specjalnego agenta wbudowanego w każdą wersję CheckMK
  3. Przez Vcenter

W tym wpisie opiszę opcję 2 i 3 ponieważ oferują one o wiele więcej informacji niż opcja 1 i taką również zalecam Wam przybrać metodę monitorowania.

Aby skonfigurować monitorowanie hostów ESXi przez CheckMK należy:

  1. Utworzyć użytkownika z prawami Read-only na każdym z hostów ESXi. Uwaga – jedyny sposób jaki znalazłem, by dodać usera do hosta ESXi to skorzystanie z nierozwijanego już Vsphere Client w c++. Z netu można wyczytać, że można się również posłużyć PowerCLI ale tego akurat nie próbowałem. W każdym razie, po zalogowaniu się do hosta w kliencie Vsphere Client, wchodzimy w zakładkę Users i wybieramy „Add…”:

2. Przejść do zakładki „Permissions” i nadać nowo utworzonego kontu uprawnienia tylko do czytania przez kliknięcie PPM i wybranie „Add Permission…” -> następnie „Add” -> znajdujemy naszego nowo założonego użytkownika -> znowu „Add” żeby wskoczył na listę niżej i na koniec dajemy „OK”:

Z prawej strony okna w „Assigned role” wybieramy „Read-only” (powinno być zaznaczone domyślnie) i upewniamy się, że na dole zaznaczone jest „Propagate to Child Objects”:

3. UWAGA! Używam wersji 1.5.0p7 CheckMK, w innych wersjach może się to nieco różnić. W CheckMK wchodzimy z menu WATO do „Host & Service Parameters” -> „Datasource programs”:

5. W polu „Search” wyszukujemy regułę dotyczącą serwerów ESX wpisując po prostu frazę „esx” – powinno nam znaleźć „Check state of VMWare ESX via vSphere” – jak widać ja już jedną mam utworzoną, u Was będzie to zapewne „0”:

6. Wchodzimy w edycję reguły klikając w nią i ustawiamy jakiego konta chcemy użyć do monitorowania (oczywiście to jest właśnie to, które tworzyliśmy w poprzednich punktach) oraz co dokładnie chcemy monitorować. Ja używam takich ustawień:

7. Co dokładnie widać w monitorowanym hoście ESX? Ano na przykład zużycie CPU, RAM, datastore’ów, zajętość filesystemów, czujniki hardware – czy są jakieś alerty na nich, podniesione interfejsy sieciowe, czy host jest w Maintenance Mode czy uptime.

Nie można skonsolidować dysku – DISKLOCKED albo msg.fileio.lock

Jedna z maszyn wirtualnych zgłasza konieczność skonsolidowania dysku:

Niestety proste kliknięcie „Consolidate” nie pomaga z powodu błędu „msg.snapshot.error-DISKLOCKED”:

Postanowiłem najpierw przenieść maszynę wirtualną na inny host i tam spróbować ponownie konsolidacji – nie udało się. Następnie spróbowałem wykonać snapshota i go usunąć (udało się), a następnie zrobić konsolidację – również nie zadziałało. Tym razem jednakże error już był inny:

W szczegółach błędu dowiadujemy się, że nie można uzyskać dostępu do pliku (maszyny wirtualnej) ponieważ jest ona w trybie „Locked” – zablokowanym. Jak wynika z tego linka – maszyn wirtualna może być zablokowana w ten sposób z powodu tego, że jeden z ESX nadal „trzyma” nad plikiem tej maszyny pieczę. Zazwyczaj jest to efekt przyblokowania go przez narzędzie do tworzenia backupów – podczas wykonywania kopii soft blokuje sobie dostęp do pliku maszyny wirtualnej i „wypuszcza” go gdy skończy backupować plik. Niestety czasami nie zrobi tego do końca poprawnie i wtedy powstaje rzeczony błąd.

Rozwiązań tego problemu jest kilka, ja akurat skłoniłem się ku najbardziej drastycznemu czyli wyłączeniu wszystkich maszyn wirtualnych i zrestartowanie wszystkich wirtualizatorów (ESXi). Akurat wypadał i tak termin cyklicznego restartu hostów więc czemu nie. W ten sposób upewniłem się, że wszelkie blokady zostały ucięte przez system operacyjny oraz, że wszelkie dostępy zostały wycięte. Po tej operacji mogłem już spokojnie skonsolidować plik i alert zniknął. Jeśli ktoś nie ma luksusu restartu wszystkich hostów ESXi może zlokalizować, który konkretnie z nich trzyma „lock” na pliku maszyny wirtualnej i zrestartować na tym jednym usługę hostd – to powinno pomóc. Trzeba jednakże pamiętać, by wcześniej zmigrować z niego wszelkie maszyny wirtualne na inne hosty. Myślę jednak, że skoro już trzeba zwolnić host z maszyn wirtualnych to lepiej od razu zrestartować go całego żeby system się nieco odświeżył bo kto wie co tam się jeszcze zablokowało wewnątrz?

Dostęp do bazy danych vPosgreSQL w VCSA 6.0

Załóżmy, że pewnego dnia zjawi się u Ciebie w firmie Pan z firmy, która zlicza licencje Microsoft. Ot, tak – żeby sprawdzić czy na te wszystkie licencje masz odpowiednie papiery. Podczas tych prac będzie chciał się połączyć z pewnością również do serwerów VMware’a, na których hostujesz systemy z rodziny Windows Server. Do tych serwerów, na których jest baza VMware’owa oparta o MSSQL nie powinieneś mieć problemu się dostać. Równie dobrze możesz mieć jednakże Vcenter postawione na Linuksie – nazywa się to-to VCSA i tam jest już baza PostgreSQL dostosowana przez VMware’owych inżynierów na swoje potrzeby i przemianowana na vPostgre. Jak się do niej dostać?

Poniższy przykład pokazuje sposób dostania się do VCSA 6.0, czyli Vcenter 6.0 ale zapewne zadziałają też na 5.5:

Pierwszym krokiem będzie zalogowanie się przez SSH do VCSA (właśnie tam, nie do jednego z ESXi) jako root – konto tutaj jest istotne. Następnie wydanie polecenia

shell.set --enabled true

a następnie:

shell

Dzięki temu dostaniemy sie do normalnej powłoki, gdzie będziemy mogli wykonywać normalne linuksowe polecenia zupełnie jak w starszych wersjach VCSA.

Dostanie sie do shella na VCSA 6.0

2. Musimy teraz poznać usera oraz hasło do bazy VMware’owej. Aby to zrobić należy podejrzeć plik /etc/vmware-vpx/vcdb.properties, w którym wszystko jest zapisane jawnym tekstem… :

cat /etc/vmware-vpx/vcdb.properties

Podgląd usera oraz hasła do bazy vPostgre

3. Kolejnym punktem będzie zmiana konfiguracji pliku /storage/db/vpostgres/pg_hba.conf, gdzie zapisane są miejsca, z których można łączyć się do bazy danych PostgreSQL:

vim storage/db/vpostgres/pg_hba.conf

Znajdź linijkę, gdzie widnieje wpis:

host   all      alll      <<<   0.0.0.0/0 >>>      md5

Ten zakres 0.0.0.0 /0 świadczy o tym skąd możemy się łączyć do bazy przez dany interfejs. Jeśli dla interfejsu ipv4 zmienimy ten wpis na właśnie 0.0.0.0/0, to będziemy mogli połączyć się zewsząd:

Edycja pliku pg_hba.conf

Kolejny krok to wskazanie na jakim adresie będzie trwało nasłuchiwanie przychodzących połączeń. Konfiguruje się to w pliku posgtresql.conf w tym samym folderze:

vim storage/db/vpostgres/postgresql.conf

Najlepiej chyba posłużyć się gwiazdką:

Na koniec jeszcze restart usługi i połączenia przychodzące powinny już działać bez problemu:

/etc/init.d/vmware-vpostgres restart

 

 

Windows Server 2012 na VMware ESXi 4.1

Jeśli próbujesz właśnie stworzyć maszynę wirtualną na Esxi 4.1.0 i postawić na niej Windows Server 2012 (w tym również R2), to z pewnością napotkasz problemy. Po stworzeniu maszyny skonfigurowanej wstępnie pod Windows Server 2008R2 i wprowadzeniu początkowej konfiguracji (Ram, procesory, podłączony napęd) odpalasz maszynę i Twoim oczom ukarze się piękny niebieski obrazek, a następnie maszyna będzie się bez końca restartować:

w2k12

 

Nie pomaga zmiana ustawień serwera, jak dodanie RAM-u, zwiększenie dysku, czy ilości procesorów. Co natomiast pomoże, to wgranie tego pliku: bios.440 do datastore’u, gdzie znajdują się pliki *.vm* maszyny oraz edycja jej ustawień w pliku .vmx. Wszystko znajdziesz w menu Home->Datastores->[Datastore gdzie jest postawiona maszyna]->PPM na Datastorze i „Browse Datastore”->przechodzisz na maszynę i wgrywasz plik – „Upload files to this datastore”->Upload File.

Żeby maszyna korzystała z tego pliku należy jeszcze dodać kilka linijek w pliku .vmx i wgrać go w to samo miejsce (nadpisać):

 

bios440.filename = "bios.440.rom"
mce.enable = TRUE
cpuid.hypervisor.v0 = FALSE
vmGenCounter.enable = FALSE

 

Po wgraniu tego pliczku i edycji pliku konfiguracyjnego .vmx maszyna z Windows Server wystartuje normalnie i można spokojnie zainstalować system. Co ciekawe VMware Tools instalują się już bez problemu:

Przechwytywanie