[TSHOOT] – VMware PowerOn : A general system error occurred : Connection refused

de | 4 avril 2018

Hello !

Petit soucis hier en voulant démarrer une VM j’ai rencontré l’erreur suivante : A general system error occurred : Connection refused

Après quelques minutes de recherche notamment dans la KB VMware j’ai appliqué les quelques recommandations trouvées ici et là :

Vérifier le status du service vmware-vpx-workflow dans votre console vCenter

Dans un premier temps il faut vérifier le status  du service vmware-vpx-workflow en vous connectant en ssh à votre appliance vCenter.

vcsa-vdays:~ # service-control --status vmware-vpx-workflow
vcsa-vdays:~ # service-control --status vmware-vpx-workflow
INFO:root:Service: vmware-vpx-workflow, Action: status
Service: vmware-vpx-workflow, Action: status
2018-04-04T12:54:02.019Z   Running command: ['/sbin/service', u'vmware-vpx-workflow', 'status']
2018-04-04T12:54:02.098Z   Done running command
INFO:root:Stopped:
 vmware-vpx-workflow (VMware vCenter Workflow Manager)
Stopped:
 vmware-vpx-workflow (VMware vCenter Workflow Manager)

Si le service est stoppé, essayer de le redémarrer :

vcsa-vdays:~ # service-control --start vmware-vpx-workflow

Si le démarrage du service échoue avec ce message d’erreur :

vcsa-vdays:~ # service-control --start vmware-vpx-workflow
INFO:root:Service: vmware-vpx-workflow, Action: start
Service: vmware-vpx-workflow, Action: start
2018-04-03T13:00:52.415Z   Running command: ['/sbin/chkconfig', u'vmware-vpx-workflow']
2018-04-03T13:00:52.453Z   Done running command
2018-04-03T13:00:52.453Z   Running command: ['/sbin/service', u'vmware-vpx-workflow', 'status']
2018-04-03T13:00:52.513Z   Done running command
2018-04-03T13:00:52.513Z   Running command: ['/sbin/chkconfig', '--force', u'vmware-vpx-workflow', 'on']
2018-04-03T13:00:52.549Z   Done running command
2018-04-03T13:00:52.549Z   Running command: ['/sbin/service', u'vmware-vpx-workflow', 'start']
2018-04-03T13:01:08.572Z   Done running command
2018-04-03T13:01:08.572Z   Invoked command: ['/sbin/service', u'vmware-vpx-workflow', 'start']
2018-04-03T13:01:08.573Z   RC = 1
Stdout = VMware vCenter workflow manager is not running.
workflow port = 8088
Waiting for vpxd to initialize
Starting VMware vCenter workflow manager...
wrapper  | An encoding declaration is missing from the top of configuration file, /usr/lib/vmware-vpx/workflow/wrapper/conf/wrapper.conf, trying the system encoding.
wrapper  | An encoding declaration is missing from the top of configuration file, /etc/vmware/wrapper_common.conf, trying the system encoding.
wrapper  | An encoding declaration is missing from the top of configuration file, /etc/vmware/wrapper_linux.conf, trying the system encoding.
wrapper  | An encoding declaration is missing from the top of configuration file, /usr/lib/vmware-vpx/workflow/wrapper/conf/wrapper-classpath.conf, trying the system encoding.
wrapper  | Spawning intermediate process...
Waiting for VMware vCenter workflow manager..................
WARNING: VMware vCenter workflow manager may have failed to start.
Last login: Tue Apr  3 12:55:57 UTC 2018
Workflow start failed. Error code = 1

Stderr =
2018-04-03T13:01:08.573Z   {
    "resolution": null,
    "detail": [
        {
            "args": [
                "Command: ['/sbin/service', u'vmware-vpx-workflow', 'start']\nStderr: "
            ],
            "id": "install.ciscommon.command.errinvoke",
            "localized": "An error occurred while invoking external command : 'Command: ['/sbin/service', u'vmware-vpx-workflow', 'start']\nStderr: '",
            "translatable": "An error occurred while invoking external command : '%(0)s'"
        }
    ],
    "componentKey": null,
    "problemId": null
}
ERROR:root:Unable to start service vmware-vpx-workflow, Exception: {
    "resolution": null,
    "detail": [
        {
            "args": [
                "vmware-vpx-workflow"
            ],
            "id": "install.ciscommon.service.failstart",
            "localized": "An error occurred while starting service 'vmware-vpx-workflow'",
            "translatable": "An error occurred while starting service '%(0)s'"
        }
    ],
    "componentKey": null,
    "problemId": null
}
Unable to start service vmware-vpx-workflow, Exception: {
    "resolution": null,
    "detail": [
        {
            "args": [
                "vmware-vpx-workflow"
            ],
            "id": "install.ciscommon.service.failstart",
            "localized": "An error occurred while starting service 'vmware-vpx-workflow'",
            "translatable": "An error occurred while starting service '%(0)s'"
        }
    ],
    "componentKey": null,
    "problemId": null
}

C’est qu’il y a un problème ailleurs.

Vérifier la volumétrie des partitions du vCenter

vcsa-vdays:/var/log/audit # df -h
Filesystem                                              Size  Used Avail Use% Mounted on
/dev/sda3                                                11G  5.6G  4.7G  55% /
udev                                                    7.9G  164K  7.9G   1% /dev
tmpfs                                                   7.9G   40K  7.9G   1% /dev/shm
/dev/sda1                                               128M   41M   81M  34% /boot
/dev/mapper/core_vg-core                                 50G  185M   47G   1% /storage/core
/dev/mapper/log_vg-log                                  9.9G  9.9G    0G 100% /storage/log
/dev/mapper/db_vg-db                                    9.9G  884M  8.5G  10% /storage/db
/dev/mapper/dblog_vg-dblog                              5.0G  571M  4.2G  12% /storage/dblog
/dev/mapper/seat_vg-seat                                 25G  4.4G   19G  19% /storage/seat
/dev/mapper/netdump_vg-netdump                         1001M   18M  932M   2% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy                    9.9G  151M  9.2G   2% /storage/autodeploy
/dev/mapper/invsvc_vg-invsvc                            9.9G  1.5G  7.9G  17% /storage/invsvc

Dans mon cas la partition de log était full entrainant ainsi des problèmes pour générer les différents logs necessaires au bon fonctionnement du vCenter.

Pour faire un peu de place, vous pouvez supprimer les logs de type « java_error12049.hprof » :

vcsa-vdays:/var/log/vmware/vsphere-client # ls -l
total 280
-rw------- 1 vsphere-client users      0 Mar 30 22:27 java_error12049.hprof
drwxr-xr-x 3 vsphere-client root    4096 Apr  4 09:56 logs
-rw------- 1 vsphere-client users      0 Apr  2 11:46 vsphere-client-gc.log.0
-rw------- 1 vsphere-client users 102071 Apr  4 13:11 vsphere-client-gc.log.0.current
-rw------- 1 vsphere-client users   1957 Apr  4 09:51 vsphere-client-gc.log.1.current
-rw------- 1 vsphere-client users      0 Mar  9 08:19 vsphere-client-gc.log.2.current
-rw------- 1 vsphere-client users      0 Mar  9 06:10 vsphere-client-gc.log.3
-rw------- 1 vsphere-client users      0 Mar  9 06:25 vsphere-client-gc.log.4
-rw------- 1 vsphere-client users      0 Mar  9 06:40 vsphere-client-gc.log.5
-rw------- 1 vsphere-client users      0 Mar  9 06:56 vsphere-client-gc.log.6
-rw------- 1 vsphere-client users      0 Mar  9 07:11 vsphere-client-gc.log.7
-rw------- 1 vsphere-client users      0 Mar  9 07:26 vsphere-client-gc.log.8
-rw------- 1 vsphere-client users      0 Mar  9 07:42 vsphere-client-gc.log.9
-rw------- 1 vsphere-client users 167185 Apr  4 10:02 wrapper.log
-rw------- 1 vsphere-client users      0 Apr  3 12:26 wrapper.log.1
vcsa-vdays:/var/log/vmware/vsphere-client # rm -rf *.hprof
vcsa-vdays:/var/log/vmware/vsphere-client # df -h
Filesystem                                              Size  Used Avail Use% Mounted on
/dev/sda3                                                11G  5.6G  4.7G  55% /
udev                                                    7.9G  164K  7.9G   1% /dev
tmpfs                                                   7.9G   40K  7.9G   1% /dev/shm
/dev/sda1                                               128M   41M   81M  34% /boot
/dev/mapper/core_vg-core                                 50G  185M   47G   1% /storage/core
/dev/mapper/log_vg-log                                  9.9G  7.9G    2G  80% /storage/log
/dev/mapper/db_vg-db                                    9.9G  884M  8.5G  10% /storage/db
/dev/mapper/dblog_vg-dblog                              5.0G  571M  4.2G  12% /storage/dblog
/dev/mapper/seat_vg-seat                                 25G  4.4G   19G  19% /storage/seat
/dev/mapper/netdump_vg-netdump                         1001M   18M  932M   2% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy                    9.9G  151M  9.2G   2% /storage/autodeploy
/dev/mapper/invsvc_vg-invsvc                            9.9G  1.5G  7.9G  17% /storage/invsvc

Pour aller plus loin, on peux aussi remettre à 0 les logs ici :

vcsa-vdays:/var/log/vmware/cloudvm # :> cloudvm-ram-size.log

Et re-vérifier l’espace disque disponible :

vcsa-vdays:/var/log/vmware/cloudvm # df -h
Filesystem                                              Size  Used Avail Use% Mounted on
/dev/sda3                                                11G  5.6G  4.7G  55% /
udev                                                    7.9G  164K  7.9G   1% /dev
tmpfs                                                   7.9G   40K  7.9G   1% /dev/shm
/dev/sda1                                               128M   41M   81M  34% /boot
/dev/mapper/core_vg-core                                 50G  185M   47G   1% /storage/core
/dev/mapper/log_vg-log                                  9.9G  6.9G    3G  70% /storage/log
/dev/mapper/db_vg-db                                    9.9G  884M  8.5G  10% /storage/db
/dev/mapper/dblog_vg-dblog                              5.0G  571M  4.2G  12% /storage/dblog
/dev/mapper/seat_vg-seat                                 25G  4.4G   19G  19% /storage/seat
/dev/mapper/netdump_vg-netdump                         1001M   18M  932M   2% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy                    9.9G  151M  9.2G   2% /storage/autodeploy
/dev/mapper/invsvc_vg-invsvc                            9.9G  1.5G  7.9G  17% /storage/invsvc

Cool cool ! on a grapillé quelques Go 🙂 on commence à respirer.

Bon notre service vmware-vpx-workflow est toujours arreter je vous le rappel !

Par « sécurité » et parce qu’il peux y avoir des dépendances entre les services, il est préférable d’arreter tous les services et de laisser VMware les redemarrer dans le bon ordre, comme il faut. Cela n’a aucun impact sur votre prod, cela va juste rendre inaccessible l’accès à la console vSphere et vSphere Web Client.

vcsa-vdays:/var/log/vmware/cloudvm # service-control --stop --all
vcsa-vdays:/var/log/vmware/cloudvm # service-control --start --all

Si vous etes assez rapide, vous pourrez voir le démarrage du service défiler 🙂 :

INFO:root:Service: vmware-vpx-workflow, Action: status
Service: vmware-vpx-workflow, Action: status
2018-04-04T12:54:02.019Z   Running command: ['/sbin/service', u'vmware-vpx-workflow', 'status']
2018-04-04T12:54:02.098Z   Done running command
INFO:root:Running:
 vmware-vpx-workflow (VMware vCenter Workflow Manager)
Running:
 vmware-vpx-workflow (VMware vCenter Workflow Manager)

Nous voilà bon, avec un service up & running ! 🙂

 

Gestion des logs d’audit

On peux aller encore un peu plus loin. Si comme moi, vous avez définit un mot de passe root lors de l’installation du vCenter, et que vous n’êtes jamais revenu dessus alors il se peux qu’il soit expiré. En effet, par défaut, le mot de passe root de l’appliance VCSA expire tous les 365 jours. Si vous ne le modifié pas, alors, il collecte un certain nombre d’erreur et fait grossir le log audit.

Du coup dans un premier temps il faudrait modifier votre mot de passe root si celui-ci a expiré, ou sinon, faire en sorte qu’il n’expire pas. Vous pouvez faire cela en vous connectant à cette adresse :

  • https://yourvcsa.tld:5480

VCSA - Change root password

Ensuite on retourne sur le vCenter en SSH puis on relance la rotation des logs qui s’etait arreter à la fin de la période de validité du password root.

vcsa-vdays:/etc # logrotate -f /etc/logrotate.conf

Allez vérifier que les nouveau logs du jour sont bien générés et archivés :

vcsa-vdays:/var/log/audit # ls -lh
total 34M
drwx------ 2 root root 4.0K Mar 21  2017 audispd
-rw------- 1 root root 5.3M Apr  4 15:01 audit.log
-rw------- 1 root root 649K Jan 10 18:15 audit.log-20180110.bz2
-rw------- 1 root root 652K Jan 11 18:15 audit.log-20180111.bz2
-rw------- 1 root root 653K Jan 12 18:15 audit.log-20180112.bz2
-rw------- 1 root root 652K Jan 13 18:15 audit.log-20180113.bz2
-rw------- 1 root root 652K Jan 14 18:15 audit.log-20180114.bz2
-rw------- 1 root root 651K Jan 15 18:15 audit.log-20180115.bz2
-rw------- 1 root root 652K Jan 16 18:15 audit.log-20180116.bz2
-rw------- 1 root root 647K Jan 17 18:15 audit.log-20180117.bz2
-rw------- 1 root root 650K Jan 18 18:15 audit.log-20180118.bz2
-rw------- 1 root root 650K Jan 19 18:15 audit.log-20180119.bz2
-rw------- 1 root root 647K Jan 20 18:15 audit.log-20180120.bz2
-rw------- 1 root root 648K Jan 21 18:15 audit.log-20180121.bz2
-rw------- 1 root root 648K Jan 22 18:15 audit.log-20180122.bz2
-rw------- 1 root root 648K Jan 23 18:15 audit.log-20180123.bz2
-rw------- 1 root root    0 Apr  4 10:11 audit.log-20180404
-rw------- 1 root root  20M Apr  4 10:07 audit.log-20180404.bz2
drwx------ 2 root root 4.0K Jan 23  2017 auditd

Si jamais vous avez un log trop gros vous pouvez le supprimer ou le remettre à zero :

vcsa-vdays:/var/log/audit #:>audit.log-20180404

En espérant que cela vous aura été utile !

M.


Aller plus loin

Ici quelques KB Vmware pour aller plus loin dans la mise en place de la rotation des logs :

 

If you like this post, don't hesitate to share it !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *