On 10/21/2011 07:13 AM, Michal Privoznik wrote:
If a disk source gets dropped because it is not accessible,
mgmt application might want to be informed about this. Therefore
we need to emit an event. The event presented in this patch
is however a bit superset of what written above. The reason is simple:
an intention to be easily expanded, e.g. on 'user ejected disk
in guest' events. Therefore, callback gets source string and disk alias
(which should be unique among a domain) and reason (an integer);
The guaranteed unique string is disk->dst, which is required by the
schema and parser to be present for all disks (from <target dev='...'>
in the XML). While disk aliases are also unique, they are not part of
the user's XML, and correspond only to what we create under the hood to
pass to qemu. I wonder if we should go with the disk target name,
rather than the disk alias. That would also match what I did for
snapshots - a <domainsnapshot> prefers listing disk->dst anywhere on
output where a unique name is needed.
/**
+ * virConnectDomainEventDisChangeReason:
+ *
+ * The reason describing why this callback is called
+ */
+typedef enum {
+ VIR_DOMAIN_DISK_CHANGE_MISSING_ON_START = 0, /* oldSrcPath is set */
+} virConnectDomainEventDiskChangeReason;
+
+/**
+ * virConnectDomainEventDiskChangeCallback:
+ * @conn: connection object
+ * @dom: domain on which the event occurred
+ * @oldSrcPath: old source path
+ * @newSrcPath: new source path
+ * @reason: reason why this callback was called; any of
+ * virConnectDomainEventDiskChangeReason
+ * @opaque: application specified data
+ *
+ * This callback occurs when disk gets changed. However,
+ * not all @reason mush cause both @oldSrcPath and @newSrcPath
s/mush/will/
+++ b/src/conf/domain_event.c
@@ -88,6 +88,12 @@ struct _virDomainEvent {
int type;
int status;
} blockJob;
+ struct {
+ char *oldSrcPath;
+ char *newSrcPath;
+ char *devAlias;
See for example where domain_conf.c lists _virDomainSnapshotDiskDef uses
char *name as its mapping back to <target dev='...'>.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list