personal vDisk (PVD) was delivered as part of XenDesktop 5.6 last March. In the months since then, we presented PVD internal public as well as Synergy last month in San Francisco. One of the topics that seems to come frequently is troubleshooting and logging
PVD keeps two types of logs -. One for the file system driver PVD and one for user mode service. The file system driver is the central part of making the PVD / O interception and redirection I, providing persistent personalization for XenDesktop VDI VMs. The user mode service performs the fusion of updates basic image PVD disks as needed, and manages the PVD disk.
I would like to take some time today to walk through the contents of one of PVD log files, namely PVD log file system driver. This log contains useful information for troubleshooting / diagnostic PVD virtual machines that will not start, and also when diagnosing possible problems of application compatibility. In the next installment, I will cover the service log in PVD user mode
The PVD file system driver of the log is maintained at the root of PVD disk (by default, it will appear as P :. VMs in your pool unless you have changed the drive letter of during the creation of the catalog.) the log is named IvmSupervisor.log (IVM is the PVD driver name of the file system).
start by looking at the newspaper, a section at a time. For brevity, I excluded logfile entries that are not relevant:
200628 23: 48: 56.258 00000001 1 07 0 0 00 0004 0008: IvmLog full initialization 20,0,628 23: 48: 56.258 00000002 January 07 0 0 00 0004 0008: Ivm REL built 0:36:44 Friday, November 4, 2011. (note that is different from the last time modified) 20,0,628 23: 48: 56.258 00000003 January 05 0 0 00 0004 0008: filtering initialized the registry
1. the section above is recorded when starting a new VM boot pool. Since PVD continually add to this file (and rotate the contents after reaching 10MB in size), you can quickly identify a VM start by searching the above lines. Another way to tell when a restart took place is to watch the third field in the journal entry - the first log entry is indexed 00000001, 00000002 next, and so on. These counters reset at each start
200628 23 :. 48: 56.258 00000007 1 23 0 0 00 0004 0008: IvmNativeStart: started the thread wait for the VHD and start the session 20,0,628 23: 48: 56.258 00000008 2 02 0 0 00 0004 0008: IvmStateChange: current driver status StateRunning, state 0x0 20,0,628 23: 48: 56.258 00000009 2 02 0 0 00 0004 0008: DriverEntry: load drivers, status 0x0 20,0,628 23: 48: 56.273 0000000A 1 07 0 0 00 0004 00DC: timer manager started with 32 timers 200628 23: 48: 56.273 0000000B January 02 0 0 00 0004 00E4: volume of the wireless processing function began, waiting for starting pilot to start 200628 ... 23: 48: 56.476 0000000C January 02 0 1 00 0004 0038: PNP notification for volume [??STORAGE#Volume#{80ce1f02-4150-11e0-9ce2-806e6f6e6963}#0000000000100000#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}] 200628 23: 48: 56.710 0000000D 1 02 1 0 00 0004 0038: PNP notification for volume [??STORAGE#Volume#{80ce1f02-4150-11e0-9ce2-806e6f6e6963}#0000000006500000#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}] 200628 23: 48: 56.710 0000000E 1 02 1 0 00 0004 0038: PNP notification for volume [??STORAGE#Volume#{7ebbc0e7-c1b6-11e1-b653-806e6f6e6963}#0000000000010000#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}] 200628 23: 48: 56.726 0000000F 1 02 1 0 00 0004 0038: PNP notification for volume [??STORAGE#Volume#{7ebbc0e8-c1b6-11e1-b653-806e6f6e6963}#0000000000100000#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}] 2. the first thing PVD is when it starts is to try locate its volume (which is created and attached to the VM and stores the user's personalization data) .To do this, the PVD registers for notification for each volume in the system, so it can examine each to determine if it is the right (more on how this is done soon ...) In this particular system, there are four volumes
200628 23 :. 48: 57.911 00000012 1 02 0 0 00 0004 00E4: processing function WI treatment volume now notifications 20,0,628 ... 23: 48: 57.911 00000013 1 02 0 0 00 0004 00E4: volume processing function WI volume dequeued [??STORAGE#Volume#{7ebbc0e8-c1b6-11e1-b653-806e6f6e6963}#0000000000100000#{53f5630d-b6bf-11d0-94f2-00a0c9 1efb8b}] 200628 23: 48: 57.911 00000014 1 02 0 0 00 0004 00E4: processing function WI volume check the volume [??STORAGE#Volume#{7ebbc0e8-c1b6-11e1-b653-806e6f6e6963}#0000000000100000#{53f5630d-b6bf-11d0-94f2-00a0c9 1efb8b}] 200628 23: 48: 57.989 00000016 1 03 1 0 00 0004 00E4: seal the volume [Ntfs] [DeviceHarddiskVolume4] on \ Volume {7ebbc0ee-c1b6-11e1-b653-806e6f6e6963} 3. Then PVD inspects each volume, looking for a "PVD footprint" - ie presence of a special GUID file located in the root of the volume, and a VHD file called "UserData.vhd" - this is the VHD file that contains the user's installed applications (not profile)
200628 23 :. 48: 58.020 00000017 1 02 0 0 00 0004 00E4: previous PUD size was 10,737,418,240 20,0,628 23: 48: 58.020 00000018 1 02 0 0 00 0004 00E4: file drive letter V 200628 23: 48: 58.020 00000019 January 02 0 0 00 0004 00E4: PUDSplit from the file is 5000 20,0,628 23: 48: 58.020 0000001A January 02 0 0 00 0004 00E4: IvmBootpCheckAndStartIvm: found the recomposition guard file 20,0,628 23: 48: 58.020 0000001B January 02 0 0 00 0004 00E4 : our volume begins at offset 1048576 and 10736369664 bytes long on disk 2 200628 23: 48: 58.036 0000001C 1 02 0 0 00 0004 00E4: saved new size of PUD 10737418240
4. If PVD is an appropriate volume (eg, one corresponding to the above features), it then checks if the file system on this volume to be resized. In this case, size "desired" (10GB) is the previous size (10GB), so no resizing is to occur. If a new size was to be desired (say, for example, the administrator opened the hypervisor console and increasing the size of the disc), PVD would load NTFS to resize the current file systems use (in the PVD disk and the VHD application zone)
20,0,628 23 :. 48: 58.036 0000001D January 02 0 0 00 0004 00E4: IvmBootpCheckAndStartIvm: try to mount the VHD 20,0,628 23: 48: 58.036 0000001E 1 02 0 1 01 0004 00E4: IvmBootpMountAndCheckVhdFile: brand that we found a VHD so we should wait any longer. 200628 .. 23: 48: 58.067 00000020 1 02 0 0 00 0004 00E4: IvmBootpMountAndCheckVhdFile VHD is mounted, check if it is a good thing. 200628 23: 49: 01,000 00000025 1 02 0 0 00 0004 00E4: IvmBootpCheckAndStartIvm: reg hive loaded, creating symbolic links 200628 Volume 23: 49: 01,000 00000026 1 02 0 0 00 0004 00E4: IvmBootpCheckAndStartIvm: Event setting to signal the session can be started
5. If the volume has been resized successfully (or if no resizing was desired), PVD will mount the VHD application and allow the machine to continue booting (remember -you, all that we have described so far occurs very early in the Windows startup sequence - in the case of Windows 7, these operations occur just after the Windows logo begins its "pulse" animated during startup )
200628 23 :. 49: 01,000 00000027 1 23 0 0 00 0004 00E8: IvmpNativeSessionCreationFunction: Try to start the session 200628 ... 23: 49: 01,000 00,000,028 1 06 1 0 00 0004 00E8: Starting NativeMode session 20,0,628 23: 49 : 01,000 00000029 1 03 1 0 00 0004 00E8: layer 0 -> {7ebbc0ef volume real-c1b6-11e1-B653 -806e6f6e6963} [DeviceHarddiskVolume2] 200628 23: 49: 01.000 0000002A 1 03 1 0 00 0004 00E8: layer 1 - > {7ebbc0f6-volume real-c1b6-11e1 b653-806e6f6e6963} [DeviceIvmVhdDisk00000001] 200628 23: 49: 01.016 0000002b 1 23 0 0 00 0004 00E8: IvmpNativeSessionCreationFunction: started the session! 200628 23: 49: 01.016 0000002C 1 07 0 0 00 0004 00E4: IvmLogSwitchToFile: relocation log to the ?? STORAGE # Volume # {7ebbc0e8-c1b6-11e1-b653-806e6f6e6963} {# 0000000000100000 # 53f5630d-b6bf-11d0- 94f2-00a0c91efb 8b} IvmSupervisor.log, see you there! 200628 23: 49: 01.016 0000002D January 07 0 0 00 0004 00E4: IvmLogSwitchToFile: after the passage of the log file 200628 ... 23: 49: 01.016 0000002e 1 02 0 0 00 0004 00E4: moved to the log file volume PUD .. . 200628 23: 49: 01.016 0000002f January 02 0 0 00 0004 00E4: find the right volume, the output volume of processing loop 200628 23: 49: 01.016 00000030 1 02 0 0 00 0004 00E4: IvmBootpVolumeProcessingWIFunction: volume notification deregistration ... 6. PVD then moved his newspapers on the PVD disc - until we have determined that we have the right to use one, the newspapers were buffered by memory. The last piece of work that happens is for developing countries to start applications / O interception under normal operation. The way this happens (as shown above by the two layer indicators) is beyond the scope of this blog entry, but you can learn about it if you are interested in looking at the record SYN119 video Synergy last month (available on CitrixTV.)
If you look at the time stamps on the log entries, you will see that the total time to perform all operations is slightly less than 5 seconds.
Log above walkthrough illustrates a successful, normal start. In cases where errors occur, you will see the appropriate error messages. In the QuickStart chess, the typical cause is a missing disk - PVD wait up to 30 seconds for all volumes of "appear" on the machine before it gives up and leaves the startup procedure (without PVD / customization activated ). If you see two log entries that have a 30s break between time stamps, chances are good that your Purchaser (PVS or MCS) failed to properly attach the volume and PVD expired waiting for the disk to appear . That, or perhaps you have slower hardware. The startup 30s timeout can be set either higher or lower in the VM basis (see video SYN119 for the location of this configuration setting.)
Another error you might see in this log file would be a mistake when resizing the volume, but this is less frequently observed and generally attributed to poor configuration.
After starting this logfile is conveniently silent. However, it is possible that in some circumstances, you might see additional log entries after the VM has started with PVD success. These log entries are made by developing countries when he meets a registry key / value or file that may not work for some reason on (corruption, unsuitable ACLs, etc.). We generally see some of these appear in the log when clients have application compatibility problems, and these log entries usually help us track down where the issue might be.
Next time, we'll walk through the user mode service log PVD, which contains information about the update operations of the image and the application of the difference. See you!
0 Komentar