<?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>wseaton Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>wseaton Tracker</description>
    <pubDate>Wed, 15 Nov 2023 12:31:10 GMT</pubDate>
    <dc:date>2023-11-15T12:31:10Z</dc:date>
    <item>
      <title>Assigning multiple NICs to specific VMs</title>
      <link>https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/Assigning-multiple-NICs-to-specific-VMs/m-p/2977508#M14712</link>
      <description>&lt;P&gt;Shows how rusty I am with VMware&lt;/P&gt;&lt;P&gt;Single host / 2 NICs. Need to assign specific VMs to a specific NIC because I'm dealing with physically isolated switches.&lt;/P&gt;&lt;P&gt;Both NIC's show up in VSphere, and both linked. Everything running through NIC 1.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Need to route a VM specifically through NIC 2 that's connected to different physical switch, but for the life of me can't remember how to set up physical NIC 2 so it's an option I can present to the VM. Do I create a port group first and then link to a virtual switch, or.....sorry...been awhile. Don't laugh.&lt;/P&gt;</description>
      <pubDate>Fri, 14 Jul 2023 21:12:31 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/Assigning-multiple-NICs-to-specific-VMs/m-p/2977508#M14712</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2023-07-14T21:12:31Z</dc:date>
    </item>
    <item>
      <title>monitoring Intel SSDs from ESXi</title>
      <link>https://communities.vmware.com/t5/vSphere-Storage-Discussions/monitoring-Intel-SSDs-from-ESXi/m-p/2963752#M24735</link>
      <description>&lt;P&gt;Greetings,&lt;/P&gt;&lt;P&gt;Recently inherited a couple smaller ESXi 8 Servers, and found they are running Intel SSDs (4610's) directly off the onboard SATA controllers. No RAID. This is a bit out of my space since I'm used to larger Vmware installs with with either central SAN storage, or pretty large dedicated storage controllers.&lt;/P&gt;&lt;P&gt;I've found those same SSDs to be super reliable on baremetal minus any type of RAID, and I can kind of see the previous admin's point of avoiding the dreadful Dell 'somes with server' lowball RAID offerings. At a minimum I would like to get some kind of direct monitoring going with the Intel SSDs. Intel has some VIB packages available for VMware on their site, but would like to see if anybody has used them and if it's worth the time.&lt;/P&gt;</description>
      <pubDate>Thu, 13 Apr 2023 18:08:09 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Storage-Discussions/monitoring-Intel-SSDs-from-ESXi/m-p/2963752#M24735</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2023-04-13T18:08:09Z</dc:date>
    </item>
    <item>
      <title>Re: Proper methods for backing up large VM's</title>
      <link>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079642#M33588</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Exactly. As a product it's not HP's fault because it's VMware's API that fails making a snapshot. From a file layer perspective it's a solid product.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The other part of your comment.....yep, pursuing it.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 16 Aug 2011 18:37:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079642#M33588</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2011-08-16T18:37:19Z</dc:date>
    </item>
    <item>
      <title>Re: Proper methods for backing up large VM's</title>
      <link>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079640#M33586</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;HP data protector and hardware.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Works great for file level back-ups. Works great for snap-shots and integrates nicely with VCenter. Turns into a paperweight when snap-shots don't work.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In retrospect we should have spent the investment into a robust SANs level back-up solution, but I wasn't here then.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 16 Aug 2011 18:27:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079640#M33586</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2011-08-16T18:27:54Z</dc:date>
    </item>
    <item>
      <title>Re: Proper methods for backing up large VM's</title>
      <link>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079638#M33584</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thanks for the insight Sergeadam. We're on the same wavelength.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;gt;&amp;gt;First you have to set goals. What are you trying to acheive from a backup solution&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Well first, given all the money we dumped into virtualization &lt;STRONG&gt;I'd like the same OS level redundancy and restore capabilities I had with bare iron twelve years ago&lt;/STRONG&gt;. It's that simple. Our operating systems and applications conduct our business, not VM kernels. With bare iron in 1998 I'd use Ghost to back up critical servers to a spare local drive, and use file level back-ups to cover anything else.&amp;nbsp; Even if my entire OS partition or physical drive took a bullet it was a simple task to restore the OS in entire state in less than 20 minutes. Bang - done - server back up. Meanwhile most of my contemporaries would run around looking for their Windows restore disks and shut down production for a few days. After all...they had the MCSE &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@DCF4E2F7991292CEECF250394DB2C2BC/emoticons/1f642.png" alt=":slightly_smiling_face:" title=":slightly_smiling_face:" /&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Fast forward a few years and I started using tools like Paragon, which could do in-state clones to a spare drive or network, often without dropping the server at all. If the system OS took a bullet for whatever reason I could restore it quickly and reliably. When you spend 500 hours getting a Citrix cluster to work flawless you don't use ArcServe to back-up your OS. You learn to clone the OS and stop listening to the nitwits telling you Servers are 'special' and can't be cloned.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Fast forward to now, and I'm running into data centers with data stores slung all over the place with no real schema in mind and pricey back-up mechanisms not working. If I Google problem issues with Snap-Shots I could spend a month reading them all with many VM specialists telling me it's a clunky and primitive process and others telling me it's a panacea, so I'm starting to thing there's a distortion field somewhere. My current back-up solution is 5months old, was put in place by a VMware consulting company, and now I'm told I have to resort to pricey SAN's level back-up methods which eat up any savings I incurred consolidating servers in the first place? This does not compute. This is a School District where budgets are tight.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So, the question remains and has yet to be answered. Is VCenter and it's stock tool set capable of cloning/&amp;nbsp; backing up / mirroring (whatever you want to a call it) a guest OS and be granular enough to not have to deal with attached datastores blowing up the snap-shot process?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 16 Aug 2011 17:55:13 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079638#M33584</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2011-08-16T17:55:13Z</dc:date>
    </item>
    <item>
      <title>Re: Proper methods for backing up large VM's</title>
      <link>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079636#M33582</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&amp;gt;&amp;gt;I also think you might be making some unfair assumptions about snapshots. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;How may I ask am I making an unfair assumption about snapshots when they &lt;STRONG&gt;aren't&lt;/STRONG&gt; working now? Why should I engage in yet another 3rd party&amp;nbsp; product and spend more money when such a product is going to rely on the snapshot process, which I've made clear isn't working on the larger VMs?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;From a bare metal perspective it was easy to perform in-state imaging and back-ups of the bare metal OS that could be restored in minutes. From what I'm hearing this is obsolete with VMware, but&lt;SPAN style="color: #333333;"&gt; &lt;STRONG&gt;I've yet to have a concise answer as to what this process is&lt;/STRONG&gt;&lt;/SPAN&gt; other than references to buy other back-up products that then reference the snap-shot process which is broken on our larger VM's.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We spent $150,000 for our current back-up system, which works exceedingly well for file level restore via guest agents. It works very well for smaller VMs. It does not work with terrabyte size VMs because the VMware snapshot process fails. Which means I need to resort to SAN level products and justifying another huge expense when a $300 copy of Paragon performed the task perfectly on bare metal.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;See my frustration?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 16 Aug 2011 15:50:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079636#M33582</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2011-08-16T15:50:54Z</dc:date>
    </item>
    <item>
      <title>Re: Proper methods for backing up large VM's</title>
      <link>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079634#M33580</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Thank you for the response.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;However, I've already looked at many of those, and maybe my eyes are missing the fine points but I don't see them offering explicitly what I want. I am not looking to back-up an entire Vm. I am not looking to back up a guest OS with the assumption the guest OS is live and will be cooperating. I need a tool that's granular enough to restore a guest OS without worrying about attached storage nor care if the guest OS is functional.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If I may vent for a second the majority of data centers I've worked in (several dozen over the past decade) do not have explicit OS back-ups and the REAL recovery plan is to pull out a Windows recovery CD, or blindly rely on a cluster fail over. This is the second data center I've been in less than 6months where the resident VMware engineers *do not* have functioning guest back-ups once the snap-shot process fails, which it does once the guest VM and attached storage grows large. So, they assume Windows guest OS's will never break, service pack downloads will never throw the guest OS into an infinite upgrade loop, registries will never get corrupted, etc. Vent = off &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@DCF4E2F7991292CEECF250394DB2C2BC/emoticons/1f642.png" alt=":slightly_smiling_face:" title=":slightly_smiling_face:" /&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 15 Aug 2011 17:32:34 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079634#M33580</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2011-08-15T17:32:34Z</dc:date>
    </item>
    <item>
      <title>Proper methods for backing up large VM's</title>
      <link>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079632#M33578</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Forgive me if this question is a bit pedestrian, but I'm a relative newcomer to data center scale virtualization, but have to solve the problem.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I recently took over about 50 virtualized servers running on Vcenter 4, and while everything is running smoothly I've run into a snag regarding our larger VM's. Given I'm certainly not the only guy dealing with terrabyte sized VMs, there has to be some other options and strategy's for dealing with this and am looking for ideas.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Currently our back-up strategy consists of logical segregation between file level back-ups (incremental, etc.) and guest OS back-ups. File level consists of back-up agents running through the guest VMs, and it works fairly well. Guest OS back-ups consist of an automated snap-shot &amp;gt; back-up &amp;gt; delete snap-shot method, and it also works fairly well, with exceptions.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The problem is VMs with a lot of attached storage (we are not using RAW disks). While it's easy to clone / snap-shot a Windows 2008 server, it starts to get inefficient once you start to exceed 100gig or so, and impossible when it get's much larger. Maybe this is something I'm missing with VMware, but as I understand it a guest VM and all the attached storage disks from a SANs are treated as one logical entity from VCenter. So, if you have a base Windows file server (or Exchange server) with several terrabytes of attached storage you can only snap-shot&amp;nbsp; / clone the entire guest *AND* attached data stores.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In the bare metal days I would use any number of tools to clone just the OS drive (or logical disk array) on a periodic basis with any number of tools and ignored the other logical or physical data volumes. If a round of service packs 'bricked' a server who cares - just restore the logical disk or partition and off you go. Even so, I found I was among a minority of Admins who did this having grasped the concept that Server OS's could be treated the same way as Desktop OS's. So, I'm a bit perplexed as to the best way to handle this in our current environment without having to resort to expensive SANs level 3rd party software.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 12 Aug 2011 15:01:47 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Enterprise-Strategy-Planning/Proper-methods-for-backing-up-large-VM-s/m-p/2079632#M33578</guid>
      <dc:creator>wseaton</dc:creator>
      <dc:date>2011-08-12T15:01:47Z</dc:date>
    </item>
  </channel>
</rss>

