Thursday Sep 16, 2010

Working with Fastprep in Oracle VDI

Oracle VDI has a feature to bypass the standard system preparation in Windows virtual desktops during the clone process. This feature is called Fast Preparation (Fastprep) and it reduces the clone time of a virtual desktop. In this article I want to share with you my experiences with Fastprep including some trouble-shooting tips.

For a successful clone operation in the Oracle VDI server, virtual machines for the Windows operating system requires customization. This is done after creation of the virtual machine when the cloned virtual machine starts-up for the first time. Fastprep changes the computer name of each virtual machine, it joins the domain and optionally you can execute your own post-customization script.

Fastprep does not require special preparation in the template before you clone, but before importing your virtual machine template in the Desktop Pool in the Oracle VDI Manager make sure:

  • The template is not a member of the domain, it must be a member of the workgroup.
  • Store your post-customization script in the template if that is required.

To configure Fastprep you have to fill in the following parameters (see the image):

  • Mandatory: windows domain, domain administrator, domain administrator password, desktop administrator (of the template) and desktop administrator password.
  • Optional: custom computer container DN and location of the post-customization script. 

Under the cover, during the clone process the Oracle VDI core mounts a floppy drive image in the virtual machine. The floppy image contains a program fastprep.exe that is executed when the virtual machine is started for the first time. I have seen some errors in this process, they were mainly related to how things in Windows works (and not related to Oracle VDI). A common error message was: Execution of command A:\\FASTPREP.EXE.... Below I will show you some trouble-shooting tips.

1. Increase Log level detail: 

The Oracle VDI Core service runs as a module within the Common Agent Container (Cacao) on the Solaris server. Error messages are stored in a log-file /var/cacao/instances/default/logs/cacao.0 and during your trouble-shooting you may increase the log-level of detail. This is done by the following CLI-commands:

root@vdiserver:~# cacaoadm set-filter -p com.sun.vda.service=ALL
root@vdiserver:~# cacaoadm stop -f
root@vdiserver:~# cacaoadm start

2. Keep the failed Virtual Machine: 

When the clone operation failed, the Oracle VDI Core removes the virtual machine and it tries to clone again by initiating a new clone process. You can configure Oracle VDI to disable clone cleanup after a failure. You do this with the following CLI-command on the Oracle VDI server:

root@vdiserver:~# /opt/SUNWvda/sbin/vda settings-setprops -p cloning.cleanup.failures=false

When you are finished with trouble-shooting you can configure it back to the default by setting the property to true.

3. Inspect Virtual Box VM Logfile:

After the change in step 2 your failed virtual machine keeps running on the Virtual Box server. In the VDI Manager it is registered in a reserved state and it will never be assigned to a user. In the VDI Manager you also see on which Virtual Box server your virtual machine is runing. Now you have time to inspect the Virtual Box virtual machine log file on the Virtual Box server. Go to the Virtual Box server with ssh (or putty from Windows):

root@vdiserver:~# ssh root@vboxserver
root@vboxserver:~# cd /root/.VirtualBox/Machines/VDA/<vmname>/Logs
root@vboxserver:~# more VBox.log

4. Access Virtual Machine through Console

If you want to inspect what is going on in your failed virtual machine, you can access your virtual machine through the console. This could be done in the VDI Manager, Desktop Console. See the below picture as an example:

As an alternative you can also use a rdp-client to access the vRDP server of the virtual machine. In the VDI Manager's Desktop Summary page you will find the IP port-number (on the Virtual Box server) of the virtual machine console. See the below picture:

With the uttsc (or rdesktop if you are not on a Sun Ray) client you can connect to the desktop console:  

root@vdiserver:~# /opt/SUNWuttsc/bin/uttsc -g 800x600 -P 49491 vboxserver

5. Test run Fastprep

When you are logged in your Windows virtual machine you can see that Windows has a mounted floppy drive A: and if you startup Command Prompt you can change directory to the floppy drive and run Fastprep:

C:\\Users\\adminuser> A:
A:\\> FASTPREP.EXE vmname 

On my Lab Oracle VDI server I had a problem in this step of the trouble-shooting process. I discovered the difference with a user with admin rights and an actual administrator in Windows 7. User Access Control (UAC) in Windows 7 prevented me to run the fastprep.exe program. I could change this behavior by changing elevation of user rights, but I took the easy way and decided to enable the actual Administrator in Windows 7.

I went back to my Windows template that I used as a source for the cloned images and I did the following in the Command Prompt of Windows 7:

C:\\Users\\adminuser> net user administrator /active:yes 

I also created a password for Administrator, halted the Windows 7 template, created a new revision in the VDI Manager and used this revision as the master for cloning in my pool. In the Fastprep specification I changed the Desktop Administrator property from adminuser to Administrator. After this change all my new clone operations in the pool did finish without errors.


I post here hands-on examples which I have used in my Oracle VDI Desktop Virtualization projects at customers and partners.


« July 2016