Jeremy Stroebel - All Things Tech in SMB

Had an odd scenario today where a VM with vGPU enabled on XenServer became unresponsive and would not restart/shutdown, force shutdown/reset, or really do anything.  So I had to reference a handful of Citrix articles to remember how to force it, but then came to another issue that it didn't kill the GPU portion...  So here we go! First we have to kill the VM on XenServer: ( https://support.citrix.com/article/CTX220777  &  https://support.citrix.com/article/CTX215974 ) Disable High Availability (HA) so you don’t run into issues Log into the Xenserver host that is running your VM with issues via ssh or console via XenCenter Run the following command to list VMs and their UUIDs xe vm-list resident-on=<uuid_of_host> First you can try just the normal shutdown command with force xe vm-shutdown uuid=<UUID from step 3> force=true If that just hangs, use CONTROL+C to kill it off and try to reset the power state.  The force is required on this command xe vm-reset-powe

This post is pretty short and simple, but I thought it merited a separate post for this issue. Problem: When layering multiple Autodesk Products in separate layers, you will likely run into errors pertaining to licensing (you will theoretically get a pop-up indicating an issue for all but 1 program).  This is due to Autodesk keeping 1 file that holds the licensed product information for all Autodesk programs installed on a machine.  If this file is incomplete, you will run into this error.  The way most layering works is the last layer to lay down will win in any conflicted files.  (Note: Liquidware's ProfileUnity/FlexApp does do some microisolation in newer releases.  Previously this was an issue there as well, but I have not tested recently to see if this problem is solved with their microisolation technology) The file affected is typically "C:\ProgramData\Autodesk\AdLM\ProductInformation.pit".  The file can have more products in it than you have installed, but can

Yesterday at Autodesk University 2018, I attended a session (SD227281) that was supposed to be about "Best Practices for Virtualizing Your Autodesk Software."  What ended up happening was some sort of confusing and illogical announcement about new Terms and Conditions around what is allowed and what is not allowed in terms of licensing models for virtualized environments.  To categorize this session as devolving into an infuriating train wreck would be an accurate description. After cooling down and doing some research yesterday I am even more confused, and some of what we heard was seemingly wrong. First I'll summarize what was "announced" and what was discussed in that session by the two senior Autodesk people (John Looper and Chris Kayser). Announced in the presentation: Autodesk will permit virtualization for: - Subscriptions with single-user access - Enterprise Business Agreements - Server-based components (Think Autodesk Licensing Server

Coming from K2 based servers, we did  not have the GPU monitoring capabilities or NVENC in our existing VDI servers.  That being said, the new monitoring features available on Maxwell and Pascal series GPUs have exposed some interesting sizing considerations when using NVENC. As we've been putting the new Tesla P4 based servers into production, we've noticed much higher GPU usage at idle than expected.  Initially, to compensate, we've increased the framebuffer profile from "P4-1Q" to "P4-2Q" and see if that solved the performance issues and high framebuffer usage.  Indeed it did, so I went searching for why! Turns out (and this make total sense) that the encode process is using additional video RAM over what it was using without NVENC.  Using RDanalyzer I looked at the encoder memory usage for Single, Dual, and Quad monitor systems using both CPU and GPU encode.  See the table below: Takeaways: The NVENC vRAM/FB usage increase is approximat

We have had issues on our two R740s with clocks becoming out of sync even with NTP servers setup.  Our first assumption was that we had set something up wrong... These were good references to rule that out and show we had an actual issue: NTP Sync: https://support.citrix.com/article/CTX226572 Tips by Tobias: https://discussions.citrix.com/topic/381709-xenserver-70-and-ntp/ Restarting the NTP client synced the time, but within a few days the times would both be wrong (slow) by dozens of minutes and sometimes even up to an hour or more.  Both hosts would also be significantly different.  While one would be off by 45 minutes the other might be off by an hour and 15 minutes.  This was obviously something more and needed to be escalated to support. Here is what came from the support call: The agent changed the current clock source from tsc to xen by running the following at the console. echo "xen" > /sys/devices/system/clocksource/clocksource0/current_clocksource

My previous post ( https://allthingstechsmb.blogspot.com/2017/11/dell-r740-issues-with-xenserver-7172.html ) indicated I was setting up 2 new R740s for our upgraded CAD/Revit VDI deployment.  We've had a few issues/learning experiences.  This is an extension of that posts with things I've found out since and new issues that have come up.  In addition, XenServer 7.3 solved one of our issues. Storage Controller - H740p This is a continuation of the issue with the H740p driver from the previous post.  This issue was resolved in XenServer 7.3, with the supported driver being included in the 7.3 install media. Crash Dumps when booting in UEFI mode While they have worked perfectly, I have been seeing crash dumps reported in XenCenter on every reboot when XenServer is installed in UEFI mode.  If you boot with BIOS and install, there are no Crash Dumps. Per Rody Kossen (@R_Kossen), This will be fixed in XenServer 7.4, which is unofficially set to be released later this mont