<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [libvirt] RFC: Domain events add DEFINED and UNDEFINED events</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>I think this sounds reasonable.<BR>
<BR>
Let me see if I understand the state machine for a newly created persistent domain:<BR>
DEFINED->ADDED->STARTED->STOPPED<BR>
<BR>
Starting, then stopping a previously defined persistent domain would just emit<BR>
STARTED->STOPPED<BR>
<BR>
and a transient domain would be:<BR>
ADDED->STARTED->STOPPED->REMOVED<BR>
<BR>
Will it be an issue for domains that only support a subset of these events (like xen)<BR>
<BR>
Yesterday, I began looking into creating a xen driver patch for emitting the DEFINED/UNDEFINED events via inotify.<BR>
It looks like the easiest way to do this right now is to create yet another Xen sub-driver.<BR>
I don't expect this to take an extremely long time, as this tutorial from IBM makes it fairly straightforward to understand:<BR>
<A HREF="http://www-128.ibm.com/developerworks/linux/library/l-inotify.html">http://www-128.ibm.com/developerworks/linux/library/l-inotify.html</A><BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: libvir-list-bounces@redhat.com on behalf of Daniel P. Berrange<BR>
Sent: Fri 11/7/2008 5:34 AM<BR>
To: libvir-list@redhat.com<BR>
Subject: [libvirt] RFC: Domain events add DEFINED and UNDEFINED events<BR>
<BR>
We currently have the following list of events for domains:<BR>
<BR>
      VIR_DOMAIN_EVENT_ADDED,<BR>
      VIR_DOMAIN_EVENT_REMOVED,<BR>
      VIR_DOMAIN_EVENT_STARTED,<BR>
      VIR_DOMAIN_EVENT_SUSPENDED,<BR>
      VIR_DOMAIN_EVENT_RESUMED,<BR>
      VIR_DOMAIN_EVENT_STOPPED,<BR>
      VIR_DOMAIN_EVENT_SAVED,<BR>
      VIR_DOMAIN_EVENT_RESTORED,<BR>
<BR>
The QEMU driver supports all of them, except for ADDED and REMOVED. I<BR>
was looking at adding these and wondering how exactly we should define<BR>
the semantics<BR>
<BR>
Originally I was just going to emit 'ADDED' from virDomainDefine() driver<BR>
impl and 'REMOVED' from virDomainUndefine().<BR>
<BR>
This does not, however, take into account that there are two sorts of<BR>
domains, so called 'persistent' and 'transient' domains.<BR>
<BR>
With a transient domain, there is no config file, so the first time you<BR>
know about the domain is when it is booted via virDomainCreateXML(),<BR>
and all trace of it disappears when it shuts down, or migrates, or is<BR>
saved.  With a persistent domain though, it is visible before it is<BR>
booted, and remains visible after shutdown/migrate/save etc.<BR>
<BR>
The current set of events does not allow applications to get this level<BR>
of visibility. eg when receiving a VIR_DOMAIN_EVENT_STOPPED event, there<BR>
is no way to know wether the domain was transient / persistent, and thus<BR>
whether to remove it from your list of VMs, or simply mark it shutoff.<BR>
<BR>
So, I'd like to propose that we do the following:<BR>
<BR>
 - Clarify the semantics for<BR>
<BR>
    * VIR_DOMAIN_EVENT_ADDED<BR>
   <BR>
    Emitted when a domain comes into existance, by which I mean a<BR>
    previously known inactive domain is defined, or a transient<BR>
    domain is booted. This is emited before any other events for<BR>
    a domain with that UUID/name.<BR>
<BR>
    * VIR_DOMAIN_EVENT_REMOVED<BR>
<BR>
    Emitted when a domains goes out of existance, by which I mean<BR>
    a transient domain shuts down / migrates / is saved, or a<BR>
    persistent domain is undefined. This is the last event ever to<BR>
    be emitted for a domain with that UUID/name.<BR>
<BR>
<BR>
 - Create two more events<BR>
<BR>
     * VIR_DOMAIN_EVENT_DEFINED<BR>
<BR>
     Emitted whenenever a domain's config file is created. This can<BR>
     be when a peristent domain is first defined, when it is later<BR>
     re-defined, or when an transient domain gains a confi file,<BR>
     becoming persistent.<BR>
<BR>
     * VIR_DOMAIN_EVENT_UNDEFINED<BR>
<BR>
     Emitted when a domain's config file is removed.<BR>
<BR>
With this complete set of events, virt-manager is able to track domains<BR>
without ever having to poll for the domain listing.<BR>
<BR>
I think we also need to provide some way for an application to determine<BR>
what set of events a hypervisor backend supports. eg, if it only supports<BR>
the STARTED/STOPPED events, virt-manager would still need to do polling to<BR>
find out about defined/undefined domains.<BR>
<BR>
Daniel<BR>
--<BR>
|: Red Hat, Engineering, London   -o-   <A HREF="http://people.redhat.com/berrange/">http://people.redhat.com/berrange/</A> :|<BR>
|: <A HREF="http://libvirt.org">http://libvirt.org</A>  -o-  <A HREF="http://virt-manager.org">http://virt-manager.org</A>  -o-  <A HREF="http://ovirt.org">http://ovirt.org</A> :|<BR>
|: <A HREF="http://autobuild.org">http://autobuild.org</A>       -o-         <A HREF="http://search.cpan.org/~danberr/">http://search.cpan.org/~danberr/</A> :|<BR>
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|<BR>
<BR>
--<BR>
Libvir-list mailing list<BR>
Libvir-list@redhat.com<BR>
<A HREF="https://www.redhat.com/mailman/listinfo/libvir-list">https://www.redhat.com/mailman/listinfo/libvir-list</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>