VMLogix Virtual Lab Automation Solution for Education Institutes and Universities

June 18, 2009

As part of the VMLogix education program, Universities and education institutes worldwide can now get access to a free copy of the award winning VMLogix LabManager solution.

VMLogix LabManager is a powerful virtual lab management solution that enables IT administrators to use any of the leading virtualization platforms to consolidate virtual lab infrastructures and enables end users (i.e., students) to gain access to lab infrastructure in a policy controlled, automated and self service manner. You can refer to the case studies to learn more about the uses of VMLogix LabManager specifically in development/test labs and training labs.

What Universities Get

  • VMLogix LabManager license at no cost (enabled for 1 year) for the latest GA release of VMLogix LabManager. There will be no cap on the number of managed hosts.
  • A waiver of the support and maintenance fees for the first year. Complementary access to VMLogix product support for the first year (access to limited support will only be provided).
  • As part of this program, VMLogix LabManager can be used to manage hosts running VMware (ESX) or Microsoft (Hyper-V) virtualization technologies.

VMLogix does require that the University representative commit to serve as a reference customer.

How to Request a Free Copy for Your University

  1. You/an appropriate representative from the University should contact VMLogix sales (sales@vmlogix.com ) to request for a free license. The email needs to come from a valid university email address (.edu for instance)
  2. VMLogix sales will respond with instructions on how to download the product bits (along with a deployment guide and other product documentation) and with a license key for the software

If you have any further questions, do contact us at – info@vmlogix.com

Make Your Request Now – This offer is open only for a limited number of participating Universities!

Bookmark and Share

Advertisements

Introduction and Tutorials on Server Virtualization

February 27, 2009

Virtual lab automation (VLA) is a management technology that helps users leverage virtualization platforms (hypervisors) to consolidate and automate lab IT infrastructure so that software applications can be delivered and maintained more quickly, cost-effectively and reliably. If you are considering VLA in your virtual labs, you will first need to have a basic degree of familiarity with virtualization to fully understand, appreciate and subscribe to the benefits of VLA.

Here are a set of resources that should help readers get basic familiarity with virtualization technology. If there are other compelling “Virtualization 101” resources that you think should be included here, do drop me a note.

This article is a great introduction to the technology, the benefits and what new users should look for in virtualization. I have pulled out a few key and relevant statements from the article (bold mine):

However, industry watchers report that most companies begin their exploration of virtualization through application testing and development. Virtualization has quickly evolved from a neat trick for running extra operating systems into a mainstream tool for software developers. Rarely are applications created today for a single operating system; virtualization allows developers working on a single workstation to write code that runs in many different environments, and perhaps more importantly, to test that code. This is a noncritical environment, generally speaking, and so it’s an ideal place to kick the tires.

And in response to “What you should look for in virtualization?”

In a word: management. The core hypervisor technology that decouples the application stack from the underlying hardware is well on its way to commoditization. The large enterprise software vendors (Microsoft, Sun Microsystems, BEA Systems, Hewlett-Packard, BMC and CA, for example) are including it in their product suites, and the standalone virtualization vendors are giving it away. Where they differ is in their ability to provide tools for managing, monitoring and optimizing the allocation of virtualized resources. Look for solutions that provide easy-to-use tools for gathering statistics and applying dynamic policies to better allocate your physical resources among the virtual consumers of those resources.

This is a nice video that explains both the basics of virtualization and also focuses on the importance and relevance of management and provisioning in a virtualized environment.

Another very good video delivered by the Dell CTO that explains the basics of virtualization. He explains the concept of a VM nicely and also points towards relevant trends including the hypervisor becoming a commodity.

Well written article that talks about the advantages and disadvantages of virtualization and also includes a discussion around decision factors around virtualization. From the article, one of the benefits that the writer mentions “Test and Development Agility”.

Test and Development Agility

Part of the advantage of business agility derives also from test and development agility. Staff can develop and test new capabilities side-by-side on multiple operating systems, and benefit from faster build/test/rebuild cycles (especially across multiple operating systems). Virtualization reduces mundane deployment processes for production implementation to minutes instead of days or weeks, reduces procurement time, and results in fewer hardware compatibility issues.

And by the way, one of the key disadvantages that the writer mentions about virtualiation is “Image Proliferation”. You should note that VLA management tools help actively combat and control VM sprawl.

Image Proliferation

Operating system and server virtualization can lead to a rapid proliferation of system images because it is so much easier and faster to deploy a new virtual image than to deploy a new physical server without approval or hardware procurement. This can impose very high management and maintenance costs and potentially lead to significant licensing issues, including higher costs and compliance risks. Enterprises need to manage their virtual environment with the same level of discipline as their physical infrastructure, using discovery tools to detect and prevent new systems from being created without following proper process.

The relevant piece from this article would be the section on “Selling virtualization to the development groups”.

Selling virtualization to development groups
Virtualization can be a great benefit to application developers. Developers are typically concerned that their applications may not run properly on virtual hardware. Virtualization actually provides the same exact virtual hardware to each virtual machine which will provide consistent hardware to developers across all environments, such as development, testing, production, etc., eliminating potential problems that may be caused by using different hardware on different servers running the same applications.

Developers might also be concerned that application vendors will not support their products in virtual environments. Although most vendors do provide support for their products running on virtual servers, it’s a good idea to make a list of your applications and get statements of support from each vendor who will usually have this available on their website.

To make the case to your development team:

  • Explain the concept of virtual hardware and how it differs from physical hardware.
  • Show support statements from application vendors.
  • Explain resource pools and how features like resource schedulers work.
  • Demonstrate a tool like Snapshot Manager and show how to clone servers.

In addition to this, I would point your developers/test staff to the article:: Features and functionality in Virtual Lab Automation solutions.

I Get Virtualization Now. So, What’s VLA Management Adding to the Mix?

Server Virtualization with VLA Management Benefits

Server Virtualization with VLA Management Benefits

Now that you are familiar with basic server virtualization, you may find the following reading about virtual lab automation and management applications useful. They talk about specific benefits/use cases of VLA over and above basic server virtualization and how a VLA management application adds tremendous value to the virtualization platform in the dev/test environment.

Bookmark and Share


When Creating Test Environments Can Get Out of Hand

December 3, 2008

Server virtualization is an accepted and mainstream technology used by increasing number of software testers today. The technology helps testers rapidly create virtual machine test environments. Testers who are new to virtualization rely on basic hypervisor technologies from VMware (e.g., VMware Server), Microsoft (e.g., Virtual PC) etc. to create these virtual machine test environments. One of the downsides of using a bare hypervisor is the problem of introducing Virtual Machine (VM) sprawl. A detailed post on the downsides of relying only on a basic hypervisor are discussed here.

The Problem of VM Sprawl: Virtualization technology makes it extremely easy for end users to create and deploy VMs. This can quickly get out of hand – resulting in an increasing number of VMs and difficulty in tracking and managing the VMs. This problem is referred to as VM sprawl. Most often, VM sprawl issues have a profound impact when VMs are used in production (and this is discussed often). However, it is an equally important problem to be aware of when you are actively using virtual machines in your dev/test environments.

When is your Dev/Test Organization at Risk with This VM Sprawl Problem: Here are typical scenarios that are would quickly lead to a VM sprawl problem in your organization.

  • Your organization or group lacks clear policies to control the creation and deployment of VMs in your environment
  • When VMs are abundantly used by your dev/test teams (e.g., it is the de-facto choice when users need new machines. And everyone operates with their own instance of VMware Server/MS Virtual PC etc.)
  • The risk of being affected with the VM sprawl problem are higher if your organization is running distributed teams (offshore/distributed company locations)

Why is the VM sprawl problem relevant to the Dev/Test Organization: So, if you do think that your organization is at risk, what are the specific problems that you are likely to run into if you let things continue ‘as-is’ and without addressing the VM sprawl problem?

  • Resource hogging: It is likely that some of your dev/test staff would let their VMs run continuously on server resources – sometimes without keeping a track of when it is being actually used or left idle. This will lead to server resources being blocked and being unavailable for others to use.
  • Increase in operational costs: Since every user creates and runs their own VMs, the cost of storage, server resources required etc. will go up linearly.
  • Difficult to track license usage: It will be practically impossible for IT administrators to keep track of specific software/OS licenses being used in each VM
  • Compliance and audit: This is less of a problem in dev/test, but a problem regardless. If your administrator ever needs to respond to a compliance audit, it will be a nightmare tracking and reporting the inventory of all machines being run
  • Impossible to track VM creations: It will be quickly impossible to manually (via Microsoft Excel, Word etc.) track VM creations by individuals as well as the resource utilization by each user

If VM sprawl is a problem that you are seeing in your dev/test environments or is likely to be a problem that you will run into shortly, you should consider looking at lab management solutions like VMLogix LabManager. These solutions do a good job of herding the VMs created in a lab (dev/test) environment and provide powerful tools to manage these configurations.

My next post will talk about how VMLogix LabManager can help control your VM sprawl in the dev/test environments. Stay tuned.

– Srihari Palangala

Other useful reading:

Bookmark and Share


Getting by with desktop virtualization for your testing needs? Here is what you are missing

November 6, 2008

All major virtualization platform vendors offer a cheap (some even free) solution that allow you to run multiple virtual machines on your desktop. Examples include VMware Workstation, Microsoft Virtual PC and Sun’s VirtualBox.

While desktop virtualization products offer a ‘quick and dirty’ solution for some testing infrastructure needs, they fall short when virtualization is to be truly leveraged across the software labs. [Side note — I have also written about why only a basic hypervisor alone is not sufficient for lab requirements in the past].

If you are currently getting by with desktop virtualization for your testing needs, maybe it is time for you to start looking at centralized virtual lab automation solutions. Virtual lab automation (VLA) solutions such as VMLogix LabManager and VMware Lab Manager are management systems by which recurrent labor-intensive manual tasks necessary in test and development labs can be automated and by which test and development lab processes and infrastructure can be streamlined and centrally managed.

Here are the key benefits of implementing a centralized virtual lab infrastructure instead of relying on individual desktop virtualization solutions:

Virtual lab automation solutions and desktop virtualization

Virtual lab automation solutions and desktop virtualization

Shared Infrastructure

  • Allow all your lab users to leverage the central library of templates and other lab artefacts (scripts, licenses, software etc.). Save your lab users’ time and avoid re-work
  • All infrastructure (hosts, storage, user access) is managed by the lab admin; users can access the lab in a self serve manner and focus on the testing
  • Collaboration – VLA enables the sharing of multi-machine configurations and other lab artefacts among users/teams making it easy to drive synergies in the software engineering efforts
  • Expand the lab use beyond just the testers and developers – bring support, pre-sales and training staff to use the central lab infrastructure effectively. This helps grow the lab user base

Scalable Infrastructure

  • Access to enterprise server grade infrastructure (CPU, storage) to run complex resource intensive jobs (prolonged jobs can be run on the host server farms with no impact to the desktop machines)
  • Ability to leverage and use network fencing – i.e., the ability run multiple copies of a multi-machine configuration in parallel without any IP/MAC address conflicts

On the other hand, here is the key benefit of using desktop virtualization.

Independence

  • Desktop virtualization provides the ability to access the VMs anywhere even when you are not connected to the lab

How is your infrastructure for the testers/devs in your team setup currently? What are your experiences?

– Srihari Palangala

Bookmark and Share


Increasing the Role and Relevance of Software Labs in Building Quality Software

October 6, 2008

Dennis Stevenson blogs at Original Thinking and is a Director of Software as a Service (SaaS) for a software company in the healthcare automation space. He has extensive experience working on software engineering and in software labs. You can read his bio here.

He recently posted on “Getting Software Development Out of the Lab” on his blog. It was an interesting post and brought forth the relevance of involving the field in the software development/testing and lab processes. Clearly, Dennis is an expert in this domain and we caught up with him to get his perspective on the Changing Role and Expectations of Software Labs.

This blog has focused on virtual lab automation and lab management tools like VMLogix LabManager – we hope you find this detailed discussion on increasing the role/relevance of software labs in building great software useful.

In summary, Dennis made the following very important points:

  • Traditionally, the software lab is a place where rapid prototyping and experimentation was done. In more recent times, the trend has shifted towards using the lab as an isolated sandbox where developers/testers can focus on building great software

  • The three most important (technology) requirements of a lab today are – (a) Automation (b) Collaboration between multiple users and (c) Ability to mimic field like conditions in the lab

  • The lab is treated as a black box in organizations today – this is an important problem for business – which demands the need for more transparency and communication between the lab and various other business/engineering functions
  • The executive leadership in an organization needs to be a stakeholder in the lab – which will help transform the lab as a strategic asset
  • Ultimately – the ability to ship great software (e.g., software being requirements compliant) – largely depends on the entire efficiency of the lab experience

[VMLogix] How have you been involved with software labs in your career?

[Dennis] In my experience, historically, the lab has been a very vague concept. Earlier in my career, we had engineering software labs where the real focus was the ability to try new things. And whenever I used the lab it was always in the prototyping and rapid deployment kind of a scenario. Labs for me were a place where the traditional production rules did not apply, where I did not have to follow the same methodologies and I did not have to worry about building production grade software, but where I could very rapidly deploy an idea and determine if that idea was going to make sense or not. I could run a pilot out of the lab very quickly and easily and make a decision about whether or not a given technology had relevance or applicability to the business problems that I was trying to solve or if it was something that I just wanted to let pass by. I had a very successful venture doing Wiki deployment where rather than developing it internally, we were trying different software products to decide which one we wanted to use as an enterprise solution. In that case the lab was the place where I could install software that I could not do in traditional data center environments, play with them and see in a “no-penalty” type of a way.

In other organizations, I’ve seen lab concepts exist though they did not recognize it as such. We had a series of engineers who were trying very hard to maintain an isolated environment where they could develop software according to requirements that were provided to them. In this case they were disconnected from the user experience. We attempted to simulate in the laboratory environment the end customer and the kinds of experience that they would bring to the software. The real driver for the lab was “here are the requirements” just “write good code”, “be very efficient”, “be productive”. Labs gave us isolation, which meant focus and concentration and hence enabled great progress. We invested enormous amount of effort and time into building processes for creating, testing and certifying software. But none of those agile build, continuous integration or other processes could be used once systems went into a client or field environment. So more recently, I began to wrestle with – how do we use the lab? What is the proper role of a lab? Do we try to support the field experience out of the lab or do we have to do something else in order to be relevant to the field users?

[VMLogix] What are the top technical challenges for a software lab today?

[Dennis] Several things jump to mind, here are the key points:

  • The lab environment must be automated. The concept of a lab is destroyed in my opinion if you don’t have automated testing, some sort of automated build, if you don’t have tools that look at the code produced and render some sort of verdict about its suitability, usability or its quality. And it is very important in a lab environment that the developers in a lab environment not be burdened down with a lot of administrative or repetitive tasks. The lab is more productive if it can make this process smoother and enable faster feedback to the developers about whether the code they’ve written works or doesn’t work.
  • The other piece to this is the offshored/outsourced relationship in software engineering teams today – the lab absolutely needs to be portable. It is very easy to get in and build a heavy lab, where it is very site specific, where the processes are very heavily and locally customized and where the automation is unique to this particular place or circumstance. This ends up being a limitation and barrier over time, because we are working through the issue of how do we replicate our lab environment for somebody else to participate or collaborate with us. I think collaboration is an ongoing theme that we really have to wrestle with these days in terms of one team working on software, handing it off to another team or integrating things from another team and so on. To the extent that the lab environment were to operate the same, feel the same, and produce similar kinds of results, the stitching together process becomes so much easier. In my mind, the purpose of the lab is to get the efficiency and let people get focused on the real hard problems not the brute force problems.
  • The lab cannot be entirely self focused. It is easy to think that the world is a sterile place that I can replicate or create in a lab environment. The reality is that when my software hits the real world and real users with completely different assumptions about what it should do and how it should work, interact with it, have different priorities than what the software developer or product manager think about – there needs to be fast communication loops with the field communicating back to the labs so that the lab can increasingly mimic what the field looks like and also so that software can be rapidly modified as it deals with this new scenario and is worked upon to work in a manner that it is designed to perform.

[VMLogix] What do you think business expects from the lab? And how can you have lab goals aligned with those priorities?

[Dennis] Business expects predictability and quality. By predictability, they need to know: How long software is going to be in the lab? When is it going to be released? And will it be what they expect when it comes out? The risk is that the lab becomes a tremendous black box environment to the rest of the business and that fosters this really difficult tension of “us” and “them” between the business users, software engineers and the lab. Penetrating this and being able to establish the relevancy and maintain cohesion is hard, especially if you are an ISV. It is easy for the business to move off in a direction — that maybe the lab does not understand and the lab is always playing catch up in that scenario… always trying to understand what the expectations are because the business seems to be running away. Software engineering is a discipline and someone does not understand that casually along the way. Attention needs to be given. Methodologies like Agile can help, but it is not a requirement for a lab. Lab as an organization needs to be able to communicate and give confidence to the business that they are getting what they expect / want or what they need. This has been the fundamental tension. Contrast this with the software development that happens in the field. In this case, business is very clear and comfortable with what’s happening – the problem, what fix is happening and the scope of the activity is relatively small. The challenge comes when software needs to be in the lab for 4-5 months, that is long time for the business to say “I don’t understand what you are doing”.

[VMLogix] Do you think labs can be a strategic asset?

[Dennis] Labs can be a black box mode, but at the same time be a strategic asset. Do we think the industry as a whole will migrate there? No, I don’t think so. However, players in the industry may adopt this. But as much as I know about people as software engineering, these tend to be more people kind of management problems, like communication management problems – and that is a lot harder to solve. Tools and technology make this problem easier and can mitigate some challenges that the lab faces in establishing its strategic value. I don’t know if this problem is entirely solvable with technology but is certainly made a lot less daunting with technology.

[VMLogix] Who are the lab stakeholders? And according to you, who should be the lab champion?

[Dennis] The technical leadership is clearly a stakeholder because the lab is the main vehicle by which the technical development happens. In my opinion the other big stakeholder is the product management organization who very often is the key driver of activity into the lab and validator of output out of the lab. Now that is really challenging because as a rule, product management tends to be outwardly focused. And so it is very difficult for a product manager to maintain that dual role (“we understand the market and what the market wants” AND “we understand how the lab is responding to the requirements and how they are creating software”). That is a difficult spot for one organization to be in. In my experience the other stakeholder is the parts of the organization that deal with the software once it goes out into the field. That may be a customer support or client services organization that has to face the slings and arrows of the user base when the software does not behave as it should in particular circumstances. To the extent that those organizations can be stakeholders and actually exercise influence, I think it is a powerful force for the delivery of market relevant functions.

At a higher level, the executive leadership of an organization needs to be considered as a stakeholder because they create the strategic direction that places the lab in a central role or requires the lab to move into a central role. And they need to understand what it takes to harvest value out of that or what it takes to create that value in the first place.

[VMLogix] What are your top wish list capabilities that you want to see labs enabled with?

[Dennis] The development process needs to be well thought out, well understood and embedded into the culture. The big piece that is difficult is the integration of the development and testing of software. And the better that can be done, the better the flow of the software and I think that ultimately the testing and the certification of the software as being requirements compliant – the extent to which you can do that and the speed with which you can do that is very closely hinging on the efficiency of the entire lab experience. You want an independent testing organization, but you don’t want a lot of organizational overhead or process overhead between the development and the testing of the software. Testing can go such a long way too – you can get into usability testing, feature function testing, integration testing, system testing, acceptance testing, performance testing, load testing etc. When you look at the number of available testing that can be performed on software (all of which are incredibly relevant as software starts getting deployed and people begin to depend upon it), having the ability in the lab to do all of those things quickly and easily is incredibly important. Honestly, it is so easy to say “we’re not setup to do load testing…we’re going to attempt to do it, but not do a good job at it, so we’re not going to know how the software is going to perform under a real load, because we never put it under the load because we did not have the means/mechanisms to do it”. Also, when we do find issues how do we feed that back to our development organization capturing ways in which software was unsatisfactory and what we would like to see development change, so that they can cycle back again. From requirements concept to installation – how do we get line of sight that what we are producing as output of this lab is conforming to the original requirements that came in. Historically, development hated requirements traceability. We need some means of determining what we are delivering meets what we were asked to deliver.


IBM Jazz Announcements and Virtual Lab Automation

June 8, 2008

Last week IBM made some announcements around their new Jazz platform for collaborative software development. Virtual Lab Automation players Surgient and VMLogix have been listed among the partners who are currently building solutions to integrate with IBM Rational Quality Manager.

Today, VMLogix is the only available virtual lab automation solution that has ready and IBM certified solutions with leading IBM build and test management tools – IBM Rational BuildForge and ClearQuest. You can read more about the VMLogix integrations.

– Srihari Palangala

Update (6/29) – Thanks to one of the readers of the blog who pointed out re: Surgient’s support of IBM Rational BuildForge.


Bookmark and Share