Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 

...