Descrizione

Questo articolo descrive come risolvere i problemi ed eseguire l'analisi della causa principale quando un CVM (Controller VM) si riavvia improvvisamente.

Log da cercare all'interno del CVM:

 dmesg /var/log/messages /home/log/messages (Avrà i log dettagliati del kernel al momento del riavvio.)

Log da cercare sull'host AHV:

 /tmp/NTNX.serial.out.0 /var/tmp/NTNX.serial.out.0 /var/log/libvirt/qemu/NTNX-
  
  -
   
  
   -CVM.log
   
  
  
  
 

Log da cercare all'interno dell'ESXi:

 /vmfs/volumi/NTNX-local-ds-
  
  -
   
  
   /ServiceVM_Centos/ServiceVM_Centos.0.out /vmfs/volumes/NTNX-local-ds-
    
   
    -
     
    
     /ServiceVM_Centos/vmware.log /var/log/vmksummary.log
     
    
    
    
   
   
   
  
  
  
 

Per esaminare l'utilizzo della memoria/della CPU/la latenza del disco del CVM al momento del riavvio, è possibile esaminare i sysstats nei log /home/nutanix/data/logs/sysstats . Tieni presente che i log hanno il timestamp UTC.

 /home/nutanix/data/logs/sysstats/meminfo.INFO
/home/nutanix/data/logs/sysstats/mpstat.INFO
/home/nutanix/data/logs/sysstats/iostat.INFO

Soluzione

Esempi

1. Ultimo riavvio del comando CVM:

    nutanix@cvm$ ultimo riavvio
   riavviare il sistema boot 2.6.32-279.9.1.e lunedì 23 dicembre 09:40 - 12:16 (02:36)

2. Registra su CVM /var/log/messages e kern.log :

    23 dic 09:40:06 Kernel NTNX-CVM-A: fioinf In attesa della creazione di /dev/fct0
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: rilevato fct0
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: settori_dimensione=512
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: il dispositivo funziona come dispositivo a blocchi.
   23 dic 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: impostazione dei dati dell'intervallo di canali su [2 .. 2047]
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: *** rilevato arresto non corretto, nuova scansione del registro. ***
   23 dic 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365GB 0000:03:00.0: *** l'operazione potrebbe richiedere diversi minuti.              ***
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: ************************ ***************************
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: interruzione di corrente rilevata
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: ricollegato con successo dopo un arresto non corretto.  (AP: 1942+228114432)
   23 dic 09:40:06 Kernel NTNX-CVM-A: fioinf Fusion-io ioDrive2 365 GB 0000:03:00.0: Creazione dispositivo a blocchi fioa: major: 252 minor: 0 dimensione settore: 512...
   23 dicembre 09:40:06 Kernel NTNX-CVM-A: fioa: fioa1

3. Registri ESXi /vmfs/volumes/xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxxxxxx/ServiceVM*/vmware.log :

    2013-12-23T17:35:25.959Z| vcpu-0| I120: Reset della CPU: soft (modalità 1)
   2013-12-23T17:35:25.960Z| vcpu-2| I120: Reset della CPU: soft (modalità 1)
   2013-12-23T17:35:25.960Z| vcpu-7| I120: Reset della CPU: soft (modalità 1)
   2013-12-23T17:35:25.960Z| vcpu-1| I120: Reset della CPU: soft (modalità 1)
   2013-12-23T17:35:25.960Z| vcpu-5| I120: Reset della CPU: soft (modalità 1)
   2013-12-23T17:35:25.960Z| vcpu-4| I120: Reset della CPU: soft (modalità 1)
   2013-12-23T17:35:25.960Z| vcpu-3| I120: Reset della CPU: soft (modalità 1)
   2013-12-23T17:35:25.960Z| vcpu-6| I120: Reset della CPU: soft (modalità 1)

   
   "Riavvia il sistema operativo guest" su CVM avviato da vCentre genera la seguente firma nel file vmware.log di cvm
   (Tieni presente che questa voce non è presente in vmware.log se il CVM è stato riavviato normalmente dall'interno del Nutanix Cluster tramite AOS Upgrade o il comando cvm_shutdown)

    2022-03-01T23:24:30.638Z| vmx| I125: Strumenti: invio richiesta di modifica dello stato 'OS_Reboot' (stato = 2).
   

   
   "Shutdown Guest OS" su CVM avviato da vCentre genera la seguente firma nel vmware.log di cvm
   (Tieni presente che questa voce non è presente in vmware.log se il CVM è stato spento regolarmente dall'interno del Nutanix Cluster tramite AOS Upgrade o il comando cvm_shutdown)

    2022-03-02T00:22:15.448Z| vmx| I125: Strumenti: invio richiesta di modifica dello stato 'OS_Halt' (stato = 1).
   

   
   Un altro esempio di vmware.log (basato sul bug VMware n. 676321):

    2013-07-17T22:35:53.907Z| vcpu-0| W110: PANICO MONITOR: vcpu-7:ASSERT vmcore/exts/hv/vt/hv-vt.c:1933 bugNr=676321
   2013-07-17T22:35:53.907Z| vcpu-0| I120: core dump con build build-838463
   2013-07-17T22:35:53.907Z| vcpu-6| I120: uscita da vcpu-6
   2013-07-17T22:35:53.907Z| vcpu-4| I120: uscita da vcpu-7
   2013-07-17T22:35:53.907Z| vcpu-0| W110: Scrittura del corefile del monitor "/vmfs/volumes/50630639-74fa7b98-830d-0025904c8605/ServiceVM-1.24_Ubuntu/vmmcores.gz"
   

   
   Un altro vmware.log (configurazione errata EPT - VMware KB 1036775 ):

    2013-05-03T17:27:43.262Z| vcpu-1| MONITOR PANIC: configurazione errata vcpu-0:EPT: PA b49b405b0
   2013-05-03T17:27:43.262Z| vcpu-1| Core dump con build build-623860
   2013-05-03T17:27:43.262Z| vcpu-1| Scrittura del corefile del monitor "/vmfs/volumes/51548019-3efd569e-d4d8-002590840e37/ServiceVM/vmmcores.gz"
   2013-05-03T17:27:43.262Z| vcpu-6| Uscita da vcpu-6
   

4. I registri ESXi /vmfs/volumes/xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxxxxxx/ServiceVM*/ServiceVM.out.0 mostra il problema driver jbd2/fio in questo esempio:

    ultimo file sysfs: /sys/devices/pci0000:00/0000:00:10.0/host2/target2:0:2/2:0:2:0/block/sdb/queue/scheduler CPU 0 Moduli collegati in: be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr i Pid: 3403, comm: jbd2/fioa1-8 Contaminato: P --------------- 2.6.32 -279.9.1.el6.nutanix.x86_64 #1 VMware, Inc. Piattaforma virtuale VMware/440BX Desktop RIP: 0010:[
       
       ] [
        
       
        ] jbd2_journal_commit_transaction+0x120c/0x14b0 [jbd2] RSP: 0018: FFFF880431113d30 EFLAGS: 00010246 RAX: 000000000000008 RBX: FFFFFF8804330D9800 RCX: 00000000 RDX: FFFF. 000 RSI: 0000000000000286 RDI: FFFF8804330D9800 RBP: FFFFF880431113E60 R08: FFFF880028216E90 R09: FFFF80028216F00 R10: 000000000018 R11: 000000000000 FFFFFF880028216f00 R10: 00000000000018 R11: 00000000000000 FFFFFF80028216F00 R10 R12: 0000000000000000 R13: FFFF8804330D9800 R14: FFFFF8804220A4AE0 R15: FFFFF8804330D9898 FS: 0000000000000000 (0000) GS: FFFF80028200000 (0000) 0018 ES: 0018 CR0: 000000008005003B CR2: 00007FBECA8A4916 CR3: 0000000378EF3000 CR4: 00000000000006F0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 000000000000400 Processo jbd2/fioa 1-8 (pid: 3403, threadinfo ffff880431112000, attività ffff8804220a4ae0) Stack:
        
       
       
       
      

5. Per eventuali guasti recenti del disco rigido, controlla il registro hades.out.

   Se l'SSD è l'unità dei metadati, AOS forzerà il riavvio di un CVM. Inoltre, se AOS ha problemi a rimuovere un HDD e una rimozione forzata viene attivata da hades, un CVM si riavvierà.

   L'output di ServiceVM.out.0 ( Bug 735768 ):

    BUG del kernel su fs/jbd2/commit.c:353! codice operativo non valido: 0000 [#1] Ultimo file sysfs SMP: /sys/devices/pci0000:00/0000:00:15.0/0000:03:00.0/host2/port-2:2/end_device-2:2/target2: 0:2/2:0:2:0/blocco/sdc/dev CPU 1

   
   ESXi vmksummary per verificare se l'host ESXi è stato riavviato:

    [root@esxi]# grep -i bootstop /var/log/vmksummary.log 2015-02-07T02:54:17Z bootstop: l'host si sta spegnendo 2015-02-07T08:43:04Z bootstop: l'host è stato avviato

   
   AVS:

    Registri di avvio del sistema dai registri di controllo sull'hypervisor
   
    11277 type=SYSTEM_BOOT msg=audit(1556350213.112:4): pid=4405 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='init exe="/sbin/telinit" hostname=? indirizzo=? terminale=console res=successo'
   11278 type=SYSTEM_RUNLEVEL msg=audit(1556350213.112:5): pid=4405 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='old-level=N new-level=3 exe=" /sbin/telinit" nomehost=? indirizzo=? terminale=console res=successo'
   

   
   CVM:

    nutanix@cvm$ sudo grep -i "kmsg avviato" /home/log/messages 2015-01-30T10:59:39.957663-08:00 Kernel NTNX-A-CVM: imklog 5.8.10, sorgente log = /proc/kmsg iniziato. 2015-02-07T00:46:55.164530-08:00 Kernel NTNX-A-CVM: imklog 5.8.10, sorgente log = /proc/kmsg avviato.

   
   Scorri qualche riga sopra per avere maggiori informazioni:

    nutanix@cvm$ sudo grep -i -B 5 "kmsg avviato" /home/log/messages 2015-02-06T18:00:02.539862-08:00 NTNX-C-CVM audispd: node=NTNX-C-CVM type= EOE msg=audit(1423274402.537:7498): 2015-02-06T18:00:02.578946-08:00 NTNX-C-CVM audispd: node=NTNX-C-CVM type=SYSCALL msg=audit(1423274402.577:7499): arch =c000003e syscall=90 success=yes exit=0 a0=251b700 a1=1ed a2=7f1ddb485a08 a3=7fff69bbdf30 items=1 ppid=8586 pid=9025 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid= 1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=150912 comm="python" exe="/usr/bin/python" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=" perm_mod" 2015-02-06T18:00:02.585360-08:00 NTNX-C-CVM audispd: node=NTNX-C-CVM type=SYSCALL msg=audit(1423274402.584:7500): arch=c000003e syscall=90 success=yes exit=0 a0=2894550 a1=1ed a2=7f1e2b955a08 a3=7fff0e433a48 elementi=1 ppid=8570 pid=9026 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid= 1000 fsgid= 1000 tty=(none) ses=150897 comm="python" exe="/usr/bin/python" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="perm_mod" 2015-02-06T18: 00:02.585392-08:00 NTNX-C-CVM audispd: node=NTNX-C-CVM type=PATH msg=audit(1423274402.584:7500): item=0 name="/home/nutanix/.python-eggs/simplejson -3.4.1-py2.6-linux-x86_64.egg-tmp/simplejson/tmp0cHe62.$extract" inode=365 dev=09:02 mode=0100600 ouid=1000 ogid=1000 rdev=00:00 obj=unconfined_u: object_r:user_home_t:s0 nametype=NORMALE

Per le versioni più recenti di CVM, potrebbe essere necessario eseguire il grep per "rsyslogd.*start" anziché "kmsg avviato":

 nutanix@cvm$ sudo grep -i "rsyslogd.*start" /var/log/messages 2018-03-06T03:28:13.648673-07:00 NTNX-C-CVM rsyslogd: [origin software="rsyslogd" swVersion=" 7.4.7" x-pid="1273" x-info="http:// www .rsyslog.com"] inizio 2018-03-06T03:28:13.647853-07:00 NTNX-C-CVM rsyslogd-2307: avviso: ~ l'azione è deprecata, prendere in considerazione l'utilizzo dell'istruzione 'stop' [prova www ] 2018-03-06T03:28:13.651494-07:00 NTNX-C-CVM systemd [1]: servizio di registrazione del sistema avviato.

Informazioni aggiuntive

• Nutanix KB 1252 - Documento originale nel portale Nutanix
• Pagina di destinazione di Nutanix
• Piano di supporto Lenovo ISG: dispositivo ThinkAgile HX e serie Lenovo Converged HX