记一次QuartzScheduler启动后无法正常执行定时任务的问题

最近想研究一下爬虫，由于爬虫工具服务端采用的是docker镜像的方式，为了让docker环境和系统环境分开（PS：纯粹不想在windows机让安装太多这些有一定的系统侵入的程序）所以就准备下载一个VMware，搞个虚拟机，然后在虚拟机上装个Centos，让爬虫在Centos上跑，结果Vmware装好后，我本地的一个项目正常启动后过去一直正常的定时任务不会跑了（后台没有任何报错，唯一的提示是，在项目启动时会报一个如下的提示：

  Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 20 threads.
  Using job-store 'org.springframework.scheduling.quartz.LocalDataSourceJobStore' - which supports persistence. and is clustered.

但是能够正常定时任务的时候也是有这个提示的，所以就各种查找原因，一直无解，后台只能度娘，有人刚好也碰到同样的问题，只是对方的原因是因为数据库IP地址换了，然后定时任务连不上数据库引起的，但是我的项目数据库IP没有变（项目启动时初始化参数及用户登录等功能都没有问题），但是联想到是因为IP地址变化引起的，而VMware在安装后会在系统中安装2个虚拟网卡，这VMware通过这两个虚拟网卡与宿主机通信，难道是因为加了虚拟网卡后quartz本身或本应用的某个功能在执行定时任务时需要从数据库里面读取配置信息，然后因为新装的虚拟网卡而造成找不到数据库了？想到做到，就果断把VMware的2个虚拟网卡给禁用掉了，so……，禁用后当场就能够正常执行了！

具体是怎么影响的，初步猜测是定时任务在连接数据库时，因为多了两个虚拟网卡，造成应用通过虚拟网卡的端口向外连接数据库（那玩意儿，肯定连不上哇），然后就一直连不上，还没有任何提示，后续有时间的话，希望能够详细分析一下原因。

PS：这玩意儿连上数据库也不吱一声，幸亏是安装VMware后当天执行的定时任务，不然估计还是多掉几根头发才能发现问题。