VMware

Announcing VMware Skyline Updates – December 2019

Before we close 2019, and open the book on 2020, we are happy to announce updates to VMware Skyline. These updates include new findings & recommendations, a Skyline Collector patch, and Skyline Advisor performance improvements.   New Proactive Findings The following Findings & Recommendations have been added to Skyline. If your environment is at risk

The post Announcing VMware Skyline Updates - December 2019 appeared first on VMware Support Insider.

Continue reading..

Announcing VMware Skyline Historical Findings & Recommendations

VMware is pleased to announce Historical Trending for Findings and Remediations within VMware Skyline. Skyline, developed by VMware Global Services, is a proactive support technology available to customers with an active Production Support, or Premier Support entitlement. Skyline automatically and securely collects, aggregates and analyzes customer-specific product usage data to proactively identify potential issues and

The post Announcing VMware Skyline Historical Findings & Recommendations appeared first on VMware Support Insider.

Continue reading..

Announcing VMware Skyline Health for vSphere & vSAN

Meeting Our Customers Where They Are VMware unifies its proactive support technology into a portfolio of complementary services, surfacing the information you need, where and when you need it. Joining forces under the VMware Skyline brand, VMware Skyline Health for vSphere and vSAN are available in the vSphere Client, enabling a native, in-product experience with consistent proactive analytics

The post Announcing VMware Skyline Health for vSphere & vSAN appeared first on VMware Support Insider.

Continue reading..

Meet AVA: VMware Launches Beta of a Virtual Assistant

Read full post . . . or http://feedproxy.google.com/~r/VmwareKnowledgebaseBlog/~3/VUhzwCE-i3Y/meet-ava-vmware-launches-beta-of-a-virtual-assistant.html

By Steve Liang, AVA Project Lead Today we’re excited to introduce a beta of AVA, VMware’s Automated Virtual Assistant. We designed Ava to help users of VMware Docs find answers to common product questions. Using natural language processing, Ava is trained to understand key VMware concepts and recommend further reading that will answer your questions.

The post Meet AVA: VMware Launches Beta of a Virtual Assistant appeared first on VMware Support Insider.

VMware’s New In-Product Support Experience – Help At Your Fingertips

Read full post . . . or http://feedproxy.google.com/~r/VmwareKnowledgebaseBlog/~3/NtTzNg60nX8/vmware-in-product-support-experience.html

  VMware is committed to re-imagining the support experience for our customers. VMware is trusted to run the digital foundation of over 500,000 customers globally. Technology innovation and cloud computing are reshaping customers’ expectations and transforming almost every sector of every industry. Today’s businesses are dependent on a digital infrastructure and when something goes wrong,

The post VMware’s New In-Product Support Experience - Help At Your Fingertips appeared first on VMware Support Insider.

Allegis Group Protects and Speeds Its Environment with a Host of Software-Defined Solutions

With more than 500 locations around the world, 10 subsidiary companies and around 15,000 employees, staffing company Allegis Group has a large and sophisticated IT environment. The company is building a flexible, secure, cloud-ready data center with a full stack of VMware solutions for virtualization, backup, security, cloud automation and containers.   Automated, Intelligent Skyline Support 

The post Allegis Group Protects and Speeds Its Environment with a Host of Software-Defined Solutions appeared first on VMware Support Insider.

Continue reading..

VMware Skyline – Bolsters Proactive Support for Customers with New Features

Today, VMware announced new features and broadened availability to VMware Skyline, its innovative proactive support technology to help customers operate VMware environments with increased reliability, security and performance. Skyline automatically collects configuration, feature, and performance data through data-driven analytics. This can transform visibility into a customer’s environment - what they are running and how their

The post VMware Skyline - Bolsters Proactive Support for Customers with New Features appeared first on VMware Support Insider.

Continue reading..

How VMware is Reimagining Support for You

Read full post . . . or http://feedproxy.google.com/~r/VmwareKnowledgebaseBlog/~3/oxtV5VtRRR0/how-vmware-is-reimagining-support-for-you.html

Scott Bajtos, Chief Customer Officer at VMware Over the past year, I’ve travelled around the world listening to VMware customers. You’ve told me what you love about our products, solutions and support offerings, and what we need to improve. I’ve heard you say that your world is changing. Technology innovation and cloud computing are reshaping

The post How VMware is Reimagining Support for You appeared first on VMware Support Insider.

A look at All Paths Down in vSphere

Read full post . . . or http://feedproxy.google.com/~r/VmwareKnowledgebaseBlog/~3/hukjeQtcheY/a-look-at-all-paths-down-in-vsphere.html

Karthick SivaramakrishnanToday we have a guest post from Karthick Sivaramakrishnan, who is a 3 year veteran at VMware. His primary field of expertise is vSphere Storage and Site Recovery Manager.

This blog post is centered around how ESXi handles unscheduled storage disconnects on vSphere 5.x and 6.x. An unscheduled storage disconnect means some issue in the vSphere environment has led to All-Paths-Down (APD) for a datastore.  An APD situation will be seen when ESXi host does not have any path to communicate with a lun on the storage array.

ESXi host can encounter an APD under several conditions. As a result, we may end up having VMs running on a given datastore go down, the host could get disconnected from vCenter, and in worst cases ESXi could become unresponsive.

From vSphere version 5.x and onwards, we are able to discern whether a disconnect is permanent or transient. Ideally a transient disconnect leads to All Paths Down state and ESXi expects the device to have a temporary disconnect. When we see permanent device loss or PDL the device is expected to have a non-recoverable issue like a hardware error or the lun is unmapped.

In the below example we see all iSCSI datastores are in inactive state.

Datastores

To determine what caused this issue we see ESXi logs, particularly vmkernel and vobd. This issue will be evident in the vmkernel logs.

vmkernel log

2017-01-10T13:04:26.803Z cpu1:32896)StorageApdHandlerEv: 110: Device or filesystem with identifier [naa.6000eb31dffdc33a0000000000000028] has entered the All Paths Down state.

2017-01-10T13:04:26.818Z cpu0:32896)StorageApdHandlerEv: 110: Device or filesystem with identifier [naa.6000eb31dffdc33a000000000000002a] has entered the All Paths Down state.

vobd log

2017-01-10T13:04:26.905Z: [scsiCorrelator] 475204262us: [esx.problem.storage.connectivity.lost] Lost connectivity to storage device naa.6000eb31dffdc33a0000000000000028. Path vmhba33:C0:T1:L0 is down. Affected datastores: “Green”.

2017-01-10T13:04:26.905Z: [scsiCorrelator] 475204695us: [esx.problem.storage.connectivity.lost] Lost connectivity to storage device naa.6000eb31dffdc33a000000000000002a. Path vmhba33:C0:T0:L0 is down. Affected datastores: “Grey”.

From these logs we understand that ESXi host has lost connectivity to the datastore. Any virtual machines using the affected datastore may become unresponsive. In this example while the datastores was mounted on ESXi, we lost the network uplink on the nic that was used for iSCSI connection. This was a transient issue and the datastore came up once the network uplink was restored.

In the below example we see Datastore Black is in inactive state.

Datastore view missing

If we look into the logs to determine whats going on we see these events.

Vmkernel.log

2017-01-09T12:42:09.365Z cpu0:32888)ScsiDevice: 6878: Device naa.6000eb31dffdc33a0000000000000063 APD Notify PERM LOSS; token num:1

2017-01-09T12:42:09.366Z cpu1:32916)StorageApdHandler: 1066: Freeing APD handle 0x430180b88880 [naa.6000eb31dffdc33a0000000000000063]

2017-01-09T12:49:01.260Z cpu1:32786)WARNING: NMP: nmp_PathDetermineFailure:2973: Cmd (0xc1) PDL error (0x5/0x25/0x0) - path vmhba33:C0:T3:L0 device naa.6000eb31dffdc33a0000000000000063 - triggering path evaluation

2017-01-09T12:49:01.260Z cpu1:32786)ScsiDeviceIO: 2651: Cmd(0x439d802ec580) 0xfe, CmdSN 0x4b7 from world 32776 to dev “naa.6000eb31dffdc33a0000000000000063” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.

2017-01-09T12:49:01.300Z cpu0:40210)WARNING: NMP: vmk_NmpSatpIssueTUR:1043: Device naa.6000eb31dffdc33a0000000000000063 path vmhba33:C0:T3:L0 has been unmapped from the array

After some time passes you will see this message:

2017-01-09T13:13:11.942Z cpu0:32872)ScsiDevice: 1718: Permanently inaccessible device :naa.6000eb31dffdc33a0000000000000063 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.

In this case the lun was unmapped from the array for this host and that is not a transient issue. Sens data 0x5 0x25 0x0 corresponds to “LOGICAL UNIT NOT SUPPORTED” which indicates the device is in Permanent Device Loss (PDL) state. Once ESXi knows the device is in PDL state it does not wait for the device to return back.

ESXi only checks ASC/ASCQ and if it happens to be 0x25/0x0 or  0x68/0x0, it marks device as PDL.

VMware KB 2004684 has in-depth information around APD and PDL situations. It also talks about planned and unplanned PDL. You can read it here: Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x (2004684)

Further on in the hostd logs you will see some additional events that will correlate to storage connection.  Look for the below event id’s.

Event ID : esx.problem.storage.connectivity.lost

datestores3

“esx.problem.storage.connectivity.lost” event indicates a loss in connectivity to the specified storage device.  Any virtual machines using the affected datastore may become unresponsive.

Event ID : esx.problem.scsi.device.state.permanentloss

datastores4

“esx.problem.scsi.device.state.permanentloss” event indicates a permanent device loss.

The post A look at All Paths Down in vSphere appeared first on Support Insider.

A look at All Paths Down in vSphere

Read full post . . . or http://feedproxy.google.com/~r/VmwareKnowledgebaseBlog/~3/hukjeQtcheY/a-look-at-all-paths-down-in-vsphere.html

Karthick SivaramakrishnanToday we have a guest post from Karthick Sivaramakrishnan, who is a 3 year veteran at VMware. His primary field of expertise is vSphere Storage and Site Recovery Manager.

This blog post is centered around how ESXi handles unscheduled storage disconnects on vSphere 5.x and 6.x. An unscheduled storage disconnect means some issue in the vSphere environment has led to All-Paths-Down (APD) for a datastore.  An APD situation will be seen when ESXi host does not have any path to communicate with a lun on the storage array.

ESXi host can encounter an APD under several conditions. As a result, we may end up having VMs running on a given datastore go down, the host could get disconnected from vCenter, and in worst cases ESXi could become unresponsive.

From vSphere version 5.x and onwards, we are able to discern whether a disconnect is permanent or transient. Ideally a transient disconnect leads to All Paths Down state and ESXi expects the device to have a temporary disconnect. When we see permanent device loss or PDL the device is expected to have a non-recoverable issue like a hardware error or the lun is unmapped.

In the below example we see all iSCSI datastores are in inactive state.

Datastores

To determine what caused this issue we see ESXi logs, particularly vmkernel and vobd. This issue will be evident in the vmkernel logs.

vmkernel log

2017-01-10T13:04:26.803Z cpu1:32896)StorageApdHandlerEv: 110: Device or filesystem with identifier [naa.6000eb31dffdc33a0000000000000028] has entered the All Paths Down state.

2017-01-10T13:04:26.818Z cpu0:32896)StorageApdHandlerEv: 110: Device or filesystem with identifier [naa.6000eb31dffdc33a000000000000002a] has entered the All Paths Down state.

vobd log

2017-01-10T13:04:26.905Z: [scsiCorrelator] 475204262us: [esx.problem.storage.connectivity.lost] Lost connectivity to storage device naa.6000eb31dffdc33a0000000000000028. Path vmhba33:C0:T1:L0 is down. Affected datastores: “Green”.

2017-01-10T13:04:26.905Z: [scsiCorrelator] 475204695us: [esx.problem.storage.connectivity.lost] Lost connectivity to storage device naa.6000eb31dffdc33a000000000000002a. Path vmhba33:C0:T0:L0 is down. Affected datastores: “Grey”.

From these logs we understand that ESXi host has lost connectivity to the datastore. Any virtual machines using the affected datastore may become unresponsive. In this example while the datastores was mounted on ESXi, we lost the network uplink on the nic that was used for iSCSI connection. This was a transient issue and the datastore came up once the network uplink was restored.

In the below example we see Datastore Black is in inactive state.

Datastore view missing

If we look into the logs to determine whats going on we see these events.

Vmkernel.log

2017-01-09T12:42:09.365Z cpu0:32888)ScsiDevice: 6878: Device naa.6000eb31dffdc33a0000000000000063 APD Notify PERM LOSS; token num:1

2017-01-09T12:42:09.366Z cpu1:32916)StorageApdHandler: 1066: Freeing APD handle 0x430180b88880 [naa.6000eb31dffdc33a0000000000000063]

2017-01-09T12:49:01.260Z cpu1:32786)WARNING: NMP: nmp_PathDetermineFailure:2973: Cmd (0xc1) PDL error (0x5/0x25/0x0) - path vmhba33:C0:T3:L0 device naa.6000eb31dffdc33a0000000000000063 - triggering path evaluation

2017-01-09T12:49:01.260Z cpu1:32786)ScsiDeviceIO: 2651: Cmd(0x439d802ec580) 0xfe, CmdSN 0x4b7 from world 32776 to dev “naa.6000eb31dffdc33a0000000000000063” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.

2017-01-09T12:49:01.300Z cpu0:40210)WARNING: NMP: vmk_NmpSatpIssueTUR:1043: Device naa.6000eb31dffdc33a0000000000000063 path vmhba33:C0:T3:L0 has been unmapped from the array

After some time passes you will see this message:

2017-01-09T13:13:11.942Z cpu0:32872)ScsiDevice: 1718: Permanently inaccessible device :naa.6000eb31dffdc33a0000000000000063 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.

In this case the lun was unmapped from the array for this host and that is not a transient issue. Sens data 0x5 0x25 0x0 corresponds to “LOGICAL UNIT NOT SUPPORTED” which indicates the device is in Permanent Device Loss (PDL) state. Once ESXi knows the device is in PDL state it does not wait for the device to return back.

ESXi only checks ASC/ASCQ and if it happens to be 0x25/0x0 or  0x68/0x0, it marks device as PDL.

VMware KB 2004684 has in-depth information around APD and PDL situations. It also talks about planned and unplanned PDL. You can read it here: Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x (2004684)

Further on in the hostd logs you will see some additional events that will correlate to storage connection.  Look for the below event id’s.

Event ID : esx.problem.storage.connectivity.lost

datestores3

“esx.problem.storage.connectivity.lost” event indicates a loss in connectivity to the specified storage device.  Any virtual machines using the affected datastore may become unresponsive.

Event ID : esx.problem.scsi.device.state.permanentloss

datastores4

“esx.problem.scsi.device.state.permanentloss” event indicates a permanent device loss.

The post A look at All Paths Down in vSphere appeared first on Support Insider.

Go Que Newsroom Categories

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 16 bytes) in /home/content/36/8658336/html/goquecom/wp-includes/wp-db.php on line 1995