Uncategorized

Top 5 Planet V12n blog posts week 39

First of all my apologies that this post is a day late. My wife and I went to Köln(or Cologne as most of you probably call it) for the weekend. For me that means no laptop, internet and/or twitter. We had a great time, but I won't tell you all the details just visit it if you are near by. The Cathedral by itself is worth your time! This weeks top 5 is more or less a waste of time. It's only a top 5 because that's what the title of this article is. In my opinion "A “Multivendor Post” on using iSCSI with VMware vSphere" is far above and beyond anything else on the list this week, and probably this year. Although I linked Chad's version this is a collaborative article between VMware (Andy Banta), EMC (Chad Sakac), NetApp (Vaughn Stewart),
Dell/EqualLogic( Eric Schott) and HP/Lefthand Networks (Adam Carter). Thanks guys for this great piece of work…

  • Chad Sakac – A “Multivendor Post” on using iSCSI with VMware vSphere
    One of the most popular posts we’ve ever done was the original “A ‘Multivendor Post’ to help our mutual iSCSI customers using VMware” that focused on the operation of the software iSCSI initiator in ESX 3.5 with several iSCSI targets from multiple vendors. There’s been a lot of demand for a follow-up, so without further ado, here’s a multivendor collaborative effort on an update, which leverages extensively content from VMworld 2009 sessions TA2467 and TA3264. The post was authored by the following vendors and people: VMware (Andy Banta), EMC (Chad Sakac), NetApp (Vaughn Stewart), Dell/EqualLogic( Eric Schott), HP/Lefthand Networks (Adam Carter)
  • Eric Siebert- Master’s guide to VMware Fault Tolerance
    FT works by creating a secondary VM on another ESX host that shares the
    same virtual disk file as the primary VM, and then transferring the CPU
    and virtual device inputs from the primary VM (record) to the secondary
    VM (replay) via a FT logging network interface card (NIC) so it is in
    sync with the primary VM and ready to take over in case of a failure.
    While both the primary and secondary VMs receive the same inputs, only
    the primary VM produces output such as disk writes and network
    transmits. The secondary VM’s output is suppressed by the hypervisor
    and is not on the network until it becomes a primary VM, so essentially
    both VMs function as a single VM.
  • Duncan Epping – Using limits instead of downscaling…
    I’ve seen this floating around the communities a couple of times and
    someone also mentioned this during a VCDX Panel: setting limits on VMs
    when you are not allowed to decrease the memory. For example you want
    to P2V a server with 8GB of memory and an average utilization of 15%.
    According to normal guidelines it would make sense to resize the VM to
    2GB, however due to political reasons (I paid for 8GB and I demand…)
    this is not an option. This is when people start looking into using
    limits. However I don’t recommend this approach and there’s a good
    reason for it.
  • Vittorio Viarengo – Virtualization Journey Stages
    Confidence can be characterized as selective at this stage.
    The team carefully selects the first applications to virtualize based
    on a path of least resistance for their organization. “Do I have a good
    relationship with that application owner?, “Do I have skills to
    virtualize the application in question?”, “What are the risks
    associated with virtualizing it?”, “What are the risks associated with
    NOT virtualizing it?”, “Does the ISV support the application in a
    virtual environment?”, “Is there a compelling reason to virtualize this
    particular app (lack of HA, deploying a new version, non-satisfactory
    uptime…)?”…
  • Steve Kaplan – The desktops may be virtual, but the ROI is real
    While the white paper lacks supporting data, the numbers nonetheless
    look reasonable. For comparison, I recently calculated annual savings
    of $455 for an organization virtualizing 1,000 PCs and laptops as part
    of a phase one View 3 deployment. The payback period of 11.7 months
    against an investment of $500,000 is in the general vicinity of the IDC
    averages. Applying the IDC white paper estimate of $130 in user
    productivity savings further reduces the payback period to 9.3 months.