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.
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
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.
There are API categories totally not supported:
- AutoScale
- VPC
- Volume
- ISO
- System VM
- Storage Pool
- Snapshot
- Disk Offering
- BigSwitch
- VNS
- SwiftS3
For now, baremetal doesn't have specific error for unsupported API. This will be improved later when CloudStack API interceptor is ready
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.
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.
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.
- create a network offering with network service: userdata, sercuritygroup, baremetalpxeservice selected, we assume using external DHCP service in this example.
- create a basic zone with aforementioned network offering.
- 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.
- configure hosts and write up information of IPMI ip, IPMI account/password, MAC address of nic which will broadcast DHCP request
- 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.
- add OS installed in step 5 to CloudStack by API addBaremetalPxeKickStartServer
- create a Cluster with hypervisor type "BareMetal"
- 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
- create a service offering with the same host tag specified in step 7
- 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) - go to instance page, create a VM from template and service offering aforementioned
Architecture and Design description
new tables: baremetal_dhcp_devices, baremetal_pxe_devices
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: