能，但象应该不会放进一同。毕竟vmware比较大，越到后面越大！而我们是需要给系统盘消耗很大点的空间。软件运行才会很流畅些
zabbix监控数据比较多两类：历史数据：history去相关表,history_uint表面查询设备监控项目平均值,即储存监控设备数据各种数。
zabbix优点：
1、数据采集：可用性和性能检测，自动出现发现到，接受agent、snmp、jmx、telnet等多种哪采，接受主动和被动模式数据传输、接受用户自定义插件，自定义设置间隔收集数据
2、高可用：server对设备性能要求低，接受proxy分布式监控，分布式几乎全部管理，有自动启动发现自己功能，这个可以利用自动化监控；两个开放接口，扩展性强，插件汇编语言很难
3、告警管理：接受多条件告警，支持多种告警，接受多组模板，模板无法继承。
4、告警设置：告警周期，告警级别，告警可以恢复通知、告警不能正常，时段阈值、支持什么维护周期、允许单机重新启动
5、图形化展示：容许下拉菜单修改多监控头项视图，网络拓扑，可以自定义面板展示，自定义it服务可用性
6、历史数据：历史数据查询可配置，内置housekeeping数据定期清理机制
7、安全审计：必须具备安全的用户审计日志，权限认证，用户可以不没限制不允许维护的列表。
zabbix缺点：
1、性能瓶颈，监控系统没有小看高峰期，更具持续性和周期性，机器量越大，数据的会增大会使数据库的写入文件成为一定会的瓶颈，官网具体的单机上限5000台，到那时就是需要提高proxy，提升成本。
2、zabbix采集数据有pull，也就是server拒绝模式，当目标机器量大之后，pull任务会直接出现积压。采集数据会延迟
3、项目二次开发，需要分析mysql表结构，表结构比较好复杂，实际api开发对开发能力有要求。
4、内置housekeeping在先执行过程中会对数据库增加压力，不需要对数据库进行系统优化
