User data option ignoring setting

[tbuckholz]

For some reason, when I create a persistent pool based on linked clones, the choice of where to put user data is being ignored. We are using Appsense and manually redirected folders, so I selected to store user data with the VM instead of on a separate drive. I confirmed I had the choice I wanted in the summary at the end of the deployment wizard. When it got done deploying, I looked at the VM and it still had a user data disk !http://communities.vmware.com/images/emoticons/angry.gif!. We're having profile issues, and I think its because the Appsense and vmware redirection is clashing.

At first I thought I had made a mistake and over looked the menu choice, but I can make it happen consitently. Normally I would think its a bug, except this is basic functionality of the deployment and you'd think QA would catch it.

This worked correctly in View 3.1. Thoughts?

[Linjo]

How big is the disk that you are seeing?

Is it associated to a driveletter?

What is on the disk?

Best regards,

Linjo

If you find this information useful, please award points for "correct" or "helpful".

[kjohnston]

Possibly what you are seeing is the 10MB Internal disk that is added to all linked clones in 4.0. This disk is used to store information needed for QuickPrep and not user data. It should not be mounted from within the guest OS after QuickPrep completes.

[jdaconsulting]

Are you running vCenter on a 64-bit OS with Composer on top of it? We experienced the same phenomena. I must have created a pool half a dozen times thinking I had selected the wrong setting. Re-installing the test environment with Composer running on top of vCenter using a 32-bit OS corrected the issue. If I read the documentation correctly, we should not have used Composer with vCenter on a 64-bit OS in the first place as Composer is only supported on 32-bit.

[tbuckholz]

vCenter is on 32 bit Server 2003 Standard.

The data drive is a 2GB drive being mounted to D:, which doesn't exist on the template.

The 😧 drive itself has a few profile folders on it, so I'm pretty sure the View profile management is doing this. It's doing exactly what its supposed to if I told it to store data on a separate drive. Problem is, I didn't.

[tbuckholz]

FYI, I talked to VMware support about this and they were also stumped. I can make this repeatedly happen. Their thought is perhaps its some kind of odd compatibility issue.

My host ESX boxes were on 3.5, I'm going to upgrade the two I was using for VDI experiementation to v4 and see what happens. I was going to do this anyways (eventually) since v4 has a lot of enhancements.

[henketh]

I have the exact same problem, any news about this matter? Did the upgrade to vSphere 4 help?

[tbuckholz]

They wanted me to try upgrading my hosts to ESX 4. I've been having issues getting it to properly install, so until I fix that, I won't be able to validate a fix for the view issue.

[jdaconsulting]

The problem with that suggested resolution is that I produced the problem in a pure vSphere4/View 4 environment. See my post a few above. In a fresh ESX4/vCenter4 (x64 OS) the problem ocurred. I assumed (perhaps incorrectly) that the issue was due to a Composer incompatability with the x64 OS used for vCenter. Regardless, I found myself in an unsupported configuration so I wiped and rebuilt using x86 vCenter and the problem never resurfaced.

[tbuckholz]

In my case, vCenter and View are both on 32 bit 2003, so the 64 bit issue doesn't affect me.

While changing to ESX4 is not what I would call a great recommendation to fix a small problem (and may not solve the problem at that), it was something I already meant to do at some point because of the performance improvements that supposedly occur. This issue just kind of forced it to the front.

[MrBeatnik]

We have resolved the issue in our environment it seems (hope I'm not getting ahead of myself).

The problem was ESX 3.5.

Upgrading to vSphere U1 has resolved the issue - UDD is now working as expeced on persistent pools.

Very strange. I guess this was missed in QA when VMWare said 3.5 works with Vew 4.

We are happy now. I hope this post helps others who might have a similiar issue.

BTW - This also resolved an issue with post sync scripts (another post).

[henketh]

This problem will be solved in View 4.01, rumoured RTM in about a week. I have tried a prerelease and it solved the problem, and my other problem too (no Active Sessions visible in View Manager)

[MrBeatnik]

Good to know for others not upgrading to vSphere as yet.

RTM was meant to be today!! View usually comes in late though.

[tbuckholz]

I'm glad they are fixing it so I can still use 3.5 for now. I can't fully migrate to vSphere until I get some storage that can handle it (yay for vendor's not requalifying).

It is kind of disappointing to have what I would consider a basic feature of the UI that obviously wasnt tested very well or this would have been caught. Fixing everything you forgot with SP1 is a Microsoft habit I was glad VMware didnt copy for the most part. At least it's being fixed.

[oppdbill]

I am having the same issue. ESX servers have been upgraded to vSphere 4.0 and I am using View 4. Virtual Center is on a 32bit W2K3 server. I created a persistent pool using linked clones and store user data on OS disk. Summary shows all those choices, but when the pool is created it has a 😧 drive a of 2048mb. When I look at the actual pool VM, it has three drives. The third drive is a small 2mb drive.

[MrBeatnik]

You are still having the issue even after upgrading to EXS 4 U1?

You didn't mention but I presume you are using vSphere VC with Composer2 as well?

That's very strange as most of the posts, as far as I remember, relate to only ESX 3.5 with View 4 causing the problem.

I presume that your ESX servers have been modified to use vSphere correctly (I'm not really a server guy, someone else dealt with the config but I know that we couldn't just install vSphere without tweaking the hardware setup a little)...

Also, I think we did a full ESX 4 U1 rebuild rather than an upgrade (migrated VMs off before hand).

I wonder if the upgrade is leaving something behind. Have you created a new pool from an existing snapshot or a new one (replica)?

Bear in mind that vSphere will need new VMTools, but that shouldn't really affect this issue I would imagine.

In any case, I guess 4.01 might fix it for you. Please let us know if it does