https://worldofeuc.com logo
Join Slack
Powered by
Vmeate has been changing nic pci slot number. I w...
# citrix-provisioning
r
Vmeate has been changing nic pci slot number. I would check that
Vmware
n
Not sure where I would check this? And in the packaging VM for the Platform layer or the provisioned VDA?
r
The target vmware vmx file verses the vmx on s packaging machine
n
I just don't get why this would start now all of the sudden
r
Would be if vmware got upgraded
n
VMware has been running 8.0 U2 for a long time now
The S19 template we were using in the Connector actually had an E1000E NIC. I created a new template yesterday hoping that was it, but still broken. Worked fine for so long with the E1000E in that template for packaging VMs, lol
r
Ok probably not that then. Did you try removing new layers to test
n
Removed all app layers, same issue. Building a new Platform layer now based off an OS layer that I know works.
r
K
n
if you hear screaming outside, this test has failed
Well, this is promising - running my AppLayeringImagePrep script and it removed 41 ghost devices. Previously, it was only removing 1 (an Intel NIC that was not installed).
jfc, still broken.
r
Must be you 😁
The 41 ghost devices is very strange
n
What's driving me nuts is that the entire build is basically automated. Installing literally everything I normally would. Same installers, same scripts, same steps.
r
I would check the slot number to be sure. Also ive never packaged for pvs on an e 1000. That seems like an issue to me.
n
So check the slot number in the flat file of the provisioned VDA?
Just makes no sense that every other image I apply to this target device works fine
ethernet0.pciSlotNumber = "192"
So the packaging VMs are using 33. I edited the vmf on this one target device to go from 192 to 33, still has the issue.
r
I dont think you can it goes back
n
How do you fix that then?
I'm having Rich create his own S19 Platform layer to validate what I'm seeing
r
I think you need your match on the packaging side
So same version if vmware patches
n
Changed the template to the one with a VMXNET 3 NIC, added an OS layer version and upgraded to VMware tools 13.0.10, and am finalizing a new Platform layer using that same template. No ghost devices in this one. Cross your fingers and toes.
Same issue. I'm just lost here.
r
whats the slot on the packaging machine
n
Gone now, I didn't check once I changed the connector, but I assume 192
r
i woudlnt assume wiht this one
n
I mean, does it even matter?
r
yes you cant change any nic paranters when using pvs
n
But even if I change the flat file of the target device to match the slot that the packaging VM used, that did nothing
at the end of the day, nothing seems to have changed in our environment, yet new Platform layers are busted
r
you cant change the target vmware just changes it back on boot
n
So let's say the slot is different. What can I actually do here?
New template where the slot is the same in the ELM?
r
Badically need to move to the new slot on both sides
n
I'm not even seeing a value for the slot in the .vmtx files for the template
Secure Boot is enabled in the template for some reason, though I don't think that's the issue
Rich's Plat layer worked, so clearly I am the issue.
r
Ha guess I was right
is he using the same connector
n
i sure as fuck hope so
He did, yes
r
ok then that makes no sense
n
I'm going to meet with him later to discuss.
r
wonder if its eomthing in your script. Did he use your script
n
I'll find out after lunch
Looking through the logs of his build, the only thing I can see that he didn't do (that I did) was run my AppLayeringImagePrep script, which removes ghost devices.
r
are you using dism to remove things
i have seen that ve an issue in teh past
n
Nope
This is the meat of it. Nothing crazy at all, and I've been using this for over a decade now, I think.
r
is ghost a function
n
yeahIt'
It's basically JG Spier's layer prep script: https://jgspiers.com/citrix-app-layering-preparation-script/
r
yea i woudlnt use that
n
Just finished my layer where I did not run this and it's still the same issue, lol. I really have to just wait until I talk to Rich now.
r
we do the sme thing during finalize and that does cause issues sometimes
k
n
So Citrix removes ghost devices itself?
And when you say same thing, is there anything else I'm doing in that script that you prefer me not do?
r
i mean i dont knwo about hacking the registry for the aad stuff usually thats just a dsregcmd /leave
n
Honestly, I think you really just want me to remove the ghost device stuff
r
yes
that might not be it but i woudlnt do it
n
Definitely not it, I tested the image where I did not run it and it still bombed
Went through the process with Rich and we are doing everything the same. Built another this morning, same issue. I give up. S19 can die in a fire.
r
You need an exact match of the VM you are using. I dealt with the same sh*t…. Just copy and vm you are using on production and build the image from there.
j
I know it's been ages, but @Nick Panaccio this one popped up for us this month... anything end up working for you?
n
For our issue, our VDAs were built using a VMware template that used hardware compatibility v19 (ESX 7.0 U2), but our App Layering templates were all v21 (ESX 8.0 U2). Once I rebuilt the App Layering template based on HW compat v19 everything started working again. I found a Broadcom article stating that v20 and above changes the NIC to slot 33 because PCIe is now 192. I have no idea how this worked for us as long as it had, but something definitely triggered the failure. All good now, though.
j
Thanks for the follow up. Ours ended up being a XenServer bug + App Layering.
5 Views
Open in Slack
PreviousNext
Powered by