VMware Horizon Community
CameronUBC
Enthusiast
Enthusiast
‎01-21-2015 06:55 PM
Jump to solution

Corrupt User Profiles With Persona

Hi All,

I'm currently trying to track an intermittent problem with corrupt user profiles when using persona management on View desktops. We've been having hardware problems lately, so user's VMs have been going down while they're logged in. We've been having some corrupt profiles happen a lot recently and I think they're related. While I'm not surprised that user profiles get corrupt if a VM if the host it's running on goes down, I'm wondering what the expected behavior is supposed to be in the following cases:

1) VM of logged in Persona user gets reset via View Administrator

2) Host goes down or datastore detaches while user is logged into VM with persona management enabled.

I've noticed on the persona share a hidden directory and lock files called "{08C31585-259A-4341-9982-78E42EAF6106}\computername.0.lck". A VMware support engineer has told me that Persona management does not create this folder and file. However, when I go to delete it, it tells me that the file is currently opened by "VMWare Horizon View Persona Management". I'm guessing the support engineer was wrong and this is how Persona management maintains the profile to be used by one logged in user at a time.

Can someone explain to me how this is supposed to work? Is profile corruption an expected result of a VM of a logged in user being reset, or is this considered a bug? If the lock file doesn't get cleaned up properly, what is the expected behavior?

Thank you

Cameron

0 Kudos
1 Solution

Accepted Solutions
ErikTatum10
VMware Employee
VMware Employee
‎01-22-2015 08:02 PM
Jump to solution

Hi Cameron,

For the purposes of this explanation, power outage, reset, and crash are the same.

I'm not sure whether you have floating or persistent desktops, but that's important because it affects the way this all works.  Floating desktops create interesting challenges in power outage scenarios with respect to data loss.  On persistent desktops  the local profile is on the desktop and if the machine crashes the data can be recovered on the next logon (assuming the data was successfully written to disk before the power went out).  This is not the case with floating desktops unless the user is lucky enough to get reassigned to the same desktop on the next logon, which is not likely.

That said, here's some details of how the replication engine works.  Every ten minutes (default) or whatever you have configured, the changes made during that interval are uploaded to a hidden temporary directory in the root of the roaming profile.  This folder name is a guid that starts with {d2...}.  Once that step is complete, the data is merged into the roaming profile itself.  If something like a crash or a reset happens before or during the upload to the temp directory, the upload is considered invalid and thrown out.  Anything else would result in a corrupt profile (i.e. a partial upload would result in a profile that is not in a crash-consistent state).  So, if a user changes a file and the machine goes down before all of the data from the delta is uploaded, the changes would be lost on a floating desktop scenario.  The replication engine is designed to ensure a crash-consistent state in the roaming profile in all cases where it's possible for us to ensure that.

So, if the VM of a logged on user gets reset or crashes, it's very likely the user can lose data for the reasons I explained above.

If the host goes down, I think this is a similar scenario as the VM crashing.  If the datastore hosting the desktop goes down, I think this is again a crash scenario.  If the connection to the central profile store is lost during the user's session, Persona will cache the changes locally and replicate them once the connection is restored.  Again, things get complicated if the user logs off while the CPS is disconnected on a floating desktop or if refresh on logoff is enabled.

You are correct, "{08C31585-259A-4341-9982-78E42EAF6106}\computername.0.lck" is created by Persona and it is how we ensure only a single session is replicating to the roaming profile.  I'm sorry the support person told you this is not created by Persona.  They were definitely wrong.  Unfortunately, if the desktop loses power while Persona is holding this lock, sometimes the file server will not receive the signal to release the lock.  This not really a Persona bug as much as it is a catch-22 within the file system.  Imagine you and I were on the phone and I pulled the plug on my end, but you kept hearing my voice.  You wouldn't know to hang up because I kept talking and didn't say goodbye.  Basically, the file server isn't hearing "goodbye" and doesn't release the lock.  The file server should release the lock when the Persona service process stops (even if Persona didn't close it explicitly), but that doesn't happen cleanly in a this kind of situation, so it doesn't get the "goodbye" message.  I am not sure if this a persistent bug in Windows, NTFS, etc of it's a design issue that Microsoft cannot work-around.

The profile will not work correctly again until the lock is cleaned up.  At this time, the only way I currently know to clean up the orphaned file locks is to reboot the file server.

So, yes, we can expect data loss to happen if the desktop is reset unexpectedly and the data hasn't been replicated yet in some cases.  Sounds like this may be what you are experiencing.  Profile corruption is a term often misused.  In your case, I think you are seeing data loss due to the outages, not profile corruption.  I would expect your roaming profile to be in a crash consistent state, but missing the last set of changes the user made.  Is that what you are seeing?

I hope this helps to answer your questions.  If not, please feel free to ask more.

Thanks,

Erik

View solution in original post

0 Kudos
2 Replies
ErikTatum10
VMware Employee
VMware Employee
‎01-22-2015 08:02 PM
Jump to solution

Hi Cameron,

For the purposes of this explanation, power outage, reset, and crash are the same.

I'm not sure whether you have floating or persistent desktops, but that's important because it affects the way this all works.  Floating desktops create interesting challenges in power outage scenarios with respect to data loss.  On persistent desktops  the local profile is on the desktop and if the machine crashes the data can be recovered on the next logon (assuming the data was successfully written to disk before the power went out).  This is not the case with floating desktops unless the user is lucky enough to get reassigned to the same desktop on the next logon, which is not likely.

That said, here's some details of how the replication engine works.  Every ten minutes (default) or whatever you have configured, the changes made during that interval are uploaded to a hidden temporary directory in the root of the roaming profile.  This folder name is a guid that starts with {d2...}.  Once that step is complete, the data is merged into the roaming profile itself.  If something like a crash or a reset happens before or during the upload to the temp directory, the upload is considered invalid and thrown out.  Anything else would result in a corrupt profile (i.e. a partial upload would result in a profile that is not in a crash-consistent state).  So, if a user changes a file and the machine goes down before all of the data from the delta is uploaded, the changes would be lost on a floating desktop scenario.  The replication engine is designed to ensure a crash-consistent state in the roaming profile in all cases where it's possible for us to ensure that.

So, if the VM of a logged on user gets reset or crashes, it's very likely the user can lose data for the reasons I explained above.

If the host goes down, I think this is a similar scenario as the VM crashing.  If the datastore hosting the desktop goes down, I think this is again a crash scenario.  If the connection to the central profile store is lost during the user's session, Persona will cache the changes locally and replicate them once the connection is restored.  Again, things get complicated if the user logs off while the CPS is disconnected on a floating desktop or if refresh on logoff is enabled.

You are correct, "{08C31585-259A-4341-9982-78E42EAF6106}\computername.0.lck" is created by Persona and it is how we ensure only a single session is replicating to the roaming profile.  I'm sorry the support person told you this is not created by Persona.  They were definitely wrong.  Unfortunately, if the desktop loses power while Persona is holding this lock, sometimes the file server will not receive the signal to release the lock.  This not really a Persona bug as much as it is a catch-22 within the file system.  Imagine you and I were on the phone and I pulled the plug on my end, but you kept hearing my voice.  You wouldn't know to hang up because I kept talking and didn't say goodbye.  Basically, the file server isn't hearing "goodbye" and doesn't release the lock.  The file server should release the lock when the Persona service process stops (even if Persona didn't close it explicitly), but that doesn't happen cleanly in a this kind of situation, so it doesn't get the "goodbye" message.  I am not sure if this a persistent bug in Windows, NTFS, etc of it's a design issue that Microsoft cannot work-around.

The profile will not work correctly again until the lock is cleaned up.  At this time, the only way I currently know to clean up the orphaned file locks is to reboot the file server.

So, yes, we can expect data loss to happen if the desktop is reset unexpectedly and the data hasn't been replicated yet in some cases.  Sounds like this may be what you are experiencing.  Profile corruption is a term often misused.  In your case, I think you are seeing data loss due to the outages, not profile corruption.  I would expect your roaming profile to be in a crash consistent state, but missing the last set of changes the user made.  Is that what you are seeing?

I hope this helps to answer your questions.  If not, please feel free to ask more.

Thanks,

Erik

0 Kudos
CameronUBC
Enthusiast
Enthusiast
‎01-22-2015 08:16 PM
Jump to solution

Thanks, that's a very helpful reply.

The data loss I'm talking about is more than just the previous 10 minutes though, it's much much more in some cases. This tells me that this must be a bug I'm experiencing with Persona and not just corruption that is happening as a result. I have a ticket that's open for all these persona synching problems I'm experiencing.

I'm fine with cleaning up the lock files if that's the expected result, I'm expecting there are some orphaned locks that aren't getting released and you can't delete the lock files because they're still locked. Here's a follow up question, what happens if you don't clear the lock file? Does the profile log in with a temporary file? Or does it log in read only and the rest of your changes are lost? I have some other guys doing support in our operations team that I want to train out in fixing these problems.

Thanks

Cameron

0 Kudos