Bug 1070411
| Summary: | RFE: domain: Add <creationTime> timestamp | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Tony <tatkinson> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | berrange, crobinso, eblake |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-17 12:20:49 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tony
2014-02-26 18:39:01 UTC
I'd like some clarification on what is desired here. In virsh terminology, 'virsh create' starts a transient guest, while 'virsh define' creates but does not start a persistent guest. Are you looking at the time since a domain first had XML registered (whether transient or persistent, and for the persistent case, regardless of whether the guest is running or not), or at the time since a domain has been running (uptime, but only available while the guest is running, resets each time a persistent guest goes offline)? A timestamp of when the domain is first defined. (when the UUID for the domain is allocated) My /particular/ use case involves tracking guest resource usage over time. I need to maintain a consistant ordering of virtual machines. Domain ID is not persistant, and the UUID (while unique and persistant) is not useful for sorting. Ideally, I would want something like <domain type='kvm'> <name>banana</name> <uuid>b4f24019-ee69-6b4b-34a1-40f6e4126c57</uuid> <created>1393442012</created> ... </domain> As pointed out upstream, you can use <metadata> to track anything you want alongside a uuid, including a timestamp when you allocated the uuid, which should work for you now whether or not libvirt adds a <created> element down the road. There's also the consideration of how to handle this for transient domains - if no timestamp is specified in the incoming XML, libvirt would supply the current domain, but in many cases (think VDSM as an application managing transient domains across a cluster of hosts) the actual domain definition has an older date of UUID allocation, known by management but not libvirt. So that means it should also be possible to set the timestamp when creating a domain XML to something other than the current time, which means that timestamps can be modified by modifying XML, which means they might possibly be less reliable than you were hoping. Ok, no problem
For my particular need I've hacked the timestamp out of the apparmor definition file
stat --format="%Y" /etc/apparmor.d/libvirt/libvirt-${VM_UUID}
I just thought it was a useful piece of info that may be worth formally including in the domain definition.
Personally, I _do_ think it is worth adding an element to the libvirt XML - we already have a <creationTime> element for domain snapshots. I'm just trying to make sure that we are thinking about the implications, and that we are also aware of alternatives for working around older libvirt that don't support an element. Closing old RFE since it isn't a critical and there's a viable workaround via the <metadata> element for mgmt apps to record a creation time and other interesting info. |