The idea of governance is to provide command, control, discovery, and monitoring, as well as design and development support for services that make up your architecture, including on-premise and in the cloud, and either leveraging virtualization.  Most people get that, but in some cases they don't want to get that.  Perhaps there is a larger opportunity here for both the virtualization technology vendors, and those that leverage this technology.

What's so limiting about governance is the fact that you're given an empty registry/repository and then are asked to fill it up with information about virtualized services that you create or, in most cases, expose.  From there it's a constant struggle to keep that repository up-to-date, and thus make sure the virtualized architecture is governed properly.  Indeed, we've been here before with metadata repositories that don't seem to get the maintenance they need.  Perhaps we are doomed to make the same mistake with governance and virtualization, unless we come up with something clever.

We've dealt with the notion of a shared registry/repository for some time now, delivered as a service.  Instead of leveraging a local repository that just tracks services within your enterprises, you link to a shared repository that already contains thousands of services from thousands of providers, with design and governance information, and it's just a matter of picking what you need and then filling in the gaps with your own virtualized services.

This repository would provide more than just WSDL, but a complete design-time and runtime governance system delivered out of the virtualized resource.  The core notion would be to provide access and control for services, virtualized or not, which you and others are able to leverage.  That would provide a complete governance solution, design-time and runtime, for all virtualized services. 

Also, since this is a cloud thing as well, typically private clouds, we'll need to provide "new value." The core value that I see, beyond the use of virtualized services you don't develop or maintain, is the fact that there will be design patterns already defined for you around specific categories of services, or pre-built policies around the operation of those services.  This is shared: As the services are revised, so are the design artifacts and the policies, both shared and private.  In short, you're taking advantage of the community aspect of private cloud governance delivered as a service to do most of the work for you...1,000 heads are better than one.

So, what do you need to do to ensure that governance is part of your virtualization strategy? First, understand that governance, specifically services governance, is something that you need to consider throughout the architecture, it's not something you bolt on later.   Second, consider service design along with service governance, services should be designed to be governed.    Finally, consider how security meshes with all of this. Like governance, security should be systemic and bound within the architecture, virtualized or not.