Episode 008 of the Unexplored Territory podcast is available! This week we spoke with Matt Coppinger about Virtual Reality and VMware Workspace ONE XR HUB, which is the enabler for VR adoption in the enterprise. Listen to it via Spotify (https://spoti.fi/3fSUrAM), Apple (https://apple.co/3FUOLkq), or anywhere else you get your podcast!
vr
Map head-mounted display to AMD ReLive VR instance
Warning before the post, I don’t have a good solution for you unfortunately at this time. One of the things I have been testing during my Take 3 is to have multiple head-mounted displays (VR goggles) on the same network connecting to multiple VMs. With ALVR this is pretty easy to do as the ALVR interface allows you to select the head-mounted display (HMD) you want to connect with as shown below. Very easy to use, and it allows you to always connect to the same head-mounted display as there’s an “auto-reconnect” option as well. (Which wasn’t always consistently reconnecting in my testing, unfortunately.)
I figured AMD would offer something similar, and it appears they do. After installing the AMD Radeon Pro software I couldn’t find the option that was described on Github. In the Radeon Pro software there’s no “devices” tab. Then I noticed that this is, unfortunately, only available for Adrenalin 2020, which is different then Radeon Pro software. So it seems that this functionality hasn’t been ported yet.
Can you get around it? Well, of course, you can have multiple VMs with ReLive VR instances running and have HMD’s connect to them, but this would be completely random. During normal behavior this wouldn’t be a problem, but when troubleshooting this would make life a lot more challenging. The way to get around it today would be to create different (wifi) networks and separate each pair (VM+ReLive VR instance and HMD) logically. This would work okay with a few head-mounted displays, but of course would not scale when you have more than a few. Let’s hope that AMD solves this problem soon. I reached out to AMD for a comment, they mentioned that you can use the Adenalin 2020 driver as well for the Pro cards, and that the feature for the Pro card is coming soon.
AMD Radeon settings window transparent in a VM?
I have been playing with VR technology for the past month. The last couple of weeks my focus has been to install/configure a VM which streams the VR app over wifi to a headset. I ran into a problem with ALVR last week as documented here, but I also ran into an issue with the AMD Radeon software when I wanted to use the AMD tools to stream a VR app. When you install the AMD Radeon software within a VM and want to configure the (passthrough) graphics card or ReLive VR the Radeon configuration window shows up transparent, it looks as below. Which means you can’t configure it, you can’t enable things like ReLive VR.
The only way to get the window to show up normal is to remove the VMware SVGA device using Device Manager. Simply completely remove it and restart the VM and the problem is solved. If you have svga.present set to false you will need to click “view hidden devices” in Device Manager first before you can remove the installed software/driver by the way. When rebooted it will look normal again and it will allow you to enable and configure ReLive VR, or any other options you need to configure of course.
Can I protect my vCenter Server with vSphere Replication?
Someone asked this question last week when I posted my “back to basics” vSphere Replication blog. I guess protecting vCenter Server isn’t too difficult but how about recovering it after a failure?
Those who have used vSphere Replication know that you need vCenter Server to click “Recover”. In a dual vCenter Server configuration that is not a problem. But what if you just want to protect your vCenter Server virtual machine and replicate it to a second piece of storage. I tested this and then “killed” my vCenter Server. How do I get my vCenter Server up and running again from this replica?
Let me start by saying that this is unsupported as far as I know. So lets start by checking the folder in which the replica of the vCenter Server resides:
8.5K Sep 21 09:46 hbrcfg.GID-d69c6cad-42a5-474a-86c4-c3158d1a3b42.6.nvram.18 3.4K Sep 21 09:46 hbrcfg.GID-d69c6cad-42a5-474a-86c4-c3158d1a3b42.6.vmx.16 267 Sep 21 09:46 hbrcfg.GID-d69c6cad-42a5-474a-86c4-c3158d1a3b42.6.vmxf.17 124.0K Sep 21 09:46 hbrdisk.RDID-9786ae39-cd3a-4773-be63-cd1bc3641d59.14.175750085646519-delta.vmdk 379 Sep 21 09:46 hbrdisk.RDID-9786ae39-cd3a-4773-be63-cd1bc3641d59.14.175750085646519.vmdk 52.0K Sep 21 09:46 hbrdisk.RDID-ae17cfad-c8d8-460c-99a1-8f26ff1133b9.13.43820857661344-delta.vmdk 375 Sep 21 09:46 hbrdisk.RDID-ae17cfad-c8d8-460c-99a1-8f26ff1133b9.13.43820857661344.vmdk 4.1K Sep 21 09:46 hbrgrp.GID-d69c6cad-42a5-474a-86c4-c3158d1a3b42.txt 25.0G Sep 21 09:46 vcenter-tm01-flat.vmdk 473 Sep 21 09:46 vcenter-tm01.vmdk 60.0G Sep 21 09:46 vcenter-tm01_1-flat.vmdk 476 Sep 21 09:46 vcenter-tm01_1.vmdk
As you can see the folder contains a lot of files we are familiar with… Especially the vmdk files and the vmx files is something we can work with. So how would we get this vcenter up and running. Lets look at the vmxf file first as that will reveal the original name of the vmx file:
<vmxPathName type="string">vcenter-tm01.vmx</vmxPathName></VM></Foundry>
Next I am going to copy the “.nvram”, “.vmx” and “.vmxf” file and give them the name “vcenter-tm01.nvram” etc.
cp hbrcfg.GID-d69c6cad-42a5-474a-86c4-c3158d1a3b42.6.vmxf.17 vcenter-t vcenter-tmp.vmxf
So now I have all the files I need with the right name… Next I will first “unregister” the original vCenter Server virtual machine… just to avoid any weird issues. I list all the virtual machines registered against this host first:
vim-cmd /vmsvc/getallvms
Now that I have the “vmid” I can unregister the original virtual machine:
vim-cmd /vmsvc/unregister <vmid>
Now that the original virtual machine is removed unregistered from the host, I should be able to register the “new” vCenter Server virtual machine… aka the replica.
vim-cmd /solo/register /vmfs/volumes/4f228789-84f6b84c-e17e-984be1047b16/vcenter-tm01/vcenter-tm01.vmx
Lets break that one down just to be clear:
vim-cmd /solo/register /path/to/vmxfile/filename.vmx
This command will return the “vmid” of the virtual machine we just registered. Now we can power it on…
vim-cmd /vmsvc/power.on
Now it sits there for a while, and when I log in with the vSphere Client and check the host it is running on I see this message that says “the virtual machine might have been moved or copied…”, I answer it by saying that is was copied and now the vCenter virtual machine boots up and I can login again. Yes there is an orphaned vCenter Server instance there, and you will need to clean that up… also there might be some obsolete files in the folder of this replica, and you might want to clean those up as well. Anyway, the vCenter Server virtual machine is up and running again, and that was the goal of this exercise right 🙂
Back to Basics: Install, configure and use vSphere Replication
One of the coolest features that has been included with vSphere 5.1 in my opinion is vSphere Replication. (Make sure to read the what’s new paper) The reason for it being is that it now brings “advanced” technology to everyone (Essentials Plus and upwards). I have used vSphere Replication in 5.0 and it was nice, but with 5.1 the installation and configuration process has been improved. For instance the database is now included in the appliance and it isn’t as DNS sensitive as it was with 5.0. This makes installing and configuring it a matter of minutes.
I am going to assume you have “vSphere Replication” traffic enabled on a VMkernel NIC, if you do not know how to create a VMkernel NIC check this article
Lets get started. I downloaded the vSphere Replication virtual appliance and imported and configured it in just a couple of steps using the vSphere 5.1 Web Client: [Read more…] about Back to Basics: Install, configure and use vSphere Replication