A VDC (Virtual Data Center) defines an assignment of one or several groups to a pool of physical resources. This pool of Physical Resources consists of resources from one or several Clusters that could belong to different Zones or public external clouds for hybrid cloud computing. You can read more about OpenNebula’s approach to VDCs and the cloud from the perspective of different user roles in the Understanding OpenNebula guide.
The Default VDC¶
There is a special
default VDC created during the installation that allows the use of
ALL the physical resources.
users group belongs to this VDC, and any new group is automatically added to the
default VDC. You can modify the VDC physical resources, even remove all of them, but it can’t be deleted.
Before adding a new group to a specific VDC, you may want to remove it from the
default one, since it allows the use of
ALL the physical resources.
Adding and Deleting VDCs¶
Your can use the
onevdc command line tool to manage VDCs in OpenNebula.
To create new VDCs:
$ onevdc list ID NAME 0 default $ onevdc create "high-performance" ID: 100
The new VDC has ID 100 to differentiate the default VDC from the user-defined ones.
Adding Groups to VDCs¶
By default a group doesn’t belong to any VDC, so users won’t be entitled to use any resource until explicitly added to one.
To add groups to a VDC:
$ onevdc addgroup <vdc_id> <group_id>
Adding Physical Resources to VDCs¶
Physical resources (hosts, virtual networks, and datastores) can be added to the VDC. Internally, the VDC will create ACL Rules that will allow the VDC groups to use this pool of resources.
Typically, you will want to add Clusters to the VDC. For instance, Cluster 7 from Zone 0:
$ onevdc addcluster <vdc_id > 0 7
But you can also add individual hosts, virtual networks, and datastores:
$ onevdc addhost <vdc_id> 0 3 $ onevdc addvnet <vdc_id> 0 9 $ onevdc adddatastore <vdc_id> 0 102
The special id
ALL can be used to add all clusters/hosts/vnets/datastores from the given zone:
$ onevdc addcluser <group_id> 0 ALL
To remove physical resources from the VDC, use the symmetric operations
When you assign physical resources to a VDC, users in that VDC’s groups will be able to use the Datastores and Virtual Networks. The scheduler will also deploy VMs from that group to any of the VDC Hosts.
If you are familiar with ACL rules, you can take a look at the rules that are created with
oneacl list. These rules are automatically added, and should not be manually edited. They will be removed by the
onevdc del* commands. The default permissions for these rules can be configured into oned.conf
The VDC management offers plenty of flexibility to suit many different scenarios. This section lists a few of them to help to visualize the possibilities of your OpenNebula infrastructure.
For example, let’s say Web Development, Human Resources, and Big Data Analysis as business units represented by Groups in a private OpenNebula cloud, with resources allocated from your zones and public clouds in order to create three different VDCs.
- VDC BLUE: VDC that allocates resources from DC_West_Coast + Cloudbursting to Web Development
- VDC RED: VDC that allocates resources from DC_West_Coast + DC_Europe + Cloudbursting to Human Resources
- VDC GREEN: VDC that allocates resources from DC_West_Coast + DC_Europe to Big Data Analysis
If you plan to have a small infrastructure, the VDC management may seem like an unnecessary extra step to assign physical resources to each Group. But having an independent VDC object allows it to have more than one Group, and at the same time a Group can be part of more than one VDC.
In practical terms, this means that once you organize your Users into Groups, and then your physical resources into VDCs, you can easily assign more or less resources to those Groups.
Using the previous scenario as an example, the Cloud Admin can add the Group Web Development to the VDCs RED and GREEN if their workload increases, and then remove it again a few days later.
A VDC can have more than one physical resource of each type (Cluster, Hosts, VNets, Datastores), and a physical resource can be in more than one VDC. In contrast a Host can be part of only one Cluster. This means that you can decide to create a VDC that encompasses resources that may not be part of the same physical Cluster.
For example, a VDC called ‘high-performance’ may contain Hosts from two incompatible Clusters, let’s say ‘kvm-ceph’ and ‘kvm-qcow2’. These Hosts may be part of the same VDC, but from the deployment point of view, the important factor is their Cluster. The scheduler will decide the deployment target based on each Host’s Cluster, and this guarantees that the VMs are always deployed in a compatible Host.
Partition a Cluster¶
Since a VDC can contain individual Hosts, VNets and Datastores, you can use VDCs to partition a Cluster into “sub-clusters” that contain a few Hosts.
Following the previous example, you may have a big “kvm-ceph” Cluster. A VDC with one or two Hosts can be created to isolate a small portion of the Cluster. In this case, remember to add the necessary Datastores and VNets to the VDC, otherwise the Users won’t be able to instantiate the VM Templates.