Vmguest.iso

[Mohammed Huberty]

Whencreating a conversion to virtual machine job, the location of the ISO image file must be entered. The file is needed to enable the installation of the drivers for the appropriate hyper visor during the conversion job.

In the Full path of Hyper-V Integration Components ISO image field, enter the location of your Hyper-V Integration Components ISO image. The ISO image is needed to make the virtual machine bootable. Path to ISO image on Hyper-V server is \Windows\system32\vmguest.iso

Note: This option is not available for Hyper-V servers that run on Windows 2016 or later. Such Hyper-V servers install integration services directly on the virtual machine either through a Windows update or a user-initiated download.

In the Full path of VMware Tools ISO image field, enter the location of your VMware Tools ISO image. The path should be accessible with the default credentials. The path should also be local to the Backup Exec server. The ISO image is needed to make the virtual machine bootable.

Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.

Hyper-V Integration Services enhance virtual machine performance and provide convenience features by leveraging two-way communication with the Hyper-V host. Many of these services are conveniences, such as guest file copy, while others are important to the virtual machine's functionality, such as synthetic device drivers. This set of services and drivers are sometimes referred to as integration components. You can control whether or not individual convenience services operate for any given virtual machine. The driver components are not intended to be serviced manually.

Each service you want to use must be enabled in both the host and guest in order to function. When you enable a service in the host, it automatically starts running in the guest. All integration services except Hyper-V Guest Service Interface are on by default on Windows guest operating systems. The services can be turned on and off individually. The next sections show you how.

Some features may not work correctly or at all if the guest's integration services are not current. To get the version information for Windows, sign in to the guest operating system, open a command prompt, and run this command:

In order for an integration service to be fully functional, its corresponding service must be running within the guest in addition to being enabled on the host. In Windows guests, each integration service is listed as a standard Windows service. You can use the Services applet in Control Panel or PowerShell to stop and start these services.

Stopping an integration service may severely affect the host's ability to manage your virtual machine. To work correctly, each integration service you want to use must be enabled on both the host and guest.As a best practice, you should only control integration services from Hyper-V using the instructions above. The matching service in the guest operating system will stop or start automatically when you change its status in Hyper-V.If you start a service in the guest operating system but it is disabled in Hyper-V, the service will stop. If you stop a service in the guest operating system that is enabled in Hyper-V, Hyper-V will eventually start it again. If you disable the service in the guest, Hyper-V will be unable to start it.

Integration service daemons that might be listed include the following. If any are missing, they might not be supported on your system or they might not be installed. Find details, see Supported Linux and FreeBSD virtual machines for Hyper-V on Windows.

We recommend that you keep integration services up to date to get the best performance and most recent features for your virtual machines. This happens for Windows guests by default if they are set up to get important updates from Windows Update. Linux guests using current kernels contain integration services built in, but there may be optional updates available. You will receive the latest integration components when you update the kernel. For more information about Linux guests, see Supported Linux and FreeBSD virtual machines for Hyper-V on Windows.

The image file Integration Services disk (vmguest.iso) isn't included with Hyper-V starting with Windows Server 2016 and Windows 10 because it's no longer needed. Windows Server 2012 and older require the Data Exchange integration service. If the Data Exchange integration service can't be enabled, integration services for these guests are available from the Download Center as a cabinet (cab) file. Instructions for applying a cab are available in this Microsoft TechCommunity blog post. If your Hyper-V host is running Windows Server 2012 R2 and older, see the next section for how to install or update integration services.

From the Action menu of Virtual Machine Connection, select Insert Integration Services Setup Disk. This action loads the setup disk in the virtual DVD drive. Depending on the guest operating system, you might need to start the installation manually from File Explorer.

The solution is to copy the vmguest.iso file from an existing Hyper-V 2012 R2 installation to the 2016 Hyper-V server. Then mount this ISO to the DVD Drive of the guest VM. Then in the OS of the VM run the installer.

The only caveat is that you must have a special service running on the client to read and write with the shared space and the Registry location. This service is automatically present in Windows 8 and Windows Server 2012, and is available with the optional integration components available on the client vmguest.iso image. There is some work necessary to get the integration services working on WinPE.

Within the UserExit.vbs Script, we then load the driver, Create a *Fake* Remote Desktop Service, and start the Key Value Pair exchange service. Now we can read and write to the registry. Any Value in the registry, will be picked up by the script and loaded into MDT Litetouch.

I recently needed to reproduce a customer issue in my lab environment. My lab is a Windows 10 workstation with the Hyper-V role installed. Part of reproducing the issue involved building out a Windows Server 2012 R2 Foundation virtual machine. I figured this would not be a problem as 2012 R2 runs fine as a virtual machine. This was not the case though. I ran into a major hurdle with the integration tools. I will describe the process I went through to get a Windows Server 2012 R2 Foundation virtual machine running smoothly.

Now before anyone goes out and tries the below procedure for a production system, please understand that running Foundation edition as a virtual machine is not supported by Microsoft. Also it will likely violate the EULA (End User License Agreement). Typically Foundation edition is only sold with an OEM license. That means it comes pre-installed on hardware and must remain on that hardware. So in order to do this, and not violate the EULA, a non-OEM license is required. I have a MSDN subscription and thus have a valid license. Additionally, I am not running the server for any type of production workload.

I started the process by creating a generation 2 VM (virtual machine). Unfortunately I found out this will not work as the VM bugchecked during setup. I deleted that VM and created a generation 1 VM. I was then able to get the Windows loaded. This is when I discovered the major hurdle I mentioned above. The VM responded very slowly to mouse and keyboard input. I also noticed severely degraded performance. This was to the point of the VM almost being unusable. The VM behaved as if none of the integration services drivers were installed. Unfortunately Windows 10/2016 do not have the option to insert the integration disk. I was able to get the vmguest.iso from a 2012 R2 hyper-v host. However when I tried to run the setup I was informed that the latest integration services were already installed.

At this point I realized this was not going to be easy, but I enjoy a challenge. I browsed the vmguest.iso inside the Foundation VM. I extracted the following file: D:\support\amd64\Windows6.2-HyperVIntegrationServices-x64.cab. I then went into device manager. I noticed quite a few, a dozen or so, unknown devices.

I then tried to manually load the drivers from the extracted cab file. While the driver was found, it was not signed. I figured no sweat, just disable driver signing requirement in the BCD (Boot Configuration Data). Yet another roadblock. It is no longer possible to permanently disable driver signature enforcement. I was able to boot into driver signature enforcement disabled mode. I then manually loaded drivers for all the Unknown devices. This corrected the input and performance issues, at least for that boot. Booting into normal mode caused all the issues to return.

Getting the drivers to load each time Windows booted was the final step in getting the virtual machine to run properly. I looked into the bcdedit command line options and was not able to find an option to boot to driver signing disabled mode. What I ended up doing was to add a dummy entry to the boot list and set the timeout to 30 seconds with the following commands.

I am trying to install VMW Windows 2012 R2 foundation on the Windows 2012 R2 host. After completing the installation it is asking for administrator account password but does not take the mouse input or keyboard input. I have inserted the integration disk vmguest.iso in the VM, but keep getting this error message

Microsoft Azure does not officially provide Windows XP images for the creation of virtual machines running this legacy operating system. As of now, the earliest version of a client OS image available on Azure is Windows 7, which additionally requires a Visual Studio subscription to access. Despite this, I have devised a method to operate legacy Windows operating systems, including Windows XP, on the current Azure compute platform. While there is little practical reason to use Windows XP in today's environment, my goal is to demonstrate the feasibility of this endeavor. In this blog post, I will outline the steps involved in this process in detail. I hope you find the journey as enjoyable as the destination.

3a8082e126