What is the correct procedure to ingest esxi host in Vipr 2.2?

Hi Ritu,

See answers below:

1. how to ingest host in vipr? [JS] You ingest storage volumes, not hosts. If the volume is exported to a host, you ingest volumes by host.

2. What needs to be ingested first? boot lun or host? [JS] There is no restriction in the order

3. Does discover/hosts api discovers esxi hosts? Or just Windows and linux hosts? [JS] From an ingestion perspective, there is no difference between host OSs. The same API calls work for all types of OSs.

4. Do we need to create a host object to ingest the host and thn register initiators by calling POST? If yes, thn does this also create initiator export in vipr? (as storage group already exists with boot lun visible) [JS] Yes, the host needs to be defined in ViPR so its volumes can be ingested. The export group (mapping/masking information within ViPR) is created when the ingestion is executed.

Please read this document for more details: ViPR 2.2 - Ingest Unmanaged Block Volumes into ViPR and let me know if you have any other questions.

Regards

Thanks much Javier!! I have a few more questions:

1. The doc says:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

If an unmanaged volume is present in one or more storage groups on the array, but has not been exported to any host, ViPR will skip this volume during ingestion. To successfully ingest this volume, do one of the following:

• Mount the volume on a host, then call the service Ingest Exported Unmanaged Volumes.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

What does it mean by Mount the volume on a host? Volume is already part of host storage group on physical array.

I see following description in document: (I have ESXi hosts and trying to do using API not vipr GUI)

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

To mount the volumes on a host:

• For Linux hosts use: Service Catalog > View Catalog > Block Service for Linux > Mount Existing Volume on Linux.
• For Windows hosts use: Service Catalog > View Catalog > Block Service for Windows > Mount Volume on Windows.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

2. When we ingest the volumes associated with a particular host into vipr, would their hlu ids remain the same or change?

   I did read following in doc:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

• If you ingest a volume, the Host LUN ID for the volume is not ingested from the export group on the array. To synchronize the Host LUN ID for a volume, you can unexport then export the volume. The Host LUN ID will then display properly in the ViPR user interface.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Does this apply to all the volumes associated with a host? Suppose there are three volumes: bootlun(with hlu 0), datalun1 (with hlu 1) and datalun2 (with hlu 2) on storage array. What will happen in this case?

3. Will we be able to remove (deactivate) the host completely using VIPR once it is manageable?

4. Do we need to create cluster object in vipr before host object creation and exported volume ingestion? (if doesnt already exists) OR it will get created during the exported volume ingestion?

Mostly it seems like host object cannot be created unless we already have a cluster object.

Regards,

Ritu

Hi again, Ritu

1.- You can have a LUN in a storage group (SG) but not have any hosts/initiators on that SG. That's the case the document is talking about. In that case, you can either ingest the volume using the "Ingest Unexported Unmanaged Volumes" and then export it to a host using ViPR or manually add host/initiators to the SG and use "Discover Unmanaged Volumes" again (or even take the volume out of the SG).

2.- The HLUs in the array won't change, but ViPR's HLU info might not be synchronized with what you see in the array. If you want the info to be synch'd, unexport and then export as suggested.

3.- Once the host is discovered in ViPR and you have ingested its volumes, you can manage all its storage from ViPR. That includes, adding, expanding and removing volumes. Does that answer this question?

Regards

Thank you Javier.

On point 3  - In my scenario, I complete following steps:

1.Host exists in vcenter with a boot volume. (with zoning and host storage group)

2. Discover the host using  - POST/compute/hosts/{id}/discover - will work with ESXi hosts?

2. Create a vipr cluster object.

3. Create a vipr host object with complete FQDN

4. Regsiter host initiators with vipr host object

5. List the UnManagedVolumes exposed to a Host. - GET /compute/hosts/{id}/unmanaged-volumes

6. Ingest exported volume using -  POST /vdc/unmanaged/volumes/ingest-exported

Now, would I be able to remove the host,boot volume and unregister the initiators associated with the host, using api - POST/compute/hosts/{id}/deactivate ? [As this host was not initially provisioned using VIPR but just added to it for managing]

In my understanding, when a host is provisioned using VIPR, on calling above api (POST/compute/hosts/{id}/deactivate) it unassociates the service profile, removes the boot volume and also unregisters the initiators.

Another question: Do we need to create cluster object in vipr before host object creation and exported volume ingestion? (if doesnt already exists) OR it will get created during the exported volume ingestion?

Mostly it seems like host object cannot be created unless we already have a cluster object.

Regards,

Ritu

Hi Ritu,

If you host is already in a vCenter and has ESX installed, you can discover the vCenter directly and that will populate any clusters and hosts managed by that vCenter. It will also discover any host initiators.

You can then run the discover unmanaged volumes followed by ingest exported volumes to ingest the boot volume if desired. Steps 5 and 6 look good.

Yes, you should be able to remove the host completely using POST/compute/hosts/{id}/deactivate, including detaching the volumes if the detach_storage parameter is specified.

Regards

Wow! Good to know. Thanks. That means VIPR will discover the hosts and clusters and create objects for them. Right?

Thank you so much for answering all my questions. I really appreciate it.

Regards,

Ritu

Hi Javier,

Is documentation on vipr 2.3 APIs available on emc webiste?

Regards,

Ritu

Not yet, ViPR Controller 2.3 is not GA yet. GA is expected at the beginning of Q3.

Regards

Hi Javier,

How do we install esxi license on the host provisioned using vipr. Currently vipr doesnt seem to accept the license key information. Is it planned to add this functionality in vipr 2.4? Or add license manually one host is provisioned.

Regards,

Ritu