EGI-InSPIRE RI EGI-InSPIRE EGI-InSPIRE RI VM Management Chair: Alexander Papaspyrou 2/25/2016 1

EGI-InSPIRE RI

EGI-InSPIRE RI Questions are there standards we should be using? are there best practices we should adopt? what software is available at the market? what is the maturity of the software? what is the availability of the software? what are the priorities? what are the gaps, issues, and concerns? what work is needed to remove these?

EGI-InSPIRE RI Discussion Items specify bandwidth for a VM (for data- intensive application) expiry and revocation of images (probably out of scope) trust/endorsement/approval policy and model (certainly out of scope) authentication mechanisms (preferably X.509v3 or VOMS proxy) bulk operations

EGI-InSPIRE RI Grid Appliances vs. Community Appliances Differences: grid appl is the traditional middleware stack packaged as VM community provided VMs Differences from VM management? In general no; maybe on regularity of updates

EGI-InSPIRE RI Requirements *** Parameters to instantiate a single VM Bandwidth, network type, memory, disk space, IP address, # cores, CPU, firewall rules, running time * SLA: requested uptime, exclusive usage of physical machine ** Instantiate n VMs as cluster Shared disk space, connectivity Dependencies between VMs e.g. deploy one VM implies deploying other depending VMs e.g. identified by a tag Leads to two levels of deployment scenarios

EGI-InSPIRE RI Requirements /2 * Does the VM Management interface need scheduling functionalities? We need for sure internally, probably not to be exposed In a federated scenario, makes sense * Req: how long will take from request to instantiation for single and bulk submission These requirements are *** for production scenarios

EGI-InSPIRE RI Requirements/3 ** Expiry and revocation of images Revocation can be done now by policy decision at the site The Site admin should be able to understand if there is a VM running based on a certain image *** State view from the VM Mgt interface of what is running on the system An end-user should be able to know which VMs started by him are running on a certain system A sys admin should be able to know who is running what ** A user can request to make a snapshot of its running VM through the API if enabled by the site

EGI-InSPIRE RI Requirements /4 *** Authentication mechanisms preferably X.509v3 or VOMS proxy evaluate SAML/Shibboleth, EDUGain Two levels (we consider the first): Super-users starting/stopping VMs at a site Users of services running in a VM *** The VM management should be agnostic to supported hypervisors, but expose which hypervisors are supported The decision of which hypervisors should be supported by sites is a policy decision

EGI-InSPIRE RI Questions Difference between starting a process and a VM? Redhat provides features to tune process resource consumption Processes can be checkpointed, migrated,... Advantage to treat things

EGI-InSPIRE RI Standards for VM Management STD for VM Management OCCI for VM Mgt (create/start/stop/…) OVF for VM format OCCI and OVF need integration Moving VM between sites CDMI can be a possible solution Connecting OCCI/OVF/CDMI EC2? Maybe higher level TCloud from DMTF, similar goal of OCCI Maturity? TCloud similar to OCCI CDMI: reference implementation + SARA Messaging is out of scope at the moment Standard for network?

EGI-InSPIRE RI Actions Check number of implementations of Tcloud and OCCI and which are production quality

EGI-InSPIRE RI State of VM Management Implementations The requirements should be on the interfaces; given this: What VM Management solutions can we consider? OpenNebula, Open Stack, Nimbus, Eucalyptus, batch schedulers (in the area of user jobs as VM), Platform ISF, VMWare See cloud arch from Redhat 2/25/