The document provides an overview of Abiquo, a cloud management software company. It discusses Abiquo's vision of enabling portability, interoperability, and federation across cloud platforms through open standards. Abiquo aims to allow both cloud providers and users to avoid vendor lock-in and have flexibility in their choice of infrastructure and ability to move workloads. The Abiquo solution is presented as a revolutionary cloud management platform that supports multiple hypervisors and achieves portability through the use of open standards like OVF and interoperability through its APIs.

1. ABIQUO TECHNICAL OVERVIEW
Cloud Standards
Enabling Interoperability and
Package Delivery
June 21, 2010
Cloud Expo Europe
Hilton Prague, Czech Republic

2. Introduction
Revolutionary Cloud Management
Diego Parrilla
VP Product Management
diego.parrilla@abiquo.com
www.abiquo.com
twitter.com/abiquo

3. Agenda
Revolutionary Cloud Management
1. About Abiquo
2. The Cloud Dream and Virtualization 1.0
3. Vendor Lock-in
4. Open Clouds are Standards Based
5. The Abiquo Vision
6. The Abiquo Solution
7. Portability via OVF
8. Interoperability: OVF and APIs
9. Conclusions
10. Q&A

4. Revolutionary Cloud Management
About Abiquo

5. About Abiquo
Revolutionary Cloud Management
 Our Company
 Founded 2006 in Barcelona by Diego Mariño and Xavier
Fernández
 Our Team
 Pete Malcolm, CEO
 Trevor Chamberlain, VP Business Development
 Xavier Fernández, Founder and VP Engineering
 Helena Torras, VP Operations
 Diego Parrilla, VP Product Management
 Steve Soechtig, VP Global Sales
 Nick Wetton, VP Regional Sales

6. About Abiquo
Revolutionary Cloud Management
 Our Technology
 Abiquo product development commenced early 2008
 First open source pre-release April 2009
 Over 15,000 downloads
 Formal 1.0.0 release February 2010
 Our Mission
Become a leading vendor of groundbreaking virtualization
management solutions, liberating both IT organizations and
the users they serve, while increasing business agility,
efficiency, and reducing cost.

7. Revolutionary Cloud Management
The Cloud Dream
and
Virtualization 1.0

8. The Cloud Dream
Revolutionary Cloud Management
Cloud Computing is the ideal solution for users & providers
 Cloud Users
 No upfront commitment, no CAPEX, only OPEX
 Pay-per-use, no long-term contracts
 Dynamic Scaling
 Physical location irrelevant
 Cloud Provider
 Higher ratio of servers per Sys Admin
 Higher efficiency
 Built on top of commoditized hardware

9. Virtualization 1.0 Issues
Revolutionary Cloud Management
The Cloud created additional problems, including:
 High Provisioning Effort = IT Bottleneck
 Poor Capacity Planning and Utilization
 Vendor Lock-In
 Low-efficiency Virtual Server Sprawl
 Security and Compliance Concerns

10. The Cloud Nightmare
Revolutionary Cloud Management
Examples of common problems experienced by Users and Providers:
“Our Cloud Provider SLA is not meeting our needs, but there is
no easy way to move our solution to another provider.”
“We had all of our project data stored virtually, but the hosting
provider corrupted it. How can we trust the cloud for future
projects?”
“I developed my solution on top of an existing platform, which
was sold to another company. Now I have 30 days to remove
all aspects of my solution and have no control over it.”
“There are new players in the Cloud Provider arena that we
might want to try, but it is impossible to transfer our servers and
data.”

11. Revolutionary Cloud Management
Vendor Lock-In

12. What is Vendor Lock-in?
Revolutionary Cloud Management
 Reliant on one vendor and cannot switch to another vendor
without substantial costs
 No alternative if the vendor fails or the product is no longer
viable
 Cloud Users risk being completely reliant on one vendor
 Cloud Providers are limited to customers that only want to use
the vendor they support
“#2 Obstacle for Adoption and Growth of Cloud Computing:
The degree of difficulty associated with moving an application from one
cloud provider to another, to your datacenter, or simply take your data
out of the cloud.”
Above the Clouds: A Berkeley View of Cloud Computing

13. Vendor Lock-in
Revolutionary Cloud Management
Impacts on the Cloud User:
 Lock-in prevents three crucial benefits of cloud computing:
Portability
Interoperability
Federation

14. Vendor Lock-in
Revolutionary Cloud Management
Impacts on the Cloud Vendor:
 Vendor lock-in does not allow you to change any of your
providers during the Platform‟s lifetime.
 A Cloud Platform is composed of:
 Servers
 Storage Systems
 Networking devices
 Hypervisors
 Monitoring tools
 Cloud Management Software
 The lifespan of a Cloud Platform can last many years.

15. Revolutionary Cloud Management
Open Clouds are
Standards-Based

16. The Open Cloud Manifesto
Revolutionary Cloud Management
Principles of an Open Cloud
1. Open collaboration
2. No platform vendor lock-in
3. Use and adopt existing standards
4. Promote innovation
5. Customer-driven
6. Collaboration to prevent open-source effort overlap

17. Open Clouds
Revolutionary Cloud Management
Required Features
 Portability: move a cloud solution (apps, data, network,
config)to other Cloud Platform than the one that it was
created
 Interoperability: use the services of more than one Cloud
Platform
 Federation: Cloud Platforms can talk to each
other to offer interoperability or transparency

18. Revolutionary Cloud Management
The Abiquo Vision

19. The Abiquo Vision
Revolutionary Cloud Management

20. The Abiquo Vision
Revolutionary Cloud Management
Cloud Providers should be able to:
 Choose their infrastructure, including:
 Servers
 Hypervisors
 Open-source and proprietary solutions
 Storage Array Networks
 Networking devices
 Mix different technologies and make them interoperable
 Provide elasticity

21. The Abiquo Vision
Revolutionary Cloud Management
Cloud Users should be able to:
 Import existing Standard (gold) images
 Use any infrastructure of their choice
 Manage Global Resources from one dashboard
 Manage the platform using different types of APIs
 Portability
 Interoperability
 Federation

22. Revolutionary Cloud Management
The Abiquo Solution

23. The Abiquo Solution
Revolutionary Cloud Management
Revolutionary Cloud Management
 Vendor independent
 Supports ESX, ESXi, Xen, Xen Server, KVM, Hyper-V
 Virtual-to-virtual (V2V) conversion between all hypervisors
 Enterprise class
 Standards-based
 Policy-driven
 Multi-tenancy delegated control
 Manages private and public clouds

24. The Abiquo Solution
Revolutionary Cloud Management
Background Information
 Developed in Java, C (Cloud Nodes) and Flex (interface)
 MySQL as the database backend
 Service Oriented Architecture (SOA)
 Abiquo Enterprise Edition codebase extends the Abiquo
Community Edition
 Standards:
 OVF
 WS-Management / CIM resources
 API based on vCloud 0.9 (beta)
 Stateless architecture (horizontal scalability)

25. The Abiquo Solution
Revolutionary Cloud Management
Use of standards effectively overcomes lock-in
and achieves:
Portability Federation
Interoperability

26. Revolutionary Cloud Management
Portability via OVF

27. Portability via OVF
Revolutionary Cloud Management
Open Virtualization Format (OVF) enables people to move a cloud
solution (apps, data, network, config) from one Cloud Platform to
another.
 Packaging and distributing virtual appliances
 Software to be run in virtual machines
 Not tied to any particular hypervisor or processor architecture
 An OVF Package contains one or more virtual systems
 Can be deployed to several virtual machines
 Supported by DMTF
OVF is the only open standard getting traction in the industry and
community

28. OVF Package
Revolutionary Cloud Management
An OVF Package consists of:
 OVF descriptor (.ovf)
 Disk images
 Additional resources (ISO files, XML files, icons)
 Manifest files (.mf)
 Certificates (.cert)
Debian-5-lenny-32bit.ovf
Debian-5-lenny-32bit-streamOptimized.vmdk
Debian_logo.png
Debian-5-lenny-32bit.mf

29. Disk Formats
Revolutionary Cloud Management
OVF does not require any specific disk format
 VMDK Stream Optimized is the preferred
 Every disk should have a static URI which identifies the format in the OVF
descriptor
<DiskSection>
<Info>List of the virtual disks used in the package</Info>
<Disk
ovf:capacity="1073741824"
ovf:diskId="vmdisk1"
ovf:fileRef="file1"
ovf:format="http://www.vmware.com/technical-
resources/interfaces/vmdk_access.html#streamOptimized"/>
</DiskSection>

30. OVF Descriptor
Revolutionary Cloud Management
 XML document
 Stores product details, virtual hardware requirements, licensing and others
 Extensible: metadata can be added with new ‘Section’ nodes.
Envelope
References (One)
File
File
DiskSection (Zero or One)
NetworkSection (Zero or One)
SomeSection (Extension)
VirtualSystem or VirtualSystemCollection

31. Virtual System
Revolutionary Cloud Management
 Description of the content of a Virtual Machine
 Stores product details, virtual hardware requirements, licensing and others
 Extensible: metadata can be added with new ‘Section’ nodes.
VirtualSystem
VirtualHardwareSection (One)
System
Item (N elements)
ProductSection
OperatingSystemSection

32. OVF Custom Extensions
Revolutionary Cloud Management
OVF requires custom extensions to do the following:
 Define multiple networks
 Set up firewalls
 Set up load balancers
 Define startup process

33. OVF Custom Extensions
Revolutionary Cloud Management
OVF was designed for static deployments, not Cloud Computing
 Does not work for elastic, self-configuring environments.
 Focused in the Virtual Machine, not in the Virtual
Datacenter.
 Ambiguous about disk formats.
 No SLA or QoS attributes.
Extensions and an API are necessary to manage OVF in the Cloud

34. OVF Conformance Levels
Revolutionary Cloud Management
Three levels of conformance (1 is the highest):
1. OVF descriptor uses only sections and elements and attributes that are
defined in this specification.
2. OVF descriptor uses custom sections or elements or attributes that are
not defined in this specification, and all such extensions are optional.
3. OVF descriptor uses custom sections or elements that are not defined
in this specification and at least one such extension is required
“The use of conformance level 3 limits portability
and should be avoided if at all possible”
Open Virtualization Format Specification DSP0243 V1.1.0

35. Revolutionary Cloud Management
Achieve Interoperability
with
OVF and APIs

36. OVF and Interoperability
Revolutionary Cloud Management
 OVF is not inherently
interoperable
 APIs enable
interoperability for
OVF
 There are several
API standards

37. Cloud APIs
Revolutionary Cloud Management
Far from a homogenous scenario:
Abiquo published Cloud Service API based on vCloud 0.9
(beta) in Abiquo v1.6
EC2 API is the de facto standard of the industry. IP belongs to
Amazon. Rumors of changing to an open license since end 2009.
vCloud API used to manage VMware„s virtualized infrastructures.
Fastest growing API.
OCCI API covers the provisioning, monitoring and definition of
Cloud Infrastructure services. Lacks traction in the industry.
Cloud API is an opensource initiative from SUN, handicapped by
Oracle‟s new strategy. An inspiration for other initiatives.
TCloud is an initiative from Telefónica. vCloud + Telefonica
extensions. They were (are?) one of the biggest supporters of OCCI

38. Why vCloud?
Revolutionary Cloud Management
Choosing the right cloud API:
 EC2 semantics and model do not meet our needs. Would lose
70% of features.
 Sun Public Cloud was promising and we developed a
prototype, but had to abandon it due to the changes at Sun.
 OCCI has a lot of great features, but it lacks of traction in the
industry.
 vCloud has staying power in the industry, some customers
prefer vCloud to OCCI or EC2.
 vCloud semantics and model are a good fit for our platform.

39. vCloud Properties
Revolutionary Cloud Management
 Based on REST principles
 Basic HTTP Authentication
 A Cloud is composed of
 Organizations
 Virtual DataCenters
 Catalogs
 Virtual Apps (vApps)
 Use Case Categories:
 Browsing
 Provisioning
 Self-Service Datacenter Operations

40. Abiquo vCloud Browse Request
Revolutionary Cloud Management
Browse the information of an organization
GET http://vcloud.abiquolabs.com/org/69
Content-Type: application/vnd.vmware.vcloud.org+xml
200 OK
<?xml version="1.0" encoding="UTF-8"?>
<Org href="http://vcloud.abiquolabs.com/org/69" name="Abiquo"
xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8 organization.xsd"
xmlns="http://www.vmware.com/vcloud/v0.8"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Link rel="down" href="http://vcloud.abiquolabs.com/catalog/1"
type="application/vnd.vmware.vcloud.catalog+xml" name="Apps Library"/>
<Link rel="down" href="http://vcloud.abiquolabs.com/vdc/1"
type="application/vnd.vmware.vcloud.vdc+xml" name="HyperV-VDC"/>
<Link rel="down" href="http://vcloud.abiquolabs.com/vdc/2"
type="application/vnd.vmware.vcloud.vdc+xml" name="KVM-VDC"/>
<Link rel="down" href="http://vcloud.abiquolabs.com/network/1"
type="application/vnd.vmware.vcloud.network+xml" name="Public Network"/>
<Description>Abiquo Default Organization</Description>
</Org>
Abiquo vCloud implementation will run on top of any hypervisor

41. vCloud and OVF
Revolutionary Cloud Management
vCloud gives ‘dynamism’ to OVF
 OVF is the unit of distribution for vApps and vApp Templates.
 vCloud API defines the façade to the instantiation mechanism of
the platform that transforms the OVF package into a deployable
vApp.
 Deployable OVF packages are not Level 1 Conformant.
 OVF is too generic.
 Need to modify the OFV package.
 Extra sections need to be added before passing the package
to the platform.

42. vCloud Network Section
Revolutionary Cloud Management
Example from the vCloud specification document 0.8
...
<NetworkSection>
<Info>The list of logical networks</ovf:Info>
<Network ovf:name="Network 1"/>
</NetworkSection>
<NetworkConfigSection>
<NetworkConfig name="Network 1">
<Features>
<Dhcp>true</Dhcp>
<Nat></Nat>
<Firewall></Firewall>
</Features>
</NetworkConfig>
</NetworkConfigSection>
<NetworkConnectionSection>
<NetworkConnection name="Network 1">
<IPAddress>192.168.1.100</IPAddress>
</NetworkConnection>
</NetworkConnectionSection>
...

43. vApp Templates Instantiation
Revolutionary Cloud Management
vApp is resolved by being bound to a provider specific platform:
 Parameters mapped to the core metadata of the Envelope must
be specified to resolve the template.
 Two-step process specific to the cloud platform:
1. „Annotate‟ the vApp template
2. Construct and send the Instantiation Parameters
 Then the vApp template instance can be deployed in the Virtual
Data center.
 Deployment means „reservation‟ of the resources.
 Finally, the user can start the vApp deployed.

44. vApp Deployment Workflow
Revolutionary Cloud Management
POST http://vcloud.abiquolabs.com/vdc/69/action/instantiateVAppTemplate
POST http://vcloud.abiquolabs.com/vapp/1/action/deploy
http://vcloud.abiquolabs.com/vapp/1/power/action/powerOn
Example adapted from the vCloud specification document
Content-Type: application/vnd.vmware.vcloud.instantiateVAppTemplateParams+xml
202 Accepted
<Task version="1.0" encoding="UTF-8"?>
<?xml
POST http://vcloud.abiquolabs.com/vdc/69/action/annotate
<InstantiateVAppTemplateParams name="Test App" xmlns="http://www.vmware.com/vcloud/v0.8"
href="http://vcloud.abiquolabs.com/task/32"
href="http://vcloud.abiquolabs.com/task/31"
Content-type: application/vnd.vmware.vcloud.annotate+xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
startTime=""
xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8
expiryTime="" encoding="UTF-8"?>
http://vcloud.example.com/ns/vcloud.xsd">
<?xml version="1.0"
status="running"
<VAppTemplate href=”http://vcloud.abiquolabs.com/vAppTemplate/1” />
<Annotate xmlns="http://www.vmware.com/vcloud/v0.8"
xsi:schemaLocation="http://vcloud.example.com/ns/vcloud.xsd
xsi:schemaLocation="http://vcloud.example.com/ns/vcloud.xsd"
<InstantiationParams xmlns:vmw="http://www.vmware.com/schema/ovf">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<NetworkConfigSection>
xmlns="http://www.vmware.com/vcloud/v0.8"
xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8
<NetworkConfig name="Network 1">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
http://vcloud.example.com/ns/vcloud.xsd">
<Features>
<Link rel="task:cancel" href="http://vcloud.abiquolabs.com/task/31/action/cancel"/>
href="http://vcloud.abiquolabs.com/task/32/action/cancel"/>
<VAppTemplate href="https://vcloud.abiquolabs.com/vAppTemplate/1"/>
<vmw:FenceMode>allowInOut</vmw:FenceMode>
<Owner href="http://vcloud.abiquolabs.com/vapp/1"
</Annotate> <vmw:Dhcp>true<vmw:Dhcp>
type="application/vnd.vmware.vcloud.vApp+xml" name="Test App"/>
</Features>
</Task> OK
200 <NetworkAssociation href="http://vcloud.abiquolabs.com/network/1">
</NetworkConfig>
<?xml version="1.0" encoding="UTF-8"?>
</NetworkConfigSection>
<Envelope ... >
</InstantiationParams>
...
</InstantiateVAppTemplateParams>
<NetworkSection>
200 OK ...
<?xml version="1.0" encoding="UTF-8"?>
<Network>
<VApp name="Test App" status="1"
...
href="http://vcloud.abiquolabs.com/vapp/1" xmlns="http://www.vmware.com/vcloud/v0.8"
</Network>
xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"
<vmw:ProvidedNetwork href="https://vcloud.example.com/network/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
type="application/vnd.vmware.vcloud.network+xml" name="Network 1"/>
xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8
</NetworkSection>
http://vcloud.example.com/ns/vcloud.xsd">
...
<Link rel="up" href=http://vcloud.abiquolabs.com/vdc/69 type="application/vnd.vmware.vcloud.vdc+xml”/>
</Vapp>
</Envelope>

45. Revolutionary Cloud Management
Conclusions

46. Conclusions
Revolutionary Cloud Management
Still in early stage of the evolution of standards
 OVF is too „Virtual Machine oriented‟.
 OVF should evolve to cover more custom extensions made by
cloud providers (OVF 2.0?).
 vCloud seems to be the future standard for Cloud Interoperability,
but has yet to address several challenges.
 vCloud delegates a lot of capabilities to the underlying platform. It
should explicitly define features of these platforms.
 vCloud HTTP basic security should be an option among more
secure and stronger authentication mechanisms.

47. Revolutionary Cloud Management
Q&A