Există un server exsi 5.5 care este implementat în HP Proliant, mă conectez prin vSphere, vCenter nu este prezent.
Într-o potrivire a suspiciunii paranoide de hacking, el a schimbat parolele pentru conturile de administrator, inclusiv vpxuser. După aceea, am lucrat în vSphere fără nici un semn de eroare. Ieri a fost nevoie să se conecteze la consola de server, dar atunci când introduceți parola de conectare cade eroare „Call“ ServiceInstance.RetrieveContent „pentru obiect“ ServiceInstance „pe server“ adresă_ip „a eșuat“. Fumatul Google pe această temă a dus la necesitatea conectării la serverul de linie de comandă fie local, fie prin ssh. În mod implicit, este dezactivat pe server. Atunci când vă conectați consola locală exsi Server de conectare prinimat / parola (la perechea greșit se plânge) și consola reflectă o oră și jumătate. După autentificare și așteptare lungă, am activat ssh și am conectat-o prin ea fără nici o așteptare.
Pentru a rezolva problema am încercat repornirea serviciului /sbin/services.sh restert - nu a ajutat.
Există suspiciuni că problema este schimbarea parolei în sistemul de înregistrare vpxuser. Ie trebuie să returnezi cumva parola implicită. Pentru a rezolva problema, se recomandă ștergerea acestui cont astfel încât gazda exsi să o recreeze cu parola implicită.
În acest sens, au apărut câteva întrebări:
- Este posibil ca problema cu imposibilitatea prin vSphere să fie legată de schimbarea parolei în contul de sistem vpxuser?
- Cum să resetați parola vpxuser-ului la valoarea implicită în condițiile date?
- Restabilirea parolei va afecta funcționarea mașinilor virtuale existente și nu va fi pierdută posibilitatea administrării de la vSphere? există mașini critice.
Materialele cu eticheta "vpxuser"
Materialele cu "exsi"
Materialele etichetate cu "resetare parolă"
Aceste materiale sunt marcate ca "finale". Afișează mesajele din ultimele:
Contul vpxuser este creat de VirtualCenter când se adaugă o gazdă ESX. Nu manipulați acest cont.
Dar, din moment ce această situație sa întâmplat, puteți încerca să resetați setările vpxuser la implicit, cu toate acestea, mă îndoiesc că acest lucru vă va ajuta. Încă o dată: prezența unei parole de la vpxuser nu va da nimic atacatorului, este imposibil să îl utilizați pentru a vă conecta la gazdă. Așa cum este indicat în articol, legătura la care am dat mai sus, nu trebuie să atingeți deloc acest cont, acest lucru este cel mai probabil să ducă la întreruperea legăturii dintre vcenter-ESXi.
O modalitate de a reveni la vpxuser implicit afișat, dar folosind clientul vSphere, și eu sunt sigur că 99% din cea a rezetnut cli ESXi sau șterge / crea vpxuser nu se poate (pur și simplu eliminați posibil) ca această operație este efectuată de centrul.
Manipularea cu acest cont nu va afecta funcționarea vm. Aș face următoarele:
1. Asigurați-vă că există backup-uri ale vm-ului meu (manipularea cu vpxuser nu va afecta funcționarea mașinilor, dar nu putem restabili accesul).
2. Voi crea un proces pentru vcenter + vsphere.
3. V-ar instala vcenter (este posibil toate pe o valoare implicită).
4. Următorul ar acționa în conformitate cu instrucțiunile din articol - ar elimina vpxuserul de la ESXi, verifica accesul - dacă nu ar fi recuperat, atunci ar adăuga ESXi la centrul. Ar trebui să existe deja acces, după care, dacă nu intenționați să folosiți vcenter, hypervisorul poate fi derivat din centrul.
Multumesc - articolul menționat, am găsit acest lucru după schimbarea parolei (((
Gândul despre procesul vCentre este destul de interesant, dar există temeri că există o versiune pe server cu o licență gratuită, ceea ce nu permite gestionarea prin vCentre. Cu siguranță nu pot spune, tk. serverele au fost moștenite fără nicio documentație. În orice caz, voi încerca.
Acesta este bântuit de întrebarea dacă eroarea „Call“ ServiceInstance.RetrieveContent „pentru obiect“ ServiceInstance „pe server“ adresă_ip „a eșuat“ atunci când conectați prin vSphere cauzate ca urmare a schimba parola? Sau pot exista alte motive, cum ar fi locul de încheiere a verificării spot a sistemului?
Am scris că procesul ar trebui să fie formalizat pe vcenter + vsphere, adică și pe ESXi, apoi activați cu exactitate ESXi în centrul. Întrebarea este: este posibil să aruncați o licență liberă după ce Ent + - nu știu, căutați informații.
Toate răspunsurile relevante specificate de eroare se referă la probleme de conectare la ESXi se execută vCenter și tratate în mod normal, articol mi-a arătat, în primul răspuns, sau reporniți serviciul de management + actualizări minore, și având în vedere că vpxuser există la toate, eu sunt sigur că 99% din vCenter a fost cel puțin și poate că acum este. Anterior, atunci când este conectată la ESXi vSphere nu client`om a emis un mesaj pe care serverul este controlat vcenter`om?
Este greu de spus ce ar fi putut cauza pierderea accesului, dar având în vedere că acest lucru sa întâmplat după schimbarea parolelor, atunci acesta este motivul cel mai probabil, mă îndoiesc că în același timp ați ieșit din volum. În plus, dacă se întâmplă acest lucru, veți obține cel mai probabil un psd.
P.S. și ce parole au fost modificate?
Instalat vCentre în modul de încercare timp de 60 de zile. VCenter a avut norocul să se conecteze la cea de-a doua (bună) gazdă exsi și să citească lista de mașini virtuale din acesta, dar nu a fost permisă să o gestioneze - licența nu permite gestionarea prin vCenter. Pentru a vă conecta la un exsi gazdă, nu reușiți - în faza de bufferare intră într-un interval de timp.
De la modalitățile de rezolvare a problemelor de conectivitate - văd că încercați doar să puneți un test exsi pe serverul virtual și să încercați să reproduceți situația, apoi încercați să resetați / eliminați parola de la vpxuser și să vedeți ce se întâmplă.
>> Mai devreme la conectarea la client ESXi vSphere "nu a dat mesajul că acest server este controlat de vcenter"?
Nu - nu au existat astfel de rapoarte.
>> p.s. și ce parole au fost modificate?
Am schimbat contul rădăcină, vpxuser, dcui. Pe unele dintre aceste înregistrări a blestemat imposibilitatea de a schimba parola, dar nu-mi amintesc în mod specific ((.
Am scris deja că gazda ar trebui să fie ușor de gestionat, trebuie să înregistrați procesul și vSphere și să puneți cheia pe hypervisor:
În acest caz, pot oferi 2 soluții:
1. Rezolvați problema cu o probabilitate de 90% (în general, sunt mai mult decât sigur că decide). Rapid.
Restaurați ESXi la setările implicite. Resetați toate setările efectuate - de ex. setările de rețea, Wirth. rețele, etc. Șterge parola de root și repornește gazda. În acest caz, configurația utilizatorului dcui ar trebui să revină la valoarea implicită. Mașinile virtuale nu vor fi pierdute, dar vor trebui să fie reînregistrate pe gazdă (de la dataastore adăugați la inventar). Desigur, înainte de a prezenta mai bine cu esxcli sau powercli rândul său, în mod corespunzător de pe mașină și introduceți gazdă în meyntenans de moda. În cazul în care accesul la DCUI acolo (consola locală, care poate fi în echipa ssh sesiune de apel dcui), apoi funcționează în conformitate cu VMware vSphere 5.1 (acest articol pentru a citi, oricum), în cazul în care accesul la nu dcui, atunci nu există comandă ESXi: Sistem Reset Configurare.
2. Rezolva problema 100%. Dacă ESXi se află într-o seif separată de la vm - trebuie doar să reinstalați hypervisor (setările de rețea etc. trebuie, de asemenea, să fie efectuate din nou).
Actualizați: și mint. Nu am verificat niciodată prezența vpxuser-ului pe gazdă imediat după instalare, documentația spune că este creată de vCenter, am crezut că este tru. Cu toate acestea, dislocat 5.5 - și există vpxuser acolo, cu toate acestea în ce scopuri este folosit în ESXi standalone nu este clar.
Actualizare2: Încă nu eram complet greșit. În versiunile mai vechi ale ESX / ESXi, într-adevăr nu a existat vpxuser în mod implicit, până când gazda a fost inclusă în vCenter, dar în versiuni noi (6 și 5.5 exact) acest utilizator este preinstalat. Aici este thread-ul meu Re: vpxuser pe standalone ESXi. De asemenea, am facut un test: am schimbat parola de vpxuser si dcui si dupa aceea am restartat ESXi si nu am pierdut accesul fie prin intermediul clientului vSphere, nici prin ssh, nici in dcui. Poate ați făcut alte manipulări pe care ați uitat să le menționați?