Introduction

Purpose

Support kickstart installation method for RPM based Linux operation system, users can provision a baremetal host managed by CloudStack as long as they has kickstart file and corresponding OS installation ISO ready.

Supporting OS:

As it uses kickstart installation method, all Linux installer supporting kickstart should be supported.

Now the tested OS are CentOS5.5, CentOS6.2, CentOS6.3, Ubuntu12.04

References

Document History

Glossary

  • TFTP server: 
    a CentOS installed with tftp-server package interacting with baremetal host during PXE boot phase, managed by CloudStack. Baremetal host will automatically download bootable Linux kernel and initrd.img from tftp server and start install process. 
  • DHCP server: 
    can be either managed by CloudStack or by user's DHCP infrastructure. If using DHCP server not managed by CloudStack, user must set next-server option pointing to TFTP server in order to navigate host the place to get bootable Linux kernel and initrd.img
  • IPMI: 
    protocol used to control power state/boot device of host. CloudStack uses ipmi-tool to send command to host
  • *KickStart file:\* (file:*)
    a text file describing components to be installed and system configuration. see References above
  • OS ISO:
    OS installation CD

Feature Specifications

  • The feature only supports kickstart installation for RPM based Linux distribution, largely RedHat series OS (e.g. Rhel, Fedora, CentOS).
  • support CloudStack security group feature as long as baremetal security group agent is installed by kickstart file
  • only supports CloudStack basic zone
  • support CloudStack userdata
  • support binding ip address allocated to VM to host when adding host. Then VM starting on that host will be assign to fixed IP
  • no CloudStack storage concepts: primary storage, secondary storage, volume, snapshot
  • no CloudStack service VMs: SSVM, CPVM, VR
  • no template copy, download 
  • no VM migration
  • no multiple nics support
  • a stopped VM(the OS running on host) can only start on the host it's lastly on
  • using host tag for allocating host, capacity(cpu, memory) specifying in service offering is never used
API Metrics:

     As a specific compute resource backend, Baremetal varies a lot from virtualization hypervisor like Xenserver, KVM, and VMWare. In general, baremetal supports all hypervisor unrelated APIs, for example, createZone, createCluster, createNetwork; for these hypervisor related APIs, here is a list of them that baremetal supports.

Virtual Machine
Host
There are API categories totally not supported:
  • AutoScale
  • VPC
  • Volume
  • ISO
  • System VM
  • Storage Pool
  • Snapshot
  • Disk Offering
  • BigSwitch
  • VNS
  • SwiftS3

 

Unsupported API Error:

For now, baremetal doesn't have specific error for unsupported API. This will be improved later when CloudStack API interceptor is ready

Host Connection Status:

Baremetal defines its host connections status based on IPMI connectivity. Unlike other hypervisors, host power state is totally unrelated to connection status in baremetal. A baremetal host is considered as UP when a IPMI command can be successfully executed, and is considered as DOWN if any IPMI command failure happens. Baremetal uses 'chassis power status' command to periodically check IPMI connectivity.  

HA and VM status sync:

Baremetal doesn't support any HA. For historical reason, baremetal disables vm status sync which is known as vm sync in CloudStack, because the former vm sync framework is buggy and often causes customer's baremetal instance unexpected shutdown. Without vm sync, for example, if a baremetal instance is powered off outside CloudStack, the instance will be still shown as Running on CloudStack UI. Customer should avoid this kind of outbound operations until baremetal vm sync gets fixed. 

Host Allocator(Planner):

Baremetal uses separate host allocator, admin must specify planner type to BaremetalPlanner when creating a compute offering for baremetal instance. Traditional allocator reserves cpu/memory from host capacity table based on capacity value  specified in compute offering. Baremetal host allocator does differently, it allocates host based on host tag in compute offering and reserves all capacity of host after the host is chosen to create baremetal instance. The reason to do this is baremetal instance always occupies an entire host, which makes cpu/memory capacity in compute offering meaningless.

Use cases

  1. create a network offering with network service: userdata, sercuritygroup, baremetalpxeservice selected, we assume using external DHCP service in this example.
  2. create a basic zone with aforementioned network offering.
  3. create a Pod. The guest ip range adding to Pod must be in the same subnet of host's IPMI ip. Reserved ip range for CloudStack service VM is never used.
  4. configure hosts and write up information of IPMI ip, IPMI account/password, MAC address of nic which will broadcast DHCP request
  5. install a CentOS VM to the zone. Install CloudStack baremetal agent in it and run cloud-setup-baremetal, write up information printed out. for each switch in the zone enable DHCP forwarding to this CentOS VM.
  6. add OS installed in step 5 to CloudStack by API addBaremetalPxeKickStartServer
  7. create a Cluster with hypervisor type "BareMetal"
  8. add a host, provide all information required by UI page. Note the 'hostname' is ipmi ip, 'account' is ipmi account, 'password' is ipmi password. Please make sure cpu number/speed, memory size is matching your real host fact, otherwise the dashboard may not display precisely. IMPORTANT: the host tag must be set to some value, otherwise the host will not be found by host allocator. If multiple host tags are set, only the first one takes effect
  9. create a service offering with the same host tag specified in step 7
  10. adding a template. the URL must be encoded in formula of
    ks=Kickstart_file_location;kernel=boot_kernel_on_nfs_path;initrd=boot_initrd_on_nfs_path (for example: //nfs1.lab.vmops.com/baremetal/rhel5.ks;kernel=192.168.253.81:/kickstart/rhel5/vmlinuz;initrd=192.168.253.81:/kickstart/rhel5/initrd.gz)
  11. go to instance page, create a VM from template and service offering aforementioned 

Architecture and Design description

Database Changes:

new tables: baremetal_dhcp_devices, baremetal_pxe_devices

New Components:

all components related to baremetal locates in cloudstack_source_root_folder/baremetal/

web services APIs

addBaremetalHost=com.cloud.baremetal.manager.AddBaremetalHostCmd

addBaremetalDhcp=com.cloud.baremetal.networkservice.AddBaremetalDhcpCmd

addBaremetalPxePingServer=com.cloud.baremetal.networkservice.AddBaremetalPxePingServerCmd

listBaremetalDhcp=com.cloud.baremetal.networkservice.ListBaremetalDhcpCmd

listBaremetalPxePingServer=com.cloud.baremetal.networkservice.ListBaremetalPxePingServersCmd

addBaremetalPxeKickStartServer=com.cloud.baremetal.networkservice.AddBaremetalKickStartPxeCmd

UI flow

  • either demonstrate it visually here or link to relevant mockups

Appendix

Appendix A:

Appendix B:

  • No labels