1description: > 2 Implement this to add system dump management. 3 4 System dumps are dump of the host memory and hardware states generated 5 during a failure in the host firmware. This can be a huge dump stored in the 6 host memory, the BMC doesnt store this dump but stream this dump to an 7 external client based on the offload request. Apart from system generated 8 system dump, users can also request for this kind of dump. 9 10properties: 11 - name: SourceDumpId 12 type: uint32 13 description: > 14 The dump id provided by the source of the dump. There are dumps which 15 get generated outside the BMC, like a system dump which gets generated 16 and stored in the host memory. All dumps will have a unique id but 17 when communicating to the source of the dump the SourceDumpId will be 18 used. 19 - name: Token 20 type: uint32 21 description: > 22 A token exchanged with an external firmware subsystem when creating a 23 dump outside of the BMC. This token can be used to identify the dump 24 entry once the collection is completed. 25 - name: SystemImpact 26 type: enum [self.SystemImpact] 27 default: Disruptive 28 description: > 29 System dumps can be broadly classified into two types based on their 30 impact on the system state. The first type, known as a 'disruptive' 31 dump, alters the system state. This kind of dump is typically 32 generated during a host crash, although it can also be manually 33 requested by a user. Despite its disruptive nature, this dump is able 34 to collect a lot of data, making it particularly useful for diagnosing 35 system crashes. The second type is a 'non-disruptive' dump. As the 36 name suggests, this dump is created without causing any disruption to 37 the system state. 38 39enumerations: 40 - name: SystemImpact 41 description: Indicate the type of system dump 42 values: 43 - name: Disruptive 44 description: > 45 The system state will change with this type of dump collection 46 - name: NonDisruptive 47 description: > 48 The system state will not change with the collection 49