I kept running into the error whilst running PowerCLI on Ubuntu. After wracking my brains, I realised that the issue is DNS, my Ubuntu box couldn’t resolve the FQDN for the ESXi host, which is a mandatory parameter for the Import-vApp command.
Import-VApp Name or service not known
Dean
When vSphere 7.0 (and therefore vCenter 7.0) went GA, a number of customers were hit with a very important change;
Since the GA, after customer feedback, the vCenter 7.0 release notes have been updated and I’m happy to report that Image based backups are still supported.
However, note that this method is now deprecated and will not be supported in a future release.
My advice is to start planning your move to using the native backup capabilities within the vCenter appliance itself, and for further information please see the following resources;
Regards
My customer asked me how to display the VLAN ID for a virtual machine in vROPs.
The short answer is, due to the VLAN ID only being available from the Distributed switch adapter, its not simple to display this in a single list view.
So after some thinking around this, I came up with the following simple dashboard which was edited from the default “Distributed Switch Configuration” dashboard.
The dashboard is simple, and shows a selectable list of port groups, which then will refresh the virtual machine list, so you can see which virtual machines are attached to that port group.
You can download the dashboard and edited view here:
Regards
I presented on the first ever virtual London VMUG event of which you can see the recording below, and it is accompanied by this blog post;
You can find the full YouTube playlist for the event here.
Regards
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.