![在无头虚拟机中运行基于 GUI 的桌面软件](https://linux22.com/image/496031/%E5%9C%A8%E6%97%A0%E5%A4%B4%E8%99%9A%E6%8B%9F%E6%9C%BA%E4%B8%AD%E8%BF%90%E8%A1%8C%E5%9F%BA%E4%BA%8E%20GUI%20%E7%9A%84%E6%A1%8C%E9%9D%A2%E8%BD%AF%E4%BB%B6.png)
我正在处理一些“想要”从具有桌面的系统运行的软件(称为主软件包)。该软件调用其他软件包,这些软件包也作为桌面上的用户级应用程序运行(称为辅助软件包)。
这些辅助应用程序大多是基于 Windows 的程序,需要 GUI 才能运行,主程序包以编程方式按下辅助程序包上的按钮以实现所需的结果。其中一个辅助程序包是基于 DOS 的应用程序,使用按钮按下技术,而另一个辅助程序包实际上可以通过 OLE 自动化调用并直接驱动。(作为参考,辅助程序分析数据并生成主程序包将通过电子邮件发送的报告)
希望将此配置移至 VM,并可能使用 SrvAny 之类的东西将第一个应用程序强行塞入 Windows 服务。但是我相信当 VM 启动时默认情况下不会有桌面,所以我的问题是:
基于 GUI 的程序将会如何反应?
当主程序尝试调用它们但找不到桌面时,它们是否可能会崩溃?
Windows 会自动支持辅助程序吗?
或者我完全搞错了,运行 VM 确实创建了默认桌面?
客户操作系统很可能是 W2k3 服务器,托管在 ESX 3.5 上
顺便说一下,无头运行的原因是安全策略不允许无人值守的系统运行。
编辑
感谢您的回答 - 我不确定 VM 虚拟图形系统的机制。
至于安全政策,事后看来,我并没有以最好的方式解释它。我真正想说的是,有人向我提出了一个替代解决方案:
启动虚拟机
RDP 连接到虚拟机以获取桌面
启动软件
断开与虚拟机的连接(而不是注销),以便软件在该会话中继续运行
离开已断开连接但正在运行的 RDP 会话被视为不允许,这不是正常的 VM 功能。
然而
这确实提出了一个问题:是否有可能连接到软件将在其下运行的任何虚拟桌面?(以便我能够与它交互)(这听起来像是一个“鱼与熊掌兼得”的要求!)
答案1
尽管我不完全确定您正在运行的这个程序的目的是什么,以及这个误导性的“不允许无人值守系统运行的安全策略”是什么或者它解决了什么问题,但仍有许多虚拟机在没有 GUI 的主机操作系统上运行。
正如你所说ESXHost 没有 GUI。另一个不错的选择是虚拟盒它具有 VBoxHeadless 和 VBoxManage 命令集,可在无头(无 GUI)操作系统上运行和配置虚拟机。
客户操作系统(W2K3 或任何其他操作系统)的工作方式与在 GUI 主机中一样。操作系统就在那里,在“虚拟”图形适配器上运行。您可以通过 RDP 进入虚拟机,它具有基于 GUI 的操作系统,就像它是数据中心中的独立服务器一样。
总而言之,无论主机操作系统是否无 GUI,您的基于 GUI 的程序都将在带有 GUI 的普通客户操作系统中完美运行。
答案2
再次重申,虚拟机本身并不是“无头”的,如果您安装了运行 GUI 界面的操作系统,它会很高兴地认为它有一个在虚拟视频适配器上运行的 GUI 桌面。您可能没有任何东西实际连接到虚拟机实例来“看到”桌面,但它确实存在,就软件而言,它应该与真实的物理桌面没有什么不同。
它所运行的主机是否为无头系统都不会产生影响。事实上,这同样适用于独立系统。我也会严重质疑无人值守系统的安全策略——你如何处理标准服务器,它们肯定是无人值守运行的?