Joining VMware and the [email protected] Project – FAQ

Since my first post about joining the VMware Team in the [email protected] ([email protected]) project, a lot has happened, we have created an easily to deploy and use OVA via our Flings website, which once deployed, will connect to the [email protected] project and start contributing straight away.

I’ve been humbled to be part of this internal VMware project and provide some of the documentation for the Fling..

In this post I will cover a FAQ of the typical questions we have come across. A FAQ can also be found on the fling web page.

VMware Appliance for Folding FAQ

1. Where can I learn more about the [email protected] project?

I recommend you check out the [email protected] website

2. If I have no VMware software, can I still contribute?

Yes, the OVA Fling is designed for deployment on VMware Workstation, Fusion and vSphere products.

However you can simply run the [email protected] client locally on your workstation, laptop or home micro server. VMware Software is not needed!

3. I seem to be receiving no workloads, is my OVA working?

If you can see logs stating the below, this means there are no available work units for your appliance configuration. We recommend leaving your appliance running, and it will continue to search for available work units.

16:24:39:WU00:FS00:Connecting to 65.254.110.245:8080

16:24:40:WARNING:WU00:FS00:Failed to get assignment from '65.254.110.245:8080': No WUs available for this configuration

4. My appliance seems to not be working, and I see “vghetto-photonos login:” when I open the console for my appliance.

You need to deploy the appliance with the OS Root Password configuration, this is a mandatory parameter, as there is no default root password for PhotonOS builds.

5. Why cannot I not select to just work on COVID-19 projects?

This is not an option that’s available from the [email protected] team, however any work units for COVID-19 will be prioritised. These are the Covid-19 projects:

  • CPU : 14328 – 14329 – 14530 – 14531
  • GPU : 11741 to 11764

6. How many CPUs should I configure my OVA with?

This depends on your available resources, by default the appliance will deploy with 2 CPUs.

7. Are there any other optimizations I can make with my configuration?

You can consult the previous link for advanced client settings. We also recommend authenticating your work by using a PassKey, please see this link; https://foldingathome.org/support/faq/points/passkey/.

8. Can I deploy the OVA on a ESXi host?

Yes, however you will need to use the OVFTool, the Host Client UI is not supported. You can find sample scripts here; https://github.com/lamw/vmware-fah-automation

9. Can I deploy multiple OVAs at once?

Yes, please consult this script: https://github.com/bzaks1424/deploy_folding_at_home_vm

10. Can I deploy the OVA on Fusion or Workstation?

Yes, you can deploy our latest OVA (ver. 1.0.1 and higher) to both VMware Fusion and VMware Workstation.

11. What are my options for monitoring the appliance?

There are three options;

  • Within the VM console itself, you can choose between the PhotonOS shell (ALT + F1) and Top screen (ALT + F2).
  • Connecting the web client – https://OVA_IP:7396
  • Using FAHControl to connect to multiple clients. This is installed by default with the [email protected] client on Windows and Mac OS X and there is a separate installer for Linux machines.

12. Is there something cooler, like monitoring in vROPs?

You can monitor the VMware Team’s performance using this vROPs dashboard; https://github.com/johnddias/vROps-Folding-at-Home

13. What ports and IP addresses do I need to open on my firewall?

  • External (Internet)
    • Inbound/Outbound on port 8080 or 80 to receive and upload Workload Unit (Please see Folding @ Home Documentation for a complete list of servers for security whitelisting)
  • Internal
    • Inbound/Outbound on port 36330 for remote management of FAHClient using FAHControl Center
    • Inbound/Outbound on port 7396 for local web management of FAHClient using FAH Web Control(e.g. http://[FAH]:7396)

14. Can I change the configuration of my [email protected] client after it is deployed?

Yes, you edit the settings using either FAHControl, or by connecting to the appliance and editing “/etc/fahclient/config.xml”. You can find more information at this link: https://foldingathome.org/support/faq/installation-guides/configuration-guide/.

15. Can I use a GPU with my appliance?

Yes, please see the supplementary documentation on the Fling website. Please also review the [email protected] requirements; https://foldingathome.org/support/faq/installation-guides/linux/requirements/.

16. if your GPU isn’t detected on your windows box

This fix has worked for other;

  • Windows Updates often breaks OpenCL support when it updates the drivers automatically. To fix it, reinstall the drivers you downloaded from nVidia or AMD website.

16. Where can I check the VMware Team stats and my user stats?

Official [email protected] Searchable Stats page – Team VMware

Official [email protected] – Fast stats – Team VMware

We have found that sometimes the official [email protected] stats page gives the error “Bad gateway”, so we recommend the Extreme Overclockers Forum link below.

Our WaveFront team have created a public facing dashboard as well!

17. I see in the logs, “Exception: Failed reading core package header”

Check your firewall/proxy settings for web filtering/download file inspection. It may be needed to exclude your appliance from this feature.

Note: I have personally seen this as an issue with the Sophos UTM used for home setups.

Regards

Using FAHControl to monitor multiple [email protected] Clients

This blog post will cover how to centrally manage multiple [email protected] clients.

  • Installing FAHControl
  • Monitor Multiple instances of VMware Appliance for [email protected]
  • Configuring Access to your Linux based clients or directly on the VMware [email protected] Appliance
  • Connecting FAHControl to your clients
  • Troubleshooting FAHControl issues
  • Firewall Rules

Installing FAHControl to monitor multiple installations

For Windows instances, this is installed as part of the FAHClient

  • “C:\Program Files (x86)\FAHClient\FAHControl.exe”

For Linux, you will need to install FAHControl separately

Monitoring multiple instances of the VMware Appliance for [email protected]

When you deploy you’re OVA you’ll be asked to configure the below highlighted settings, by default we input a rule of 0.0.0.0/0 meaning any FAHControl node can connect (using the correct password). You can alter this for your local subnets.

Configuring Access to your Linux based clients or directly on the VMware [email protected] Appliance

On your Linux machines or deployed OVAs

  • Connect via SSH
  • Edit the config.xml file
vi /etc/fahclient/config.xml
  • Insert the following code to enable FAHControl access
    • From within vi press ‘i’ to enter insert mode
  • To configure a single address to access your client
    • Without passwords;
<command-allow-no-pass v='127.0.0.1 x.x.x.x’ />
  • With Password;
<command-allow v='127.0.0.1 192.168.200.10' />

<password v='VMware1!' />

N.B. The localhost address must remain configured, otherwise the client work run

  • Save the config.xml file
  • Press ESC key
  • Enter without quotes “:wq!”

  • Reload the FAHClient
    • /etc/init.d/FAHClient restart

If you see “Starting fahclient … FAIL” check your XML file again for any syntax errors.

Examples Config.xml changes

Using password with a single IP restriction

  <!-- Remote Command Server -->

  <command-allow v='127.0.0.1 192.168.200.10' />

  <password v='VMware1!'/>

Without a password against a single IP restriction

  <!-- Remote Command Server -->

  <command-allow-no-pass v='127.0.0.1 192.168.200.10' />

Without either a password or IP restriction

<!-- Remote Command Server -->

  <command-allow-no-pass v='127.0.0.1 0.0.0.0/0' />

Connecting FAHControl to your clients

  • Open your FAHControl and click Add
  • Enter the name of your client as you would like it to be displayed, the IP address of your client and your password if necessary, and click save
  • You should now see your client is connected in FAHControl.

Troubleshooting FAHControl issues

FAHControl uses the default TCP Port 36330

Test access with telnet you should get a response as below.

The VMware Appliance for [email protected] has IPTables configured to allow this port by default, if you did not specify a specific remote management address during deployment, then access is open to all IP addresses.

Ensure that the machine where you are running FAHControl is not blocking outbound connections to TCP 33630.

Appendix

Firewall rules

The below firewall rules have been added to the VMware Appliance for [email protected]  by default to allow for FAHControl to remotely manage FAHClient.

If you are using these instructions for a Linux machine, you can use the below settings as well.

iptables -A INPUT -p tcp --dport 36330 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 36330 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

 

Regards

Migrating User and Password Objects between Active Directory Forests

As part of some internal lab work, I had to move the user objects with their passwords to a new forest. It was key to migrate the passwords to ensure that disruption to the users was minimized.

To migrate the users, I used the Microsoft Active Direction Migration Tool (ADMT + documentation) alongside the Password Migration Service.

In this blog post I am going to cover;

  • Create connectivity between both AD Forests
  • Installing the ADMT software + Password Migration Service
  • Creating a user list for migration
  • Migrating User objects + Passwords between AD Forests

Create connectivity between both AD Forests

There must be IP network connectivity between the DC’s in your Forests.

DNS setup

You need to configure conditional forwarders between your forests, so they can resolve one another.

On the source domain controller;

  1. Open up the DNS console, and right click the Conditional Forwarder folder to create a new record.
  2. Enter your target domain name and IP address/es of your domain controllers in the target domain. Select “store this conditional forwarder in active directory”, to replicate to other DCs in the source domain.

It is also a good idea to add the target domain DNS suffix to your Source DC network adapter, this allows for short name resolution.

Repeat the same steps on the target domain controllers, pointing the conditional forwarder to your source domain.

After this, ensure you can successfully look up the domains from another with the correct Domain controller IP addresses being returned. Also check short name resolution works.

Create Active Directory Forest Two-Way Trust

Next you need to create a forest trust

  • You can read about the different options here

I will create a two-way forest trust which means we are able to authenticate users between domains, and this trust will be removed after I’ve migrated the users.

On the source domain controller

  1. Open Active Directory Domains and Trusts. right click your domain name and go to properties
  2. Click the trusts tab, and click the new trust button
  3. Enter the name of your target domain
  4. Select forest trust
  5. Select two-way trust
  6. Select forest wide trust
  7. Enter trust password (you will use this when you create the trust on the target domain side)
  8. Click next x2
  9. If you click to confirm the trust at this point, it will fail as it does not exist on the target domain side yet. (See screenshots)

Installing the ADMT software

Install this on your Target domain controller, or a machine in target domain. There is a requirement for an SQL server to host a database. I used SQL Express for the lab setup.

Installing the Password Migration Service

First you must generate an encryption key from a DC in your target domain. Open CMD as administrator and run;

admt /key option:create /sourcedomain:{source domain name} /keyfile:{folder path to save the file} /Keypassword:*

Using * for the pwd flag, will then prompt you for the password when the command is run

On your source domain, in the built-in Administrators group, add in the domain administrator from your target domain.

On the domain controller in your source domain, install the Password Migration Service.

When prompted, install the service as the domain admin from your target domain, this account will be added the log on as service right.

A reboot of the machine where this service is installed will be needed.

After the reboot, you will need to manually start the “Password Export Server Service”, after you’ve migrated your users, for security, you should stop this service.

Creating a user list for migration

The last step before migration, is creating a CSV file with a list of the users we want to migrate. I will do this using a simple PowerShell command

get-aduser –filter * -searchbase {OU full path} | Export-csv {path}

You can be more complex if you need to target users who are part of a security group or multiple OUs.

You will need to edit this CSV to use the accepted headers for use as an “include file” for ADMT. You can follow the official documentation for these headers.

Migrating users between AD Forests

Ok, we’ve finished the prep work. Now time to migrate the users.

  1. Open up ADMT console, right click on the Migration tool folder and select “User Account Migration Wizard”
  2. Type in your source domain, and select your target domain from the drop down
  3. Select the option “read objects from include file”
  4. Set your include file location and Source OU where your users are located
  5. Select the option to migrate the user’s passwords
  6. Select account options for after the migration
    1. If selected SID History Migration, accept the options
  7. Input the domain admin detail to authenticate to the Source Domain
  8. Configure user options for after the migration
  9. Select any user object attributes you do not want to be migrated
  10. Select your option for how to handle user conflicts
  11. Complete the user migration wizard
  12. Watch the progress, you also have easy access to view the logs from here
  13. Configure user’s password so that they do not need changing upon next login.
get-aduser -filter * -searchbase {OU path} | set-aduser -changepasswordatlogon $false

            

Hope this helps someone out there, I recommend that you read the ADMT document first before undertaking a migration of AD users in production, and then test in a lab environment.

Powershell snippet – text to secure string and output to XML file

Below is a quick Powershell command I use to convert passwords to secure strings and output to an XML file, I can encrypt that XML file locally on the machine where any scripts need to run from, and call it in another Powershell script.

$secpasswd = ConvertTo-SecureString "VMware1!" -AsPlainText -Force

#The logic used here between the brackets is Username,Password, where we call our previous variable

$mycreds = New-Object System.Management.Automation.PSCredential ("administrator", $secpasswd) 

$mycreds | export-clixml -path c:\temp\password.xml

It’s quick and easy to use, there will be other ways that may work better for you, if so, drop them in the comments.

vRSLCM – vRA fails to update from 8.0 to 8.0.1 – LCMVRAVACONFIG90030

When updating my vRealize Automation instance from 8.0 to 8.0.1, I ran into an issue;

LCMVRAVACONFIG90030

Error Code: LCMVRAVACONFIG90030

vRA VA Upgrade Status Check failed.

Upgrade prepare on vRA VA sc-dc1-vra001.simon.local failed with state error. To know more about the failure, run command "vracli upgrade status --details" on the vRA VA sc-dc1-vra001.simon.local. If the prepare upgrade issue is fixed outside vRSLCM, the vRSLCM request can be proceeded to next step by clicking RETRY with proceedNext property set to true. Optionally, the whole upgrade can be cancelled and started afresh by clicking RETRY with cancelAndStartAfresh property set to true. If both the retry properties are set to true,cancelAndStartAfresh property will take precedence and will be honoured

I logged into my vRA node, and ran the recommended command “vracli upgrade status –details”. This basically told me no running application servers were running. Which was odd, as my vRA installation was working.

So I ran “vracli status” and immediately seen that I had some issue with my database in the vRA node. I’m unsure if this was a pre-upgrade issue, or happening during the upgrade.

[ERROR] Exception while getting DB nodes.
...
Error getting database node status

I decided to run “deploy.sh” which re-runs all the Kubernetes configuration, thus killing and restarting all the services. This seemed to resolve my issue, as running the upgrade again worked as expected.

If you encounter this situation, I would recommend you contact VMware Support for guidance, and information as to why your services have stopped. As this is in my lab environment, I do not have the same considerations as those that run production.