Archiwum kategorii: VMware

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