Archive for January, 2011

VMware View 4.5 real-time usage statistics pt2

January 5, 2011 Leave a comment

I have redone my trigger for pool-based usage stats. In looking through the event log table I found that there was not always an AGENT_DISCONNECTED record for all user logoff events. I don’t know if it is dependent upon whether the user logs off or just disconnects or what, but it seems like there are always BROKER_DESKTOP_REQUEST and AGENT_ENDED both of which contain the pool in a field called DESKTOPID.

So now I am basing my logic on those two types. If I get BROKER_DESKTOP_REQUESTED, I then get the count from the table based on that pool, then increment it. Same goes for the AGENT_ENDED event, I get the count from a table (which is pre-populated with pool names of course) and then decrement the count. Works great so far, but my users are not back in full swing yet so we’ll see how things go when there’s some real load on the View infrastructure.

So, to recap it looks like a View client login/logout shows up in the event table as follows:


This is on a floating pool with View Composer set to refresh the machine at logoff. I guess now only time will tell how well this works. The database server shouldn’t have a problem with the extra bit of load from the trigger.. I’m sure I’ll find out soon enough if it doesn’t work. Everyone knows where my office is ūüėČ

Categories: View, Vmware

VMware View 4.5 real-time usage statistics

January 4, 2011 3 comments

I was somewhat disappointed by the lack of usage information from View 4.5. Specifically that I had to login to the admin side of a connection server to find out how many machines were in use out of a given pool.

The data that View stores is in ADAM and in searching the net, I’ve not found a good way to query that data. What I’d like to do is have a webpage that shows how many desktops are in use or available for a given pool.

I had already started parsing the View Event database for historical statistics (users per day, average length of time logged on, busiest days etc) but nowhere in there was an easy method to just go “hey, there are 75 people on right now”

What I came up with (this may or may not work in your environment) was to put an AFTER INSERT  trigger on the viewevent table. The trigger either increments or decrements a counter in a table on a remote-linked server that is accessible to my web server.

At this point I am not looking at specific pools, only overall usage. There are a few event types in the log table that you can use and it all depends on which one you want to pick as the definitive “a user logged on” event for the trigger:


For me, the most obvious seemed to be to base counts on the BROKER_USERLOGGED -IN and -OUT¬†event types. The issue with these is that in the record, neither the pool nor the desktop are listed. Only the userid of the person logging in and the name of the View Connection server. If you based your trigger on the “AGENT_CONNECTED” event type, you have the name of the user and the name of the responding desktop. If you use BROKER_DESKTOP_REQUEST then you have the name of the pool.

I didn’t want to make my trigger complex at this point so I am just getting an overall/aggregate usage for all pools.

Basically my trigger is as follows (note, I removed the linked server name and some other specific data, this code is NOT guaranteed to run as-is or at all):
--written by Paul Dunn
--(C) 2011
--will increment/decrement a counter for view usage based on event type
--in the viewevent table
ALTER TRIGGER [test1]    ON  [dbo].[viewevent]  
  AFTER insert
declare @etype as varchar(50),
@count as int
 -- SET NOCOUNT ON added to prevent extra result sets from
 -- interfering with SELECT statements.  
select @etype = [EventType] from inserted  
select @count = (select num from view_usage where poolid = 1)  
update view_usage set num = (@COUNT + 1)
 if @count> 0   
update view_usage set num = (@COUNT - 1)  

Now all I have to do it query that value in the table and display it on the page. I have the tables setup so that I can track usage by pool, which makes more sense than all users, but this is a start at least. This should also help get others off my case as I run View 4.5 pools for 3 other departments besides my own and now I don’t have to give them access to the admin side for them to see the usage on their pools.

I am going to re-write this eventually so that it will be pool-based, shouldn’t be that big of a deal, just means using a different event type in the table and parsing out the name of the pool. Could even go so far as to grab the name of the logged in user, although at this point I don’t see much use for that.

Categories: View, Vmware