Help
Hello,
We have been struggling with camera quality in our virtual environment. It seems that no matter what we do, quality of a webcam ends up very choppy and pixelated. After a fair amount of research, we came to the conclusion that it is best to run cameras on Thin Clients, as opposed to Zero Clients. Still, when logged into a virtual machine, there is no improvement to the quality of the picture when run on a Thin Client.
While most of our environment is running PCoIP, we have also tested with BLAST. RTAV is another avenue that we’ve explored. We are running nVidia Grid cards, and have plenty or resources to put toward video quality (graphic intensive programs such as AutoCAD, Photoshop and BlueBeam work just fine). What’s alarming to me is that, no matter what we test (RTAV, BLAST, Thin/Zero Client, PCoIP, etc…), there is absolutely no change, negative or positive, in camera quality.
I am also confused about the benefits of using a Thin Client. I was told early on that running a camera from a Thin Client allows the video to be processed locally before passing through to the VDI. My understanding is that a Thin Client is nothing more than a PC running the Horizon View Client (or Citrix, RDP, etc…), but did find recently that there are RTAV settings in the registry of our 10zig Thin Clients. I’m just wondering if there is something that needs to be done on the Client itself in order to utilize RTAV in the virtual environment.
My suspicion is that we HAVE the tools we need, but are missing some critical information on how to use them. I apologize for the lack of information/context… I’m not sure I know the VDI lingo well enough to communicate a question like this. I’m hoping that someone can offer some advice based on similar experiences. We NEED to give our users acceptable camera quality, and they do not want to take extra steps to leave their virtual machine to do so.
Currently running:
nVidia GRID (M and K series)
VMWare Agent version 7.4
Logitech 1080p cameras
10Zig 5800/5900 Thin and Zero Clients
Thanks!
Michael
I need to pull up a bunch of information for the VMs living in specific datacenters within a vCenter (5.1, ugh) environment right now. There are three datacenters with clusters within each (plus some hosts not in clusters, but still within the datacenter items). With about 4000 VMs total, I really need a solid way to pull the information from just one datacenter, or even from a single cluster/host within each set. The first target is the smallest, with only 18 hosts and 111 VMs listed in the summary of the DC.
I’ve found some scripts to pull the information (or a good chunk of it) but I really need it to be more specific (instead of shotgunning to everything).
Information I really need to pull:
VM name (obviously)
vNIC with portgroup connected to, plus how many of them (if more than one at least) along with the adapter type selected (e1000, etc.)
VMDK information including how many and which datastore it’s on as well as what the type of datastore it is (VMFS, NAS, etc.).
Snapshot if present (I’d also prefer to have the total snapshot size if easy, but I can always gather that later).
Affinity rule(s) applied against the VM(s). If this can include which rule is applied, that would be great.
IMO, easy stuff to add would be the OS inside the VM, IP address, and power state. I’d also like to have the location information for the VM. Such as which datacenter, cluster and host. Or at least have that available and either enabled or disabled easily (add/remove # in front of the lines).
I’ve been asked to get all of this for the first target before end of the week. I’d like to have it sometime before EOD tomorrow. One of the scripts I found earlier today is still runnning.
Get-VM | Select-Object Name, Powerstate, NumCPU, MemoryGB, @{N=”Noofdisk”; E={($_ | Get-HardDisk).count}}, HardDisks, @{N=”Datastore”; E={($_ | Get-Datastore).Name}}, @{N=”DiskState”; E={($_ | Get-HardDisk).storageformat}}, ProvisionedSpaceGB, @{N=”Snapshot”; E={($_ | Get-snapshot).count}}, VMHost, @{N=”OS”; E={$_.ExtensionData.summary.config.guestfullname}} | Export-Csv -NoTypeInformation -UseCulture -Path “C:powercli_reportsInventory4Result.csv$(Get-Date -f MM-dd-yyyy-H-mm-ss).csv”
The above script just finished and pulled up all the info listed in it (good sign). Can I simply add “NetworkAdapter,” to the list to get the adapter type for each VM?? I’d still like to narrow down the target to just the DC/cluster I need to focus on (at each run time). Even if it means altering the script to be target specific. I’m also going to still need the rest of the info I listed above added to this. With each run taking over an hour (around 1-1/4 to 1-1/2 hours) it would be better. Especially when I can target a smaller group and get the results faster.
Hopefully someone will answer up soon (like LucD).
update: added the “Get-Datacenter =”<datacenter>” | ” at the start to narrow it down. I can change it to a cluster later when I start hitting the one with over 3000 VMs in it (so it takes less time).
Still trying to figure out how to get the Network Adapter Type added to the list. I’ve tried added “@{N=”NetworkAdapter”; E={($_ | Get-NetworkAdapter)}}” but it’s not giving me the desired result…
Update2: changed the NIC line to “@{N=”NetworkAdapter”; E={($_ | Get-NetworkAdapter).type}}” and that pulls the info needed for that section… Need to figure out how to add a NIC count line to this too (hope what I’m thinking will work, but will see).
Update3: I’ve managed to get almost everything needed. Except for a way to get the DRS affinity rule for any VMs they are applied against. Since this is going against a DC, is that just not possible? I’ll consider pushing the script against a cluster tomorrow.
Message was edited by: golddiggie
Hy everyone.
Hope I’m in the right place to be asking this question, if not, please be kind enough to redirect me.
So, in a setup where we have a USB device connected to the Internal USB port of a Dell Poweredge R430 server and want to deliver it to an ESXi 6.5 Guest Debian VM (we know this is not best practices but please try to disregard the reasons, it’s where we’re at), we’re having an issue where in some situations, if the device is disassociated from a VM and we reboot the server we then start getting “USB Enumeration failed” errors or other USB related errors if we attempt to add the USB device to a VM, this happens until we are completely unable to find the device as available to be added to the VM, like greyed out in the interface. For what we gather to be able to find the device again we have to remove it physically, inserting it again and boot the server.
Really weird situation. Anyone has any ideas? We’re out. We tried with USB Passthrough options, disabled vmkusb drivers and we could not find much else to try.
Thanks.
Hi All,
Currently playing in my DEV environment.
Which is running AppVolumes 2.14
My Production is running AppVolumes 2.13.2 but I seem to have over 5000 machines even tho I only have 300 online working.
So doing a test in DEV before we deploy to production.
Currently I have 24 machines running online so to make sure the Database is fine I created multiple desktop pools to get the numbers up I currently have 85 machines.
So I have deleted my test pools and should be back to only 24 machines again but each time the system Syncs with AD its syncing 85 machine even tho we only have 24 ??
Now my Home page on Appvolumes shows Computer Utilization 85 machines which I’m expecting that number to come down to 24 again.
Am I doing something wrong here I thought Appvolumes 2.13.3 had this issue sorted or at least now 2.14.
Thanks in advanced
Hello,
My server is an HP DL360 G7 with VMWare 5.5.0,1746974
I have recently updated some switches on my network and now 2 of 5 VM’s on the same host.
I made no changes on the host so I am not sure why/what happened.
Anyone seen this before?
Thanx,
Bruce
Team,
Any idea why “Add USB Device” would be grayed out in the VM’s configuration within the ESXi Embedded Host Client? I’ve tried multiple operating systems, USB 3.0 and USB 2.0 controllers, etc. but for some reason my WD Pa$$port USB HD device never shows up in the client. I’ve also tried other basic USB devices. Are there any troubleshooting steps I can take to see where the issue is?
Thanks,
Brad
Hi All,
With the recent release of vSphere 6.7 many of us who built home lab environments just hit a dead end on the upgrades due to CPU incompatibilities. Taking the fact that some of us have built quite extensive versions of the labs with rather expensive equipment, it makes a situation even more difficult, since if we would like to upgrade all the back-end equipment then this would require tremendous financial support which we usually can’t get out of nowhere. So I was thinking about some potential workarounds with hopes that some of you may pop into this discussion and provide additional ideas.
In my lab I have various types of machines some of which are fully supported at this time for running ESXi 6.7 but the question of “until when ?” is always out there. So far I managed to run most of my hardware up till ESXi 6.5 without any issues regardless of the warning message that my CPU’s are falling into the scope of unsupported stuff, but oh well we never care about such warnings when it comes to home labs right ?
Anyway so my stuff is organized as follow. I have one ESXi Cluster based on Xeon E5-2620 CPU’s which runs absolutely fine with ESXi 6.7, however I have another ESXi Cluster based on older Intel Core i7-950 CPU’s and I’m using it for testing some vCloud Director related VCD features. Unfortunately this second cluster definitely doesn’t fall into the scope of upgrading it to ESXi 6.7 and for my worst luck it just refused to boot up when I tried to enforce it to v6.7 via the offline-depot upgrading method. The machines were always getting back to the black screen stating that my CPU type is unsupported.
Personally I’m not very happy with VMware’s decision on completely dropping out the older CPU’s because this seriously limits the options for home labs and frankly I don’t even think we usually test the most complex features requiring the additional hardware support. Of course I agree to some extend with the decision to limit support for extremely old machines and especially when it comes to production environment, but on the contrary I have another very old ESXi cluster based on Intel Core 2 Quad Q9550 CPU’s which still totally works with ESXi 6.5 and I’m using it occasionally for testing out vCloud Edge related services. So I found it kinda unnecessary that VMware went too drastic on this decision instead of letting the home-lab users to test out on their own equipment what may or may not work. Anyway…
So in my case upgrading the hardware from scratch on at least two cluster of 3 machines to new generation is totally going to drain my finances and therefore I started to look for some workarounds to this. My main idea here was to try the nested-virtualization method by installing ESXi 6.7 on the top of ESXi 6.5 layer and enforce the VM via CPUID modifications to actually think that it does have a supported CPU class underneath. I took the approach by making a test VM on one of my Intel Core i7-950 CPU based machines (still running ESXi 6.5). When I boot the VM and try to install ESXi 6.7 the obvious result was this one:
At this point I decided to play around a bit with the EAX registers and implement a mask that would enforce ESXi 6.7 to think the VM has a different CPU model and stepping. Since my knowledge on CPUID implementation is somewhat limited I just decided to take the EAX register from one of my Intel E5-2620 based hosts instead:
Once I applied the mask, I was able to install ESXi 6.7 without any issues. I didn’t even have to rebrand the CPU via the 0x80000002 registers in order to be able to install the new OS, so it seems that ESXi 6.7 is primarily looking at the CPU Family ID, model and stepping for the initial CPU identification procedure.
While this method is not ideal at all (in fact it’s a very ugly workaround) at least it provided the option to install the new OS and therefore to put hands on the basic functionality. Not sure if this method is suitable for nested virtualization, but if I get some time I’ll definitely test it out. I suppose the EAX registers could be tweaked a bit better in order to be able to support certain set of features, so if anyone has a good idea on how to craft a better CPUID EAX registers purely for lab uses with as much compatibility on features as possible, feel free to put your magic in this thread.
Any other workarounds on running ESXi 6.7 on unsupported CPU’s are also very much welcomed.
