Last couple of weeks I heard people either asking questions around how tot limit a VM from an IOps perspective or making comments that Storage IO Control (SIOC) allows you to limit VMs. As I pointed at least three folks to this info I figured I would share it publicly.

There is an IOps limit setting on the virtual disk as an option… This is what allows you to limit a virtual machine / virtual disk to a specific amount of IOps. Now it should be noted that when you set this limit this is handled (vSphere 5.1 and prior) by the local host scheduler, also known as SFQ. One thing to realize though is that when you set a limit on multiple virtual disks for a virtual machine is that all of these limits will be added up and that will be your threshold. In other words:

• Disk01 – 50 IOps limit
• Disk02 – 200 IOps limit
• Combined total: 250 IOps limit
• If Disk01 only uses 5 IOps then Disk02 can use 245 IOps!

There is one caveat though, “combined total” only goes for the disks which are stored on the same datastore. So if you have 4 disks and they are stored across 4 datastores then each of the individual limits apply respectively.

More details can be found in this KB article: http://kb.vmware.com/kb/1038241

"Limit a VM from an IOps perspective" originally appeared on Yellow-Bricks.com. Follow me on twitter - @DuncanYB.

In my earlier blogs on Transforming Security Analytics and Transforming Trust, I wrote about the strong focus we have on cybersecurity at this year’s EMCworld, previewing several of the sessions that will highlight security topics. In addition to those presentations, we’ll also once again have a Birds-of-a-Feather session, focused on Building your Trusted Cloud. It’ll provide a great chance for you to interact with experts from RSA and EMC and wrestle with the critical security issues for private, public and hybrid cloud deployments.

I’ll be moderating the BoF, drawing on the recent Cloud Security Alliance meeting at RSA Conference US in February, the review of OECD Security Guidelines in Paris in early April and my presentation at the Cloud Security Summit last week in Orlando to frame the most critical security questions that enterprises need to consider when establishing private clouds or engaging with cloud service providers. The presenters that I mentioned in earlier blogs (John McDonald, Jason Rader, Matthew Gardiner, Matthew Coles and Yael Villa, who will be presenting instead of Michal) will join me to explore these questions. We’ll be joined by other cybersecurity experts from RSA and EMC, including Davi Ottenheimer, Rob Sadowski and Ash Devata. And there will be lots of opportunity for folks in the audience to pose questions, respond to points made by the panelists and introduce issues that are top-of-mind for them.

You never know where the conversation will go in a BoF! But I’m expecting that we’ll focus on four major topics. The first is the threat landscape for the cloud, especially for the public cloud. What threats do you need to need to consider when thinking about cloud deployments? How do you assess the risk implied by those threats? What do you do about mitigating, transferring or insuring against those risks?

The second topic is security capabilities in and for the cloud. We’ll explore questions such as what should you expect from a cloud service provider in terms of controls and visibility? Where are we in terms of embedded security in cloud infrastructure and where are the big gaps?  We’ll then turn to the third topic: best practices when you entrust data and/or workloads to the cloud. How do you decide what data you can entrust to the cloud? What can you do to enhance the security of mobile devices accessing apps in the cloud, such as in terms of multi-factor authentication?  Finally, we’ll look at the security issues in managing the relationship with the cloud service provider. How do you decide what level of trust you can realistically have with a CSP? What kind of visibility can you have, really, into their infrastructure?

Please join us for this great BoF! And I hope you’ll follow my blogs and tweets @robtwesgriffin throughout EMCworld.

By Matthew Gardiner, Sr. Manager, RSA

I just returned from a weeklong trip to Europe, where I contributed my voice to the wildly successful series of RSA Security Summits. With near unanimity in London and Zurich the audience accepted our premise that as a result of the changing IT landscape – including cloud, mobile, big data, extended workforce, supply chains – and the realities of today’s sophisticated attackers, the approach to security in organizations needs to dramatically change. Furthermore there was also general agreement that today’s preventive security systems, that are largely perimeter and signature-based, no longer provide sufficient defenses, and that to compensate organizations must improve their detective and response focused security controls. This quickly led to the practical and real challenge of how organizations can best make those improvements. How in an environment of fixed security budgets can organizations invest to create or significantly enhance their monitoring and response capabilities?

In effect organizations are asking themselves how they can build out their security operation centers (SOCs). No doubt there are many factors to consider when considering a significant SOC investment, not the least of which is the organization’s security maturity, type and location of sensitive digital assets, expertise, and risk tolerance. But equally important are the technical infrastructure and processes necessary to make SOCs both more effective and efficient in their task of detecting, investigating, and remediating threats and vulnerabilities. With limited human resources, how can the mundane tasks be automated away and the complex ones be made easier? This is a deep topic that we were only able to touch on during these Summits.

But fortunately if you have interest in building what we call an intelligence-driven SOC, RSA is running a webinar precisely on this topic in which we will spend most of the session walking through the detection, investigation, and response lifecycle of a representative advanced attack and show you how an intelligence-driven SOC solution can help to optimize this process. Sound interesting? Come join us at this event happening Thursday, May 2 at 2 pm EST.

Matthew Gardiner is on the product marketing team at RSA and is focused on the evolution of the SOC and RSA’s solutions which help SOC analysts be more effective and efficient in their jobs. You can follow him on twitter @jmatthewg1234.

By  Berk Veral, Senior Product Marketing Manager, RSA

…And they did it, they managed to slow down the internet. Next thing you know, they will break it! I am referring to what’s been called “the largest publicly announced online attack in the history of the Internet.”  And this week we read about the suspect; a 35-year old guy from Netherlands who was arrested in Spain (The Netherlands Public Prosecutor Service press release in Dutch).

This is interesting for two reasons:

1.) Supposedly, a single person can slow down the internet

2.) Flaws and more importantly the vulnerabilities of the Internet are being discussed in the main stream media.

Up until this news hit the media, the Internet was limitless in the public eye.  A big endless digital universe where there are billions of websites for everything and for everyone. The only Internet “speed” issues for the majority of public users were due to their own system performance or the connection – remember modem days anyone?

However, all of a sudden, there is news about a cyber attack actually slowing down the entire Internet. There were discussions about the specific details, the Geo-location effects, which users were impacted and how long, but regardless of the actual impact of this incident on Internet speed, the bigger impact might be how the perception of the Internet has changed; it doesn’t seem as limitless or abstract anymore.

Also interesting, this incident wasn’t “achieved” by an army of researchers and sophisticated coding, it was a DDoS attack by a single person and most likely due to a dispute between two companies. It got so much media attention that not only technology and security media, but global news organizations like the BBC  reported the incident.  Naturally, as it happens with most big news stories, discussions and disputes followed and the story lost its attraction for most audiences.

The real point is darker, though.  It’s about the vulnerabilities that cybercriminals and more specifically a single cyber criminal, have caused a public discussion about the Internet. Let’s hope that the change in public opinion will also help everyone realize that we exist in a physical world but live in a digital world that can be far more dangerous.  A world where our identities, reputations and finances are much more vulnerable.

As we continue to discuss the Cyber Intelligence Sharing and Protection Act (CISPA), its positives, negatives and impacts on privacy, we are already reading news stories on how DDoS attacks are increasing across industries.

Berk Veral is Senior Product Marketing Manager at RSA responsible for RSA FraudAction Anti-Phishing, Anti-Pharming, Anti-Trojan, and Anti Rogue App services as well as RSA FraudAction Intelligence and Cyber Crime Intelligence. Prior to joining RSA, Berk served as a senior member of product marketing teams at global technology companies where he worked closely with global financial institutions on technology solutions

I received this question today around how to increase the Storage IO Control logging level. I knew either Frank or I wrote about this in the past but I couldn’t find it… which made sense as it was actually documented in our book. I figured I would dump the blurp in to an article so that everyone who needs it for whatever reason can use it.

Sometimes it is necessary to troubleshoot your environment and having logs to review is helpful in determining what is actually happening. By default, SIOC logging is disabled, but it should be enabled before collecting logs. To enable logging:

1. Click Host Advanced Settings.
2. In the Misc section, select the Misc.SIOControlLogLevel parameter. Set the value to 7 for complete logging.  (Min value: 0 (no logging), Max value: 7)
3. SIOC needs to be restarted to change the log level, to stop and start SIOC manually, use: /etc/init.d/storageRM {start|stop|status|restart}
4. After changing the log level, you see the log level changes logged in /var/log/vmkernel

Please note that SIOC log files are saved in /var/log/vmkernel.

"Increase Storage IO Control logging level" originally appeared on Yellow-Bricks.com. Follow me on twitter - @DuncanYB.

Year after year, studies such as the Verizon Data Breach Investigation Report show software vulnerabilities and misconfiguration among the main data breach causes. At EMC, we operate under the assumption that securing a product in a customer environment is a team sport between the product vendor and the customer deploying the product. The vendor plays a greater role upstream with a focus on adopting secure development practices and in properly handling and responding to vulnerabilities reported on the product. The customer takes the baton from the vendor and plays a larger role downstream by taking the necessary steps to securely deploy and maintain the product.

Having a baton to pass from the vendor to the customer is critical to facilitate the secure deployment of a product. For our products, the baton takes the shape of a security configuration guide. It is a document required by EMC’s Security Development Lifecycle for each product that centralizes in a single guide all information required to change and optimize the security settings of the products. If you are an EMC customer, you can find this information on our support website’s security configuration guide page.

I am also glad to announce that if you are attending EMC World starting on May 6th in Las Vegas, there will be several security sessions on security including one by Matt Coles from the Product Security Office on “How EMC Enables You to Secure Your Storage Infrastructure” which will explore guidelines for managing VMAX and VNX products securely. Make sure you attend!

The post Secure Product Deployment: A Team Sport appeared first on Product Security Blog.

We had a discussion internally on static overhead memory. Coincidentally I spoke with Aashish Parikh from the DRS team on this topic a couple of weeks ago when I was in Palo Alto. Aashish is working on improving the overhead memory estimation calculation so that both HA and DRS can be even more efficient when it comes to placing virtual machines. The question was around what determines the static memory and this is the answer that Aashish provided. I found it very useful hence the reason I asked Aashish if it was okay to share it with the world. I added some bits and pieces where I felt additional details were needed though.

First of all, what is static overhead and what is dynamic overhead:

• When a VM is powered-off, the amount of overhead memory required to power it on is called static overhead memory.
• Once a VM is powered-on, the amount of overhead memory required to keep it running is called dynamic or runtime overhead memory.

Static overhead memory of a VM depends upon various factors:

1. Several virtual machine configuration parameters like the number vCPUs, amount of vRAM, number of devices, etc
2. The enabling/disabling of various VMware features (FT, CBRC; etc)
3. ESXi Build Number

Note that static overhead memory estimation is calculated fairly conservative and we take a worst-case-scenario in to account. This is the reason why engineering is exploring ways of improving it. One of the areas that can be improved is for instance including host configuration parameters. These parameters are things like CPU model, family & stepping, various CPUID bits, etc. This means that as a result, two similar VMs residing on different hosts would have different overhead values.

But what about Dynamic? Dynamic overhead seems to be more accurate today right? Well there is a good reason for it, with dynamic overhead it is “known” where the host is running and the cost of running the VM on that host can easily be calculated. It is not a matter of estimating it any longer, but a matter of doing the math. That is the big difference: Dynamic = VM is running and we know where versus Static = VM is powered off and we don’t know where it might be powered!

Same applies for instance to vMotion scenarios. Although the platform knows what the target destination will be; it still doesn’t know how the target will treat that virtual machine. As such the vMotion process aims to be conservative and uses static overhead memory instead of dynamic. One of the things or instance that changes the amount of overhead memory needed is the “monitor mode” used (BT, HV or HWMMU).

So what is being explored to improve it? First of all including the additional host side parameters as mentioned above. But secondly, but equally important, based on the vm -> “target host” combination the overhead memory should be calculated. Or as engineering calls it calculating “Static overhead of VM v on Host h”.

Now why is this important? When is static overhead memory used? Static overhead memory is used by both HA and DRS. HA for instance uses it with Admission Control when doing the calculations around how many VMs can be powered on before unreserved resources are depleted. When you power-on a virtual machine the host side “admission control” will validate if it has sufficient unreserved resource available for the “static memory overhead” to be guaranteed… But also DRS and vMotion use the static memory overhead metric, for instance to ensure a virtual machine can be placed on a target host during a vMotion process as the static memory overhead needs to be guaranteed.

As you can see, a fairly lengthy chunk of info on just a single simple metric in vCenter / ESXTOP… but very nice to know!

"What is static overhead memory?" originally appeared on Yellow-Bricks.com. Follow me on twitter - @DuncanYB.

Cybersecurity has been visible in EMC keynotes before. Last year Pat Gelsinger spoke about the importance of security in VMware architecture, for example. But this year is the first time that security has taken center stage in the opening keynote.

Most of the keynote, delivered by David Goulden (EMC COO), was about the new ViPR storage controller and data services capability being released later this year, including a demo of ViPR by Andy Brown, CTO of UBS. But towards the end of the keynote, David invited Jason Rader, Chief Security Strategist for RSA (and a presenter at #EMCworld this year in the RSA session on “Assessing the Value of Information Assets”) to show how cybersecurity attacks can be detected and responded to. Jason did a great job showing Jeremy Burton and all of us in the audience how potential attacks are visible in Archer, how they can be analyzed to determine whether the attacker has caused damage or exfiltrated information, and how the incident can be tracked and responded to effectively.

The solutions pavilion opened for a reception after the keynote. It was great to see that cybersecurity had a substantial presence there as well. RSA has a dedicated booth this year, including a theater with security-related presentations like “Anatomy of an Attack”. There were also quite a few other security-related vendors, like Varonis, who are doing  with a great demonstration of their support for big data analytics in detecting anomalies in access patterns.

So it was a good day for cybersecurity at #EMCworld, including our four well-attended security-related sessions. Lots of interest, lots of energy! I’m looking forward to the rest of the week.

Lately I have been receiving more and more questions around support for specific “hypervisor side” solutions. With that meaning, how VMware deals with solutions which are installed within the hypervisor. I have always found it very difficult to dig up details around this both externally and internally. I figured it was time to try to make things a bit more clear, if possible at all.

For VMware Technology Partners there are various programs they can join. Some of the programs include a rigid VMware test/certification process which results in being listed on the VMware Compatibility Guide (VCG). You can find those which are officially certified on our VMware Compatibility Guide here, just type the name of the solution in the search bar. For instance when I type in “Atlantis” I get a link to the Atlantis ILIO page and can see which version of ILIO is supported today with which version of vSphere. Note that in this case on vSphere 4.x is listed, but Atlantis assured me that this will be updated to include vSphere 5.x soon.

Then there are the Partner Verified and Supported Product (PVSP) solutions. These are typically solutions that do not fit the VCG, for instance when it is new type of solution and there is no certification process yet. Now of course there are still strict guidelines for these solutions to be listed. For instance, your solution will only be listed on the PVSP (and the VCG for that matter) when you are using public APIs. An example for instance is the Riverbed Steelhead appliance, it follows all of the guidelines and is listed on the PVSP as such. You can find all the solutions which are part of the PVSP program here.

Finally there is the VMware Solutions Exchange section on vmware.com. This is where you will find most other solutions… Solutions which are not officially tested/certified (part of the VCG) or part of the PVSP program because of various reasons. Note that these solutions, although listed, are not supported by VMware in anyway. Now, of course VMware Support typically will do its best to help a customer out. However, it is not uncommon to be asked to reproduce the problem on an environment which does not have that solution installed so that it can be determined what is causing the issue and who is best equipped to help solving the issue.

I am not saying that those solution that are not listed on the VCG or PVSP should be avoided. They could very well solve that problem you have, or be the solution to fulfill your business requirements and as such be the “must use” component in your stack. It should be noted though that when introducing any 3rd party solution that there is a “risk” associated with it. From an architectural and operational perspective it is heavily recommended to validate what that risk exactly is. How you can minimize that risk? What you will need to do to get the right level of support? And ultimately, which company is responsible for which part? As when push comes to shove, you don’t want to be that person spending hours on the phone just figuring out who is supporting what! You just want to be on the phone to solve the problem right?!

I hope this helps some of you out there who asked me this question.

** Note: the above is not an official VMware Support statement or a VMware Partner Alliances statement, these are my observations made while digging through the links on vmware.com **

"Tested / Supported / Certified by VMware? (caching / dr solutions)" originally appeared on Yellow-Bricks.com. Follow me on twitter - @DuncanYB.

Timothy R. Rand, Senior Manager, RSA Advanced Cyber Defense Practice – Americas

The main goal of RSA’s Advanced Cyber Defense (ACD) practice is to help customers strengthen their overall cyber security posture so they are able to better defend against advanced threats. In order to accomplish this goal, the ACD team provides a number of services, including an initial engagement referred to as a Breach Readiness Assessment (BRASS).

After having conducted a number of such BRASS engagements over the past year or so with customers in a variety of industry sectors – including, aerospace, financial, telecommunications device manufacturers, and health care technology – we’ve compiled a list of the Top 10 gaps that we’ve observed during these engagements. The following list is roughly ordered in frequency of occurrence (gaps at the top were seen at more customers than those further down the list), but all were observed at numerous customers:

1. No incident response tracking or workflow mechanism (e.g., ticketing system).
2. No clearly defined roles and responsibilities around incident response and other breach-related activities.
3. Ad hoc or unclearly documented incident response procedures. Where such procedures do exist, they often do not match what is done in actual practice.
4. Inadequate or lack of centralized security monitoring and alerting. In many cases, there are no real-time alerting capabilities (e.g., alerts are not delivered to analysts for 24 hours or more).
5. No forensic analysis capabilities. As a result, incident remediation is often incomplete.
6. Insufficient number of security staff.
7. Insufficient or non-existent user awareness training regarding advanced threats.
8. Inadequate patch management process. Many companies do well deploying the monthly Microsoft patches, but struggle to deploy out-of-band and non-Microsoft patches.
9. No post mortem analysis (i.e., lessons learned) following incident resolution.
10. No cyber threat intelligence capabilities. Implementing a strong threat intel program is critical in order to start getting ahead of advanced threats.

Just about any security organization can (and should) benchmark their company’s breach readiness against this list. The obvious and most prudent question is to ask whether any of these gaps exist in your organization’s breach readiness and response plans? How can your organization go about closing these gaps and what are the potential risks to your business if they aren’t fixed?

RSA ACD practitioners work with our customers to provide viable recommendations for resolving each identified gap, including alternatives where applicable. The ACD team also helps implement selected recommendations via other offerings in our service portfolio, including Cyber Threat Intelligence, Breach Management and the development of a NextGen Security Operations Center (SOC). The methodology behind these offerings will be discussed in future posts.

Tim Rand leads the delivery of professional services for RSA’s Advanced Cyber Defense Practice in the Americas, including breach readiness/management, incident discovery, cyber threat intelligence, and Advanced Security Operation Center (ASOC) design and implementation.

Walter Goulet, Senior Practice Consultant/Identity and Data Protection, RSA Advanced Cyber Defense Services

Organizations which deploy RSA Authentication Manager (SecurID) for enforcing two-factor authentication frequently think of their RSA SecurID solution only as an additional security control to enforce strong authentication to resources. However, by analyzing the wealth of log data that is generated by RSA Authentication Manager, organizations can gain valuable intelligence that can be useful to detect attacks and perhaps even predict new attacks.

As my colleague Tom Chmielarski posted a few weeks ago, use cases must be developed first to help guide and refine the types of events that will be valuable to your organization. This post will describe two use cases that many organizations will likely find valuable.

Detect access attempts using lost or stolen tokens

As any organization that has operated an RSA SecurID solution for any period of time already knows, users frequently misplace or lose their hardware tokens. When users report the lost token, normally they are assigned emergency access codes for a short period of time until the token is recovered or a new token is assigned. However, if a user authenticates successfully with their emergency access code:

(AUTHN_METHOD_SUCCESS_TEMPORARY_FIXED_TOKENCODE events for the user are indicated in runtime authentication logs), but subsequent bad PIN events are discovered for the user (AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE events for user are present in runtime authentication logs), there is a possibility that someone has obtained the user’s token without their knowledge and is attempting to guess the user’s PIN.

The previous scenario assumes that the attacker knows the user’s userID; if the useriD is unknown the attacker will likely try to guess the user’s userID. Attempts to guess valid usernames can be detected by looking for AUTH_RESOLUTION_FAILED_BY_ID_ALIAS events.

Of particular interest, observe several subsequent login attempts for a particular userid and try to identify patterns. For example, assume that my userid is ‘wgoulet’. An attacker that knows my name and the company I work for may well generate several possible userids based on my name. Here are a series of events that would be logged by RSA Authentication Manager that could indicate such attempts.

2013-04-05 12:35:52,552,
db0de0686441a8c0052db45bd f59cc15,899413cc6441a8c00 0ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX, AUTH_PRINCIPAL_RESOLUTION,23008, FAIL,AUTH_RESOLUTION_FAILED_BY_ID_ALIAS,, SYSTEM,SYSTEM,SYSTEM, wpgoulet,SYSTEM,SYSTEM, d84f41896441a8c00524ecb3d b4b6e54, 000000000000000000001000e0011000, 192.168.XX.XX,
win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

2013-04-05 12:36:12,630,
db0e2ed56441a8c00538ba24a 960784f,899413cc6441a8c0 00ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX, AUTH_PRINCIPAL_RESOLUTION,23008, FAIL,AUTH_RESOLUTION_FAILED_BY_ID_ALIAS,, SYSTEM,SYSTEM,
SYSTEM, goulew,SYSTEM,SYSTEM,d84f41896441a8c00524ecb3db4b6e54,
000000000000000000001000e0011000,
192.168.XX.XX,win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

2013-04-05 12:36:33,254,
db0e7f666441a8c0053f983220384857,899413cc6441a 8c000ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX,AUTH_PRINCIPAL_RESOLUTION, 23008,FAIL,AUTH_RESOLUTION_FAILED_BY_ID_ALIAS,,SYSTEM,
SYSTEM,SYSTEM,walter.goulet@rsa.com,SYSTEM,SYSTEM, d84f41896441a8c00524ecb3db4b6e54,000000000000000000001000e0011000, 192.168.XX.XX,win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

Detect access attempts to unauthorized resources

Typical organizations use their RSA SecurID solution to provide strong authentication for remote VPN access and for high value applications. Therefore, there will typically be a few SecurID agent hosts that are accessed by a large percentage of the organization’s user population. These usage patterns can be constructed by observing the total number of AUTHN_METHOD_SUCCESS events for each SecurID agent host. By building a history of userids that access agent hosts, you can construct access profiles for your users that show which agent hosts are typically accessed by a given userid. This history can then be cross-referenced with subsequent AUTHN_METHOD_SUCCESS events for a given userid to detect unusual patterns, such as a userid suddenly attempting to access a SecurID agent host that they have not accessed in the past. Alternatively, attempts to authenticate to a large number of agent hosts could indicate attempts to reconnoiter your network to gain access to SecurID protected resources.

Another way to detect unauthorized access to agent hosts is to configure your RSA SecurID agents as restricted agent hosts. When SecurID agents are configured as restricted agent hosts, only users that belong to groups granted access to the agents may authenticate. If unauthorized users attempt to access restricted agent hosts, the following event is logged by AM:

2013-04-11 11:45:03,760, f9c583106441a8c001ee1e2de321139a,899413cc6441a8c000ba0f53a08fd2e6, 192.168.XX.XX,192.168.XX.XX,AUTH_AGENT_ACCESS_CHECK,23004, FAIL,AGENT_ACCESS_CHECK_FAILED_NO_ASSOCIATED_GROUP,, d885b2ae6441a8c00527cc160d00e972,000000000000000000001000d
0011000,000000000000000000001000e0011000,wgoulet,wgoulet,wgoulet, d84f41896441a8c00524ecb3db4b6e54,000000000000000000001000e0011000, 192.168.XX.XX,win2k3-am71.pslab.com,1,,,,,,,1,,,,,,,,

Conclusion

Hopefully this blog post has given you a few ideas of the types of security monitoring use cases that can be implemented by monitoring your RSA Authentication Manager event logs. By combining these events with other events generated by other components of your security infrastructure, you can gain valuable insight into activities taking place on your network to help you better secure your environment.

Walter Goulet is a Senior Practice Consultant within RSA Professional Service’s Identity and Data Protection practice. Walter is responsible for designing and implementing world-class customer security solutions based on RSA’s industry-leading RSA SecurID product line, PKI and other authentication technologies.  Walter holds 2 SANS GIAC certifications as well as a MS in Computer, Information and Network Security from DePaul University.

For years these rumors have been floating around that DRS does not take CPU Ready Time (%RDY) in to account when it comes load balancing the virtual infrastructure. Fact is that %RDY has always been a part of the DRS algorithm but not as a first class citizen but as part of CPU Demand, which is a combination of various metrics but includes %RDY. Still, one might ask why %RDY is not a first class citizen.

There is a good reason though that %RDY isn’t, just think about what DRS is and does and how it actually goes about balancing out the environment, trying to please all virtual machines. Yes a lot of possibilities indeed to move virtual machines around in a cluster. So you can imagine that it is is really complex (and expensive) to calculate what the possible impact is after a virtual machine has been migrated “from a host” or “to a host” for all of the first class citizen metrics.

Now, for a long time the DRS engineering team has been looking for situations in the field where a cluster is balanced according to DRS but there are still virtual machines experiencing performance problems due to high %RDY. The DRS team really wants to fix this problem or bust the myth – what they need is hard data. In other words, vc-support bundles from vCenter and vm-support bundles from all hosts with high ready times. So far, no one has been able to provide these logs / cold hard facts.

If you see this scenario in your environment regularly please let me know. I will personally get you in touch with our DRS engineering team and they will look at your environment and try to solve this problem once and for all. We need YOU!

"DRS not taking CPU Ready Time in to account? Need your help!" originally appeared on Yellow-Bricks.com. Follow me on twitter - @DuncanYB.

In his #EMCworld keynote on Tuesday morning, Joe Tucci used the phrase “the sea of trust” to capture the pervasive role that security has to have in the success of the “third platform” of mobile, cloud and big data. It’s a great metaphor, reflecting not only the pervasiveness that security has to have, but also the dynamism and power that it needs to embrace.

We had the opportunity to explore this new vision for security in our birds-of-a-feather session on “Building Your Trusted Cloud.” We talked about the threat landscape for cloud, security capabilities that cloud service providers should have, best practices in security for the cloud and in engaging with CSPs. And there were great questions that led us into topics that we hadn’t foreseen.

One of the best of these questions was from Mike Versace of IDC, who asked “What are the big breakthroughs that will make a difference in cloud security?”

Mike’s question was excellent because it challenged us to think about what really mattered in establishing and maintaining that sea of trust. RSA’s Rob Sadowski responded with the developments in GRC tools, best practices and standards that help you manage the risk inherent in moving data and workloads into private, hybrid or public clouds. RSA Software Engineer Matt Coles emphasized the embedding of data security capabilities into technology, like encryption built into storage. EMC infosecurity expert Davi Ottenheimer spoke to the critical developments in embedded security in the virtual infrastructure. Matthew Gardiner of RSA called out the importance of new developments in security visibility and analytics technologies. And EMC security consultant John McDonald spoke about the breakthroughs in risk-based authentication as critical to the mobile user environment.

It was great to have such a range of breakthroughs recognized, especially because they also represented a good cut at the most essential capabilities for establishing trust in the cloud. Sure there’s lots of work still needed in making these breakthroughs fully effective. But the essential elements for establishing and maintaining the trusted cloud are here. Maybe that’s the biggest breakthrough of all.

A while back I did this article on Storage DRS Interoperability. I had questions last week about this so I figured I would write a new article which reflects the current state (vSphere 5.1). I also included some details that are part of the interoperability white paper Frank and I did so that we have a fairly complete picture. This white paper is on 5.0, it will probably be updated at some point in the future.

The first column describes the feature or functionality, the second column the recommended or supported automation mode and the third and fourth column show which type of balancing is supported.

(*) = Change from 5.0

"vSphere 5.1 Storage DRS Interoperability" originally appeared on Yellow-Bricks.com. Follow me on twitter - @DuncanYB.