Analysis of VMware openstack Access Solution

Statement:

You are welcome to forward this blog, but please keep the original author information!

Blog: http://blog.csdn.net/halcyonbaby

It is a pleasure to study, study, and summarize the content!

Analysis of VMware openstack Access Solution

In openstack, the Nova project currently has two vmware-related drivers (esxdriver, vcdriver ).
From the name, we can clearly see that one is the driver involved in ESX, and the other is the driver involved in vcenter.
Esxdriver was first contributed by Citrix, and vcdriver was provided by VMware.
Esxdriver connects ESX as the hypervisor to openstack, and vcdriver connects the vcenter cluster as the hypervisor to openstack.
Esxdriver causes loss of some VMware Cluster Features. vcdriver solves these failures and introduces some new problems (to be discussed later ).
Vcdriver more reflects the complementarity between VMware and openstack. On the one hand, there is a large inventory of VMware, and many enterprise applications are not developed according to the idea of the cloud; on the other hand, new applications are mostly developed on the cloud. The two complement each other to meet user needs, which also meets the current consensus of various vendors on hybrid cloud trends.

Esxdriver

Esxdriver is slightly different from other hypervisor access methods.
It has the following Disadvantages:
Unlike KVM, the VM runs on esxi and is not the node where Nova-compute is located.
Esxdriver restrictions. Each Nova-compute service only supports one esxi host.
Advanced features such as DRS on vcenter are not supported.

Vcdriver

• This topic describes how to access vcdriver. In this way, the cluster is connected as a hypervisor, which naturally has ha, DRS, and vmotion capabilities.
  Currently, each compute node supports only one hypervisor. Grizzly each compute Service supports only one vcenter cluster. This restriction has been removed by Havana.
  Each cluster in vcdriver must have a datastore for configuration and use.
  As a hypervisor, cluster also brings about the problem of cross-esxi nodes. Specifically, the CPU and memory resources presented as a whole by the hypervisor are abundant, however, when you create a virtual machine, you can find that the resources of any node do not meet the needs of the virtual machine.
  
• Access Illustration
  
• Access Method
  The configuration of the Nova. conf file. (Use vcdriver to connect the C1 cluster)
  

[Default] compute_driver = vmwareapi. vmwarevcdriver [VMware] host_password = Huawei-123 host_username = [email protected] host_ip = login # datastore_regex = Not Defined cluster_name = C1 # multiple clusters can be configured

Explanation:
Compute_driver specifies the driver used.
Host_password/username/IP is used to connect to the vcenter server. Cluseter_name specifies the managed VMware cluster. You can specify multiple clusters from Havana.
Datastore_regex datastore configuration format, which specifies the datastore that can be used.

• Image usage
  The figure above shows that the image is downloaded from glance to VMware's datastore.
  The process is to call the glance API on the compute node to download the image and then use the VMware API to write the image to datastore.
  Such a transmission process will undoubtedly consume compute resources and is inefficient.
  The process of creating a volume based on an image in cinder is similar to this. I will not go into details here.
  

#virt/vmwareapi/vmware_images.pydef fetch_image(context, image, instance, **kwargs):    """Download image from the glance image server."""    LOG.debug(_("Downloading image %s from glance image server") % image,              instance=instance)    (image_service, image_id) = glance.get_remote_image_service(context, image)    metadata = image_service.show(context, image_id)    file_size = int(metadata[‘size‘])    read_iter = image_service.download(context, image_id)    read_file_handle = read_write_util.GlanceFileRead(read_iter)    write_file_handle = read_write_util.VMwareHTTPWriteFile(                                kwargs.get("host"),                                kwargs.get("data_center_name"),                                kwargs.get("datastore_name"),                                kwargs.get("cookies"),                                kwargs.get("file_path"),                                file_size)    start_transfer(context, read_file_handle, file_size,                   write_file_handle=write_file_handle)    LOG.debug(_("Downloaded image %s from glance image server") % image,              instance=instance)

The ideal way is to use datastore as the glance backend, so you do not need to download images when creating virtual machines.
At present, the Community already has a similar BP idea.