Monthly Archives: April 2019

VMware

WARNING: LRO: 977: cannot aggr pkt from port 0x5000002 as lro session port is 0x5000004

Leave a comment
This post was originally published on this site

We have started receiving the warning: “WARNING: LRO: 977: cannot aggr pkt from port 0x5000002 as lro session port is 0x5000004″.  The esx hosts are running 6.5 build 10884925.  I searched through VMware’s knowledge base, without success.  AS of yet I do not see any indications of a problem.  Any information around the error would greatly be appreciated.  We are using a nimble array with HP Proliant DL 380 G10, usiing

 

 

Thanks,

ShineKnox

Misc.

WARNING: LRO: 977: cannot aggr pkt from port 0x5000002 as lro session port is 0x5000004

Leave a comment

We have started receiving the warning: “WARNING: LRO: 977: cannot aggr pkt from port 0x5000002 as lro session port is 0x5000004″.  The esx hosts are running 6.5 build 10884925.  I searched through VMware’s knowledge base, without success.  AS of yet I do not see any indications of a problem.  Any information around the error would greatly be appreciated.  We are using a nimble array with HP Proliant DL 380 G10, usiing

 

 

Thanks,

ShineKnox

VMware

CPU Ready vs Co Stop vs Contention vs Steal

Leave a comment
This post was originally published on this site

We’re running several hundred VM’s on one of our clusters and have multiple business units managing servers at the OS level, running on these clusters. We have one business unit who runs their own monitoring software on their Windows Servers that is telling them the ‘CPU Steal’ is very high, and that it’s an issue with the hosts having CPU contention. We manage the underlying infrastructure, so I’m trying to match vSphere metrics up with what they are reporting for relevance.

 

I’m not familiar with CPU Steal, but typically I would review the CPU Ready values of a VM experiencing CPU performance issues. With CPU Ready value < 5% there’s nothing to worry about, general rule of thumb in my experience.

 

Looking at 1 particular VM (for example) with reported issues of high CPU Steal, CPU Ready is very low, 1.2% max peak however the CPU Co-Stop reached peaks of 250ms during these 1.2% ready peaks. If these 2 values indicate the same (or similar) information (VM vCPU is waiting to process on the hosts physical CPU) how can the values be so different?

 

Looking at the Max VM CPU Contention values from VROPS at the cluster level, it ranges from 4 to 16 – what is acceptable value for this metric?

VMware

Horizon View – GetDisplayProtocolPerformanceData Error

Leave a comment
This post was originally published on this site

Hi,

 

I’m getting the following error during Performance_GetDisplayProtocolPerformanceData method from Horizon API 7.6.0:

VMware.Hv.VimException: ExceptionType : VMware.Hv.UnexpectedFault

ErrorMessage : Failed to do helpdesk operation for session ****

CauseString : [HelpdeskOperation]com.vmware.vdi.sessionclientapi.OperationFailedException:  – failed to get protocol metrics

CauseStackTrace : System.String[]

ErrorCode :

ErrorAttributes :  —> System.ServiceModel.FaultException`1[ViewApi.RuntimeFault]: Failed to do helpdesk operation for session ***

 

 

Server stack trace:

   at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)

   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

 

 

Exception rethrown at [0]:

   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

   at ViewApi.viewApiPortType.Performance_GetDisplayProtocolPerformanceData(Performance_GetDisplayProtocolPerformanceDataRequest request)

   at VMware.Hv.Performance.Performance_GetDisplayProtocolPerformanceData(SessionId id)

   — End of inner exception stack trace —

   at VMware.Hv.Performance.Performance_GetDisplayProtocolPerformanceData(SessionId id)

 

Any ideas why it’s happening?

VMware

Failed to provision / publish a Windows desktop in Horizon Connection Server

Leave a comment
This post was originally published on this site

I followed every step on the following web page to create a Windows 10 Enterprise VM and snapshot using vCenter:

 

Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware

 

Then I tried to provision/publish a Windows 10 Enterprise desktop in VMware Horizon 7 Connection Server, but got the following error:

 

Error during provisioning: Initial publish failed: Fault type is UNKNOWN_FAULT_FATAL – Internal Template: vm-632 customization appears to not have succeeded. State = error

 

How to solve this problem?

VMware

Upgrade Esxi 6.7 U1 to Esxi 6.7 U2 Failed due to No space left on device

Leave a comment
This post was originally published on this site

Update command:

# esxcli software profile update -p ESXi-6.7.0-20190402001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

[OSError]

[Errno 28] No space left on device

Please refer to the log file for more details.

 

Swap config:

All swap is on, datastore use datastore1 and more than 100G space.

 

 

Please see the /var/log/esxupdata.log below:

2019-04-16T00:41:48Z esxupdate: 2099451: Ramdisk: INFO: Unmounting manual tardisk /tardisks.noauto/esxupdt-2099451^@
2019-04-16T00:41:48Z esxupdate: 2099451: Ramdisk: INFO: Unmounting manual tardisk /tardisks.noauto/weaselin-2099451^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR: Traceback (most recent call last):^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/usr/lib/vmware/esxcli-software", line 470, in <module>^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:     main()^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/usr/lib/vmware/esxcli-software", line 461, in main^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:     ret = CMDTABLE[command](options)^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/usr/lib/vmware/esxcli-software", line 213, in ProfileUpdateCmd^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:     nohwwarning=opts.nohwwarning)^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/build/mts/release/bora-10764712/bora/build/esx/release/vmvisor/esxupdate/lib64/python3.5/site-packages/vmware/esx
image/Transaction.py", line 375, in UpdateProfileFromDepot^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/tmp/esx-update-2099451/usr/lib/vmware/weasel/util/upgrade_precheck.py", line 2161, in cliUpgradeAction^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/tmp/esx-update-2099451/usr/lib/vmware/weasel/util/upgrade_precheck.py", line 997, in _parseVmwareVersion^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/build/mts/release/bora-10764712/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 514,
 in getoutput^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/build/mts/release/bora-10764712/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 495,
 in getstatusoutput^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/build/mts/release/bora-10764712/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 316,
 in check_output^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/build/mts/release/bora-10764712/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 383,
 in run^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/build/mts/release/bora-10764712/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 676,
 in __init__^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR:   File "/build/mts/release/bora-10764712/bora/build/esx/release/vmvisor/sys-boot/lib64/python3.5/subprocess.py", line 1228
, in _execute_child^@
2019-04-16T00:41:48Z esxupdate: 2099451: root: ERROR: OSError: [Errno 28] No space left on device

Security

Protecting Against Ransomware

Leave a comment
This post was originally published on this site

Original release date: April 11, 2019

What is ransomware?

Ransomware is a type of malware threat actors use to infect computers and encrypt computer files until a ransom is paid. (See Protecting Against Malicious Code for more information on malware.) After the initial infection, ransomware will attempt to spread to connected systems, including shared storage drives and other accessible computers.

If the threat actor’s ransom demands are not met (i.e., if the victim does not pay the ransom), the files or encrypted data will usually remain encrypted and unavailable to the victim. Even after a ransom has been paid to unlock encrypted files, threat actors will sometimes demand additional payments, delete a victim’s data, refuse to decrypt the data, or decline to provide a working decryption key to restore the victim’s access. The Federal Government does not support paying ransomware demands. (See the FBI’s ransomware article.)

How does ransomware work?

Ransomware identifies the drives on an infected system and begins to encrypt the files within each drive. Ransomware generally adds an extension to the encrypted files, such as .aaa, .micro, .encrypted, .ttt, .xyz, .zzz, .locky, .crypt, .cryptolocker, .vault, or .petya, to show that the files have been encrypted—the file extension used is unique to the ransomware type.

Once the ransomware has completed file encryption, it creates and displays a file or files containing instructions on how the victim can pay the ransom. If the victim pays the ransom, the threat actor may provide a cryptographic key that the victim can use to unlock the files, making them accessible.

How is ransomware delivered?

Ransomware is commonly delivered through phishing emails or via “drive-by downloads.” Phishing emails often appear as though they have been sent from a legitimate organization or someone known to the victim and entice the user to click on a malicious link or open a malicious attachment. A “drive-by download” is a program that is automatically downloaded from the internet without the user’s consent or often without their knowledge. It is possible the malicious code may run after download, without user interaction. After the malicious code has been run, the computer becomes infected with ransomware.

What can I do to protect my data and networks?

  • Back up your computer. Perform frequent backups of your system and other important files, and verify your backups regularly. If your computer becomes infected with ransomware, you can restore your system to its previous state using your backups.  
  • Store your backups separately. Best practice is to store your backups on a separate device that cannot be accessed from a network, such as on an external hard drive. Once the backup is completed, make sure to disconnect the external hard drive, or separate device from the network or computer. (See the Software Engineering Institute’s page on Ransomware).
  • Train your organization. Organizations should ensure that they provide cybersecurity awareness training to their personnel. Ideally, organizations will have regular, mandatory cybersecurity awareness training sessions to ensure their personnel are informed about current cybersecurity threats and threat actor techniques. To improve workforce awareness, organizations can test their personnel with phishing assessments that simulate real-world phishing emails.

What can I do to prevent ransomware infections?

  • Update and patch your computer. Ensure your applications and operating systems (OSs) have been updated with the latest patches. Vulnerable applications and OSs are the target of most ransomware attacks. (See Understanding Patches and Software Updates.)
  • Use caution with links and when entering website addresses. Be careful when clicking directly on links in emails, even if the sender appears to be someone you know. Attempt to independently verify website addresses (e.g., contact your organization’s helpdesk, search the internet for the sender organization’s website or the topic mentioned in the email). Pay attention to the website addresses you click on, as well as those you enter yourself. Malicious website addresses often appear almost identical to legitimate sites, often using a slight variation in spelling or a different domain (e.g., .com instead of .net). (See Using Caution with Email Attachments.)
  • Open email attachments with caution. Be wary of opening email attachments, even from senders you think you know, particularly when attachments are compressed files or ZIP files.
  • Keep your personal information safe. Check a website’s security to ensure the information you submit is encrypted before you provide it. (See Protecting Your Privacy.)
  • Verify email senders. If you are unsure whether or not an email is legitimate, try to verify the email’s legitimacy by contacting the sender directly. Do not click on any links in the email. If possible, use a previous (legitimate) email to ensure the contact information you have for the sender is authentic before you contact them.
  • Inform yourself. Keep yourself informed about recent cybersecurity threats and up to date on ransomware techniques. You can find information about known phishing attacks on the Anti-Phishing Working Group website. You may also want to sign up for CISA product notifications, which will alert you when a new Alert, Analysis Report, Bulletin, Current Activity, or Tip has been published.
  • Use and maintain preventative software programs. Install antivirus software, firewalls, and email filters—and keep them updated—to reduce malicious network traffic. (See Understanding Firewalls for Home and Small Office Use.)

How do I respond to a ransomware infection?

  • Isolate the infected system. Remove the infected system from all networks, and disable the computer’s wireless, Bluetooth, and any other potential networking capabilities. Ensure all shared and networked drives are disconnected whether wired or wireless.  
  • Turn off other computers and devices. Power-off and segregate (i.e., remove from the network) the infected computer(s). Power-off and segregate any other computers or devices that shared a network with the infected computer(s) that have not been fully encrypted by ransomware. If possible, collect and secure all infected and potentially infected computers and devices in a central location, making sure to clearly label any computers that have been encrypted. Powering-off and segregating infected computers and computers that have not been fully encrypted may allow for the recovery of partially encrypted files by specialists. (See Before You Connect a New Computer to the Internet for tips on how to make a computer more secure before you reconnect it to a network.)
  • Secure your backups. Ensure that your backup data is offline and secure. If possible, scan your backup data with an antivirus program to check that it is free of malware.

What do I do if my computer is infected with ransomware?

References

Author: CISA

This product is provided subject to this Notification and this Privacy & Use policy.

VMware

Configuring NetApp Share through Content Gateway

Leave a comment
This post was originally published on this site

I dunno if I am at the right place here to ask this question but since I struggle for some time to get it done I am trying my luck. We have a Workspace ONE deployment (at VMware´s Cloud) and have a NetApp Storage on premise. Now we want to access the NetApp Storage with the mobile devices through the ‘ Content Locker’  App. I am facing problems with configuring the repository in the Workspace ONE console. The link, how should the syntax for the link look like so that Workspace ONE server can access the repository?

We have a two UAG´s in place, one in the dmz and one in the same subnet as the storage.

VMware

VC_FAULT_FATAL – Disconnected from virtual machine.

Leave a comment
This post was originally published on this site

– ESXi 6.5 U1

– vCenter 6.5 Build 5973321

– VMFS 6

– Horizon 7.7

– VM Tools 10.3

– Instant Clone Pools

 

This error is only happening when publishing Windows 10 (1703, 1809) snapshots to the pool. Seeing the following:

  • The snap publishes to the pool
  • The machines in the pool are created and they are not powered on.
  • The machines are renamed and joined to the domain.

 

VMware says there is a hotfix to address the issue. Is everyone experiencing this issue? Is no one creating Win10 instant clone pools?