Contents
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
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 :
Hello ! Maxime, fondateur et auteur indépendant de vDays.net. Je travaille dans l’IT depuis 6 ans, après avoir fait 5 ans d’apprentissages. Via ce blog, j’aimerais partager et échanger avec vous sur les nouvelles technologies, notamment sur la virtualisation et VMware. Si vous voulez en savoir plus sur moi, consultez ma page « à propos de moi » ou suivez-moi sur Twitter et LinkedIn.
Merci beaucoup pour cet article.
C’est claire et complet.
Merci encore pour le partage.