SPEC Virtualization Manager Guest Lifecycle Events

Virtualization Manager Guest Lifecycle Events

This document will go over the management events that are associated with both application (containers) and operating system virtualization. Knowing what events are expected and what they mean allows an analytical application to properly reason about status and lifecycle. The following table lists the events that comprise virtualization management in the audit trail. The events fall into two categories, required and recommended

Required:

• AUDIT_VIRT_MACHINE_ID - Records guest name to be associated with events
• AUDIT_VIRT_INTEGRITY_CHECK - Records results of guest integrity test
• AUDIT_VIRT_RESOURCE - Records assignment of all resources to guest
• AUDIT_VIRT_CONTROL - Records start/pause/stop of guest

Recommended:

• AUDIT_VIRT_CREATE - Records the creation of the guest image
• AUDIT_VIRT_DESTROY - Records the destruction of the guest image
• AUDIT_VIRT_MIGRATE_IN - Records information about the arrival of a guest
• AUDIT_VIRT_MIGRATE_OUT - Records information about the departure of a guest

Lifecycle of Guest, Required Events

When a guest is started, the host's manager must start by sending an AUDIT_VIRT_MACHINE_ID event to record the name of the vm and some identification information and labels if applicable. This is so that utilities can use name and identification information in subsequent reports about the session.

During start up, the integrity of the guest must be tested. The host must record this using an AUDIT_VIRT_INTEGRITY_CHECK event which must record what integrity mechanism was used (including "none"?), pass or fail results, and the action the host took as a result of the test.

After this, any device that is assigned to the guest must be recorded using a AUDIT_VIRT_RESOURCE event. The event must describe what the device is and its identifying attributes such as path, MAC address, UUID, etc. In cases where the device has quantitative values associated - like how many cores, amount of memory, etc, the old and new values must be recorded. This event must also be sent any time the guest is modified while running.

The final required event is an AUDIT_VIRT_CONTROL event that records the state of the guest such as start, pause, or shutdown.

Lifecycle of Guest, Recommended Events

There are some other helpful events that are not yet mandatory in common criteria but are likely to be included in the future because they keep getting discussed. When a guest image is created, there is an AUDIT_VIRT_CREATE event that should be used to record what the name of the guest is, what source is used to create the image, its uuid, what form of integrity check will be used, fingerprint or hash of resulting image, and location of the resulting guest image on storage.

When a guest is decommissioned, an AUDIT_VIRT_DESTROY event should be used to record the name of the guest being erased, how it was erased, and the location where the guest image used to reside.

If the virtualization supports guest migration an AUDIT_VIRT_MIGRATE_IN event should be used to indicate where it came from, form of integrity testing to be used, fingerprint or hash of recieved image, and guest name. Likewise, an AUDIT_VIRT_MIGRATE_OUT event should be create when a guest leaves to indicate where its going to, integrity used, fingerprint or hash of leaving image, whether it was successfully done, and how the image was cleaned up. Migration events should be similar in content to create and destroy events except they indicate the transitory nature of the guest.

Recording the events

Typically a programmer would use the audit_log_user_message function to record various bits of information needed to describe the virtualization events.

Conclusion

Having some rules around the auditing of virtualization will allow for better analysis of what is happening on a system. This will also allow for test suites to be created to spot problems with this common understanding of how the virtualization must behave so that apps are corrected.