Browse Prior Art Database

System and Method for auto-detect logical template in hybrid cloud Disclosure Number: IPCOM000244636D
Publication Date: 2016-Jan-04
Document File: 4 page(s) / 97K

Publishing Venue

The Prior Art Database


This disclosure propose a new method of detecting logic template in a hybrid cloud dynamically. The logical template detector will collect all of the metrics of the templates in hybrid cloud periodically and the end user only need to define some tags to define the required logical template. When end user want to deploy a new cloud host with a logical template, the scheduler will help select the best target host based on the logical template.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 4

System and Method for auto

System and Method for auto-

--detect logical template in hybrid cloud

detect logical template in hybrid cloud



.. Background Background



In a hybrid cloud (including physical machines, virtual machines and linux containers) environment such as OpenStack, CloudStack, Eucalyptus etc,the template means the image that will be used to create the container, the VM or the physical machine, it is just a standalone template.The problem for such kind of standalone template is that each template can only be used by the specified hypervisor or bare metal machine, such as a KVM template can be only used by KVM hypervisor, this caused some trouble for the cloud operator as the template was limited to a specified kind of hypervisor or bare metal machine, and the specified kind of hypervisor or bare metal machine might not have enough resource to hold the application but other hypervisor might still have resources with different template.

The Logical Template is a template that can be usedto provision machines in multiple Groups of Hosts,and it is associated with multiple standalone templates in different Groups of Hosts. This can make sure cloud operator has more opportunity to get cloud resources and do live migration between in different groups.

For above chart, the [*]T[i] means the standalone template on each group. The customer can create Logical Templates manually based on standalone templates:
a) VM Logical Template: LT1 = { C1T2@Pool1,V1T1@Pool3,V2T1@Pool4

b) VM Logical Template: LT2 = { V2T2@Pool4}

c) PM Logical Template: LT3 = { P1T1@Pool5}

d) PM Logical Template: LT4 = { P2T2@Pool6, X1T1@Pool7}

The "GROUP1" Group can access LT1.


Page 02 of 4

The "GROUP2" Group can access LT2, LT2 The "GROUP3" Group can access LT3, LT4.
The "GROUP4" Group can access LT4

The current "logical template" require user to make sure all standalone template must be isomorphic, e.g they have same OS. It is difficult to set "logical template" manually of there are hundreds of templates in a hybrid cloud, because the hybrid normally contain various cloud system, each cloud system has its own template, and may have many templates. There are some drawbacks for current "logical template" solutions:

#1. User cannot manually pick up the isomorphic template as 'logical template', it's hard to identify them by name, and sometime the same name template may have different OS as user may name it by mistake.

#2. It's hard to let user maintain the member of each logical template, which image implement belong to one logical template, which standalone template does not belong to it. Once the template are added/removed from the cloud system, or there are hypervisor added or removed from the hybrid cloud, user may forget to manually update the member of logical template. And in hybrid cloud, it is one common case that the standalone template is dynamic changed, and may be added/removed.

#3. Current solution

            1 does not su...