<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: VMware snapshot of vSZ causing AP disconnects in To Be Moved</title>
    <link>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31504#M1719</link>
    <description>Here are the exact times from yesterdays snapshot that results in large number of AP disconnects&lt;BR /&gt;&lt;BR /&gt;Create virtual machine snapshot&lt;BR /&gt;Requested Start Time - 4:17:23&lt;BR /&gt;Start Time - 4:17:23&lt;BR /&gt;Completed Time - 4:17:24&lt;BR /&gt;&lt;BR /&gt;Remove snapshot&lt;BR /&gt;Requested Start Time - 4:20:24&lt;BR /&gt;Start Time - 4:20:24&lt;BR /&gt;Completed Time - 4:20:26&lt;BR /&gt;&lt;BR /&gt;When a VM gets a snapshot or when a snapshot is removed the VM is stunned for a period of time and no I/O happens. The snapshot took 1 second to take and 2 seconds to remove. Seeing "AP lost heartbeat" during this time did not surprise me. One or 2 second stun should not be long enough for an AP disconnect</description>
    <pubDate>Mon, 14 Aug 2017 13:25:15 GMT</pubDate>
    <dc:creator>david_henderson</dc:creator>
    <dc:date>2017-08-14T13:25:15Z</dc:date>
    <item>
      <title>VMware snapshot of vSZ causing AP disconnects</title>
      <link>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31501#M1716</link>
      <description>We have two Ruckus Virtual Smartzone controllers, both running 3.5.1&lt;BR /&gt;We use Veeam for backup and replication. As part of the backup and replication process, each VM gets a VMware snapshot, the snapshot stays open for about 3 minutes, and then the snapshot is deleted&lt;BR /&gt;&lt;BR /&gt;Not every time, but quite often the VMware snapshot process causes AP disconnects. APs disconnect for 20-30 seconds then reconnect. APs do not restart, they just lose the connection to the controller for a short period of time&lt;BR /&gt;&lt;BR /&gt;Has anyone else seen this?</description>
      <pubDate>Sun, 13 Aug 2017 22:40:39 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31501#M1716</guid>
      <dc:creator>david_henderson</dc:creator>
      <dc:date>2017-08-13T22:40:39Z</dc:date>
    </item>
    <item>
      <title>Re: VMware snapshot of vSZ causing AP disconnects</title>
      <link>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31502#M1717</link>
      <description>At a guess yo're seeing VM stun either when creating the snapshot, or more likely when it's being consolidated after deletion. What version of VMWare are you running? ESXi 6 had significant improvements in VM stun around snapshots.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;The other factor affecting VM stun is the speed of your storage. The faster the storage the lesser the affect</description>
      <pubDate>Mon, 14 Aug 2017 06:07:16 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31502#M1717</guid>
      <dc:creator>dave_watkins_74</dc:creator>
      <dc:date>2017-08-14T06:07:16Z</dc:date>
    </item>
    <item>
      <title>Re: VMware snapshot of vSZ causing AP disconnects</title>
      <link>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31503#M1718</link>
      <description>We are running ESXi 6, update 3a&lt;BR /&gt;We are using a Nimble all flash array in production which has very high IOPS and very low latency&lt;BR /&gt;I thought about stun as well but it only takes a second to take a snapshot and even when deleting the snapshot and consolidation occurs it only takes a second&lt;BR /&gt;&lt;BR /&gt;In the Ruckus controller under events I am seeing lots of "AP lost heartbeat" which does make sense. My guess is the AP does lose the heartbeat to the controller for just a second or two. I would not think this is long enough for AP disconnects. We have been running this setup for about 9 months and it is only recently we are seeing this behavior. We were running Ruckus firmware 3.4.x for much of that before upgrading to 3.5.0 and finally to 3.5.1 which is the latest.</description>
      <pubDate>Mon, 14 Aug 2017 10:34:27 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31503#M1718</guid>
      <dc:creator>david_henderson</dc:creator>
      <dc:date>2017-08-14T10:34:27Z</dc:date>
    </item>
    <item>
      <title>Re: VMware snapshot of vSZ causing AP disconnects</title>
      <link>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31504#M1719</link>
      <description>Here are the exact times from yesterdays snapshot that results in large number of AP disconnects&lt;BR /&gt;&lt;BR /&gt;Create virtual machine snapshot&lt;BR /&gt;Requested Start Time - 4:17:23&lt;BR /&gt;Start Time - 4:17:23&lt;BR /&gt;Completed Time - 4:17:24&lt;BR /&gt;&lt;BR /&gt;Remove snapshot&lt;BR /&gt;Requested Start Time - 4:20:24&lt;BR /&gt;Start Time - 4:20:24&lt;BR /&gt;Completed Time - 4:20:26&lt;BR /&gt;&lt;BR /&gt;When a VM gets a snapshot or when a snapshot is removed the VM is stunned for a period of time and no I/O happens. The snapshot took 1 second to take and 2 seconds to remove. Seeing "AP lost heartbeat" during this time did not surprise me. One or 2 second stun should not be long enough for an AP disconnect</description>
      <pubDate>Mon, 14 Aug 2017 13:25:15 GMT</pubDate>
      <guid>https://community.ruckuswireless.com/t5/To-Be-Moved/VMware-snapshot-of-vSZ-causing-AP-disconnects/m-p/31504#M1719</guid>
      <dc:creator>david_henderson</dc:creator>
      <dc:date>2017-08-14T13:25:15Z</dc:date>
    </item>
  </channel>
</rss>

