VMware Horizon Community
eddilimp
Enthusiast
Enthusiast

VMware View 6.2 is just a catastrophe

Hi all,

I have several Problems with my VDI at 2 Locations. At the Moment we ware running Version 6.2.2.

The VD Pool is a linked clone pool with sysprep. After a recompose i have different Problems:

- over 50% of the Desktops stuck in customizing for hours. after that they are deleted. when i log on a stucked Desktop, Windows wants to restart. a Manual restart doesn't Change anything. it's still stucked.

- when i do a recompose of a single Desktop, the VM boots, but the NIC is not connected.

- when a recompose was successfull after some tries, it sometimes happens when a user wants to log on, that the local Administrator is logged on.

i think that were the main issues for the Moment. im really getting tired of this.

18 Replies
kermic
Expert
Expert

Any chance that you might be running out of ports in your portgroups / vSwitches or out of DHCP IP addresses in scope?

These really do sound like networking issues.

As for the "local administrator logged on", check if your customization specification has the "Automatically log on as administratod X times" option enabled. It must be turned off.

Hope this helps.

Reply
0 Kudos
eddilimp
Enthusiast
Enthusiast

There are 120 ports on the vSwitch, that is still far away from out number of VMs, Also in the DHCP are enough IP adresses free.

the logged on as Administrator Option is enabled. i thought that has to be enabled, so that the customization can take part.

then i also don't understand, why we have this issue also at another site?

what else i noticed: when a VD is booting up, it Needs a long time until i can ping the machine, although i already see the Windows Screen with "applying Computer Settings...."

Reply
0 Kudos
kermic
Expert
Expert

"Log in as administrator" in customization specification can and most likely will break things.

Now back to the other issues you described - when you provision or recompose the vDesktop, a new VM is created using the parent + snap / template specified, customization script injected and the VM started up. Unique values cleared (computername etc), then the VM should get an IP from DHCP and contact AD DC to join. Then reboot, comes up with new fresh IDs, agent starts up and notifies the Conneciton Server of process completion. If they get stucked in customization phase, then most likely there is something preventing them from joining the domain and doing a successful reboot after that.

I'd start with networking first and then move on with View / AD settings.

Can you check if the desktop gets a valid vSwitch port and IP address while customizing and if there is network connectivity to AD DC during that timeframe? Any firewalls / routers in between?

Another thought, most likely not your case, however I've seen this once with similar symptoms - any chance that somebody might have set a static / manual MAC address for your parent VM / Template? In that case all clones would come up with the same MAC address causing MAC conflict.

Another thing for sysprep - sometimes it is recommended (at least was with earlier releases) that you disjoin your parent VM from domain before turning it into a template / parent, if you are using sysprep. There were cases where sysprep would not appreciate rejoining the machine to the same AD domain where it is already.

And of course any customization and view agent logs from the faulty machines could potentially reveal the cause.

Hope this helps.

Reply
0 Kudos
cbaptiste
Hot Shot
Hot Shot

Reply
0 Kudos
eddilimp
Enthusiast
Enthusiast

The hotfix is already installed

Reply
0 Kudos
eddilimp
Enthusiast
Enthusiast

I just checked now a single VD which stucked in customization. The virtual Desktop has a vSwitch port, an ip adress and i can ping it. i also can ping the DC from the VM. so i think the Network site is ok.

the parent vm doesn't have a Manual mac adress.

until now i never disjoined the parent vm from ad. perhaps that i should try next time.

at which logs i should take a look exactly?

something more: at booting up, the NICs are not connected. after a while they are suddenly connected. sometimes the customization works then, or it stucks at this Point.

Reply
0 Kudos
kermic
Expert
Expert

Thanks for checking and clarifying things!

Initially disconnected NIC for a freshly cloned VM is absolutely OK and the expected behavior. After the VM is cloned with customization, once powered on for the first time it actually comes up with the identity of the original VM (template / parent). Sysprep is injected and called at that point to clear out the unique values. Since up to now the original values are still there, vCenter disconnects the NIC so that the fresh clone would not hook up with its original and / or siblings.

Have you manually run sysprep on your parent machine / template, before deploying a desktop pool out of it?

Reply
0 Kudos
eddilimp
Enthusiast
Enthusiast

yes, i had. same Problem when i run sysprep manually.

Reply
0 Kudos
kermic
Expert
Expert

You should not be running Sysprep manually on parent machine since you are using vCenter customizations.

During customization process vSphere injects or calls sysprep on the target machine. If the guest also does it, customization will fail most likely as there are 2 processes trying to do the same thing.

Reply
0 Kudos
eddilimp
Enthusiast
Enthusiast

I run the sysprep via the vCenter customization. So there is only one customization process.

Reply
0 Kudos
amatt12
Contributor
Contributor

We might be having a similar issue (as well as others) with the NIC being not connected. When you spin up a pool how many desktops have the vNIC "connected" box unchecked? We and others in the community have been seeing 5-10% of desktops being deployed or refreshed with the check box unchecked.

Reply
0 Kudos
srodenburg
Expert
Expert

Sorry i don't understand. WHY on earth are you running sysprep via vCenter Custm. with Linked Clones?

All you need to do, is create a master image to your liking, create a snapshot and use that as the source within the pool definition. Then tell the pool to either sysprep or quickprep (better) and you are done.

So yes, there is only one customization process but vCenter has nothing to do with it. It's all the Composer and it's Quickprep (way faster than Sysprep which is only needed in very rare occasions).

No vcenter stuff, no manual sysprep, none of that is needed !

As long as there are plenty of vSwitch ports free, DHCP addresses free and the KMS Server can auto-activate windows for you, you are good to go.

I've been doing what I do for years. It's quick, avoids a lot of unneeded work and is bulletproof.

Reply
0 Kudos
eddilimp
Enthusiast
Enthusiast

I run sysprep via vCenter on a test machine to check if the sysprep is working in general.

I know that quickprep is better, but not for our environment. When I use quickprep then our eset nod32 virus scanner only displays one VD in the console. So I have to run sysprep.

I dont run sysprep manual during the recompose.

Reply
0 Kudos
srodenburg
Expert
Expert

Many Virusscanners and "Management Agents" cause clones to show up as a single system in their respective admin consoles. Such products must be anonymized / de-personalized just before cloning. It's mostly about deleting some INI / config file or a registry key with the VM's "ID" etc.

I've seen many such cases and never needed to resort to sysprep. I have always been able to "anonymize" some way or another.

Reply
0 Kudos
fugrat1
Enthusiast
Enthusiast

Please see this link for how to prep a master image containing NOD32

Deploy ESET products on a "ghost" or master image that can be cloned to multiple computers—Base de c...

Reply
0 Kudos
HendersonD
Hot Shot
Hot Shot

I am having a similar issue to two other posters. When we recompose a pool, we are seeing several VMs coming up with the Network Adapter Connected checkbox unchecked. I have had a support case open with VMWare for over a month on this issue. The support engineer at VMWare has been great but we have still not gotten to the root cause of the issue. Between the two of use we have tried a lot of things to fix this problem. We started with firmware upgrades on storage, servers, switches, nics, and ESXi. I made all new master Win7 images from scratch. We have upgraded our dvSwitches to version 6 with ESXi fully patched. We have tried older version of VMWare tools. We checked all of our switches for any errors and none were found

I do not think this is a hardware issue. Not sure if the issue lies with VMWare tools, View agents, composer, or ESXi itself. All of our desktops are non-persistent so they are refreshed on logoff. This problem crops up on recompose as well refresh on logout. My largest pool of 320 desktops can have 6-10 VMs at the end of each day that are in this state where the nic is not connected. If we just edit settings on one of these VMs and check the Connect checkbox for the nic, the VM is ready to go.

EricNichols
Hot Shot
Hot Shot

The admin client can accomplish this with a scheduled task:

ESET Remote Administrator - Administration Guide

Reply
0 Kudos
RWalterCC
Enthusiast
Enthusiast

Hi,

anything new here? any KB or something? We are starting to get that issue, too.

regards

Robert

Reply
0 Kudos