One thing that is always true, as new technology comes along, some people are going to criticize, ridicule, or simply not believe it does what it says it does.<\/p>\n
Many years ago, I was approached by some guys in development that were having issues with an application that had a SQL database backend, this is the story of how they questioned VMware, and what transpired.<\/p>\n
The environment<\/strong> Yes, this is an old story that I have told many times. This is my first time posting it. I decided to post it, because lately I have had some conversations questioning running servers\/applications in VMware. Yes, even in 2011.\u00a0 Now back to the story.<\/p>\n The problem<\/strong> When they stepped through the stored procedures manually in both physical and virtual, they worked.\u00a0 When they attempted to run them normally through the application, they failed on the virtual machines, but worked on the physical systems.<\/p>\n Result: The developers looked toward IT for a solution, because obviously VMware was the problem, or so it appeared.<\/p>\n The test<\/strong> I suggested the following troubleshooting steps:<\/p>\n The wager:<\/p>\n Initial setup<\/strong> When they were done, I moved the desktop to our staging area, and connected it where they could get to it.<\/p>\n Upon completing the installation by the end of the week, they were set to run their tests on following Monday.<\/p>\n Week One<\/strong> Each day, I dropped by, several times a day, checking on how things were going.\u00a0 Again, “Good” was the only response I received.<\/p>\n Weekend Work<\/strong> Regardless of the steps, after some effort, it was virtualized.<\/p>\n Week Two<\/strong> Just as I had the week before, I stopped by each of the developer’s desks, asking how the test was going.\u00a0 Most of them said “Good.”\u00a0 I would ask “Any issues?” “Nope, nope, and nope.” A few however said words to the effect of “This is faster this week.” The most engaged developer even used the term “flying” to describe the performance.\u00a0 I simply responded with “We had a maintenance window, and now everything in the staging room is on a Gigabit switch.”\u00a0 They took that as the reason that it was running faster.\u00a0 Nevermind that it had more disks from a storage perspective.<\/p>\n In the middle of the day on Friday, I asked them to meet with me regarding virtualizing this server, so we could talk about the P2V process\/etc.\u00a0 We started to talk about the process, and they brought up the normal concerns about downtime, connectivity, and so on.\u00a0 In responding to their question about downtime…<\/p>\n I responded “There won’t be any.”<\/p>\n They responded with “What? No downtime? How can that be?”<\/p>\n I said “I virtualized it last weekend.”<\/p>\n Every mouth in the room dropped.\u00a0 “You did what?”<\/p>\n I said “No problems, issues, etc? Running faster?”<\/p>\n They said “Oh, the ESX box has Gigabit connections, and that’s why it is faster.”<\/p>\n I hated to (but did) break it to them that where it had been running had already been connected to a Gigabit switch.<\/p><\/blockquote>\n Looking deeper<\/strong> It made them look deeper into their issue from a coding\/configuration standpoint.\u00a0 The root of the problem was a misconfiguration of that initial development SQL VM Template.\u00a0 Because the template was misconfigured, any\/all VMs deployed from it were destined to fail. That’s why VMs on both GSX & ESX had the issue.<\/p>\n The point<\/strong> As more and more companies, businesses, etc get to the point of virtualizing servers\/applications, it is important to remember to troubleshoot further than just blaming virtualization.<\/p>\n After that, I can’t remember a developer implicating VMware as the cause of an issue again.<\/p>\n And I’m still waiting for that lunch…<\/p>\n","protected":false},"excerpt":{"rendered":" One thing that is always true, as new technology comes along, some people are going to criticize, ridicule, or simply not believe it does what … <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[30,37,84,90,100,105,111],"class_list":["post-1697","post","type-post","status-publish","format-standard","hentry","category-virtualization","tag-database","tag-esx","tag-sql","tag-tier-1","tag-virtualize-first","tag-vmware","tag-vsphere"],"_links":{"self":[{"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/posts\/1697","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/comments?post=1697"}],"version-history":[{"count":1,"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/posts\/1697\/revisions"}],"predecessor-version":[{"id":1974,"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/posts\/1697\/revisions\/1974"}],"wp:attachment":[{"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/media?parent=1697"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/categories?post=1697"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jasemccarty.com\/blog\/wp-json\/wp\/v2\/tags?post=1697"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nThe development environment was comprised of several application servers and SQL servers that were particular to different builds of our in-house software.\u00a0 Some of the servers were physical, some were virtual running on VMware GSX (now VMware Server) and some were running on VMware ESX 2.5.<\/p>\n
\nThe developers were working on some stored procedures, and noticed some procedures were not executing properly.\u00a0 Upon troubleshooting the problem they decided to blame VMware.\u00a0 The stored procedures worked properly on all of the physical SQL servers, but failed on the virtual SQL servers on VMware GSX\/ESX.<\/p>\n
\nI proposed a challenge to them to determine in fact whether the problem was VMware or not.<\/p>\n\n
\n
\nIf I was right, they (6+ people) could buy me a nice lunch.<\/li>\n
\nThe following week, I gave them an appropriate workstation and the MSDN media for Windows Server 2003 and SQL 2000.\u00a0 I asked them to install Windows and SQL, with all the approved patches (relative to our software).\u00a0 The only things I had control of, with their agreement, were the IP address of the server, the appropriate membership in the Active Directory Domain, and the physical location of it.\u00a0 Nothing else.\u00a0 They had full control of the system.\u00a0 No input\/configuration of the system was going to be done by me or anyone else in IT.\u00a0 They felt very comfortable with that.<\/p>\n
\nOn Monday morning, I dropped by the developer’s desks and checked to see how everything was going.\u00a0 “Good” was the response I got from all of them.<\/p>\n
\nThat Friday night we had a maintenance window.\u00a0 I figured… Why not go ahead and P2V this box and get this over with. Remember from earlier that I was using VMware GSX\/ESX? Yep, VMware Converter hadn’t come out yet, and it wasn’t as easy to P2V a system.\u00a0 I had to use the older P2V Importer application that was a little quirky in comparison.<\/p>\n
\nI failed to share with the developers that I had virtualized the server over the weekend.<\/p>\n
\nTo them the test proved that VMware was not the root of the issue in any form or fashion.<\/p>\n
\nThe point to my story is, it is easy to blame technology when you don’t understand it.<\/p>\n