September 2006 - Devel - libvirt List Archives

[Libvir] Supporting new Xen 3.0.3 blktap backend for file devices
by Daniel P. Berrange 06 Oct '06

06 Oct '06

When defining a guest's block device in the libvirt XML we currently allow the dev to be backed by either a file or block device in the host system. This is done by specifying the 'type' attribute when defing the block device XML. eg <disk type='file'> Or <disk type='block'> This is all fine & dandy for Xen 3.0.2, but in 3.0.3 we now have a choice of drivers for the 'file' backed block devices. We can either use the traditional loopback mounted system, or the new blktap system. To complicate things further still, blktap itself has man different drivers - one uses a raw file with Async-IO, another uses the QCow sparse format with AIO, and all sort of other possibilities are available... This means the easy option of just making all file devices use blktap in 3.0.3 is not practical. This in turns means we need to come up with a way to express the new driver methods in libvirt XML. There are a few options I can think of : - Allow more values in the 'type' attribute, eg file, block, blktap:aio, blktap:qcow, etc. This feels wrong because the blktap:* entries are really still 'file' types. - Introduce a new attribute 'driver' where you can specify 'loop', 'blktap:aio', 'blktap:qcow', etc - Introduce a new element 'driver' where you can specify the same <disk type="file"> <driver type='blktap:aio'/> </disk> - Same as above, but normalize the driver type further <disk type="file"> <driver type='blktap' backend='aio' /> </disk> My preference is probably option 3 or 4. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 7

[Libvir] Problem with hypercall
by Jim Fehlig 03 Oct '06

03 Oct '06

Stumbled across a problem trying to list domains with libvirt-0.1.5. Using virsh I get errors such as xen81:/tests/jim # virsh list Id Name State ---------------------------------- 0 Domain-0 running libvir: Xen Daemon error : GET operation failed: No such domain 16 xm shows xen81:/tests/jim # xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 2048 4 r----- 815825.8 vm1 1 512 2 -b---- 0.3 I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST hypercall differs slightly from the buffer in xen/dom0_ops.h. Attached is a patch against current cvs that works for me, but I'm not familiar with this part of the code so not sure if this is the proper fix. I'm using xen 3.0.2 that shipped with SLES10. Regards, Jim

3 8

[Libvir] Release of libvirt-0.1.7
by Daniel Veillard 29 Sep '06

29 Sep '06

Is available on ftp://libvirt.org/libvirt/ It's 0.1.6 with the fixes for the 2 bugs that Daniel Berrange fixed yesterday: - failure of domain info when using the hypervisor on 32 bits with 3.0.3 - the memory corrption which can happen when reading vCPU info from xend Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

Re: [Libvir] Proposal for virtual devices described in XML
by michel.ponceau＠bull.net 29 Sep '06

29 Sep '06

When specified at device creation, vifname is put in XenStore directory /local/domain/0/backend/vif/<domID>/<vif_number>. All vifnames used in a domain are returned by Get "/xend/domain/<domID>?detail=1" and converted into XML "target" by virDomainGetXMLDesc. For convenience, we could force the vifname, either at domain creation or in Attach, and ignore any "target" in "interface", except for Detach. The vifname value could be the sequence number of network device creation in domain (for Xen, it would be equal to vif number). Veuillez répondre à "Daniel P. Berrange" <berrange(a)redhat.com> Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Proposal for virtual devices described in XML On Wed, Sep 27, 2006 at 05:21:33PM +0200, michel.ponceau(a)bull.net wrote: > After comments from Daniel P. Berrange and from Bull people, my proposal > is reduced to following 2 functions: > > /* Create a virtual device attachment to backend */ > int virDomainAttachDevice(virDomainPtr domain, char *xml); This is definitely a good way forward - it lets us re-use the existing code for parsing device descriptions very easily. > /* Destroy a virtual device attachment to backend */ > int virDomainDetachDevice(virDomainPtr domain, char *xml); > /* @domain: pointer to domain object > * @xml: pointer to XML description of one device > * Returns 0 in case of success, -1 in case of failure. */ I was wondering whether we need to have the full XML block passed in for detaching devices. Perhaps it is sufficient to just pass i nthe target name of the device. Then again, some implementations may prefer to have the full XML blob available to allow greater sanity checking when detaching, so its probably worth while. > The XML would be in same form as the part of domain description for a > single device, either <disk.../disk> or <interface.../interface>. Very nice. > The device is identified by its target name. This attribute is optional > for "interface" in domain description, but would become mandatory in > Attach/Detach description. It is not yet processed in Libvirt-0.1.6 source > xml.c (function virDomainParseXMLIfDesc). I have successfully tried the attached patch, which tranlates "target" > into Xen "vifname". (It processes "ip" attribute in same way, but my try > failed, maybe because address value was invalid for Xen). I'm not sure I like the idea of having to explicitly set a vif name for every guest NIC we define - principally because there's no straightforward way for a user of this API to determine what VIF names are already in use, vs free. It also seems XenD does not tell us what the vifname for running domains are - although I think the info is in xenstore somewhere. I can see why we need the vifname to detach the device though. If we can find a way to fill in the vifname when dumping the XML, then this would let a caller uniquely identify an existing device, without us requireing that vifnames are used when creating a domain/attaching a new device (& thus let Xen still auto-allocate them) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Proposal for virtual devices described in XML
by michel.ponceau＠bull.net 28 Sep '06

28 Sep '06

My try of "ip" attribute failed because of a bug in patch. With this corrected file, it works as well as "target". Pour : libvir-list(a)redhat.com cc : Objet : Proposal for virtual devices described in XML After comments from Daniel P. Berrange and from Bull people, my proposal is reduced to following 2 functions: /* Create a virtual device attachment to backend */ int virDomainAttachDevice(virDomainPtr domain, char *xml); /* Destroy a virtual device attachment to backend */ int virDomainDetachDevice(virDomainPtr domain, char *xml); /* @domain: pointer to domain object * @xml: pointer to XML description of one device * Returns 0 in case of success, -1 in case of failure. */ The XML would be in same form as the part of domain description for a single device, either <disk.../disk> or <interface.../interface>. The device is identified by its target name. This attribute is optional for "interface" in domain description, but would become mandatory in Attach/Detach description. It is not yet processed in Libvirt-0.1.6 source xml.c (function virDomainParseXMLIfDesc). I have successfully tried the attached patch, which tranlates "target" into Xen "vifname". (It processes "ip" attribute in same way, but my try failed, maybe because address value was invalid for Xen).

1 0

[Libvir] virDomainDestroy not synchronous?
by Lon Hohberger 28 Sep '06

28 Sep '06

i686 libvirt-0.1.5-3 xen-3.0.2-33 Code: domain_desc = virDomainGetXMLDesc(vdp, 0); response = virDomainDestroy(vdp); if (response == 0 && domain_desc) { /* sleep(3); */ virDomainCreateLinux(vp, domain_desc, 0); free(domain_desc); } If I add the 'sleep()', the domain dies and virDomainCreateLinux() fails with the following error: libvir: Xen Daemon error : POST operation failed: No such domain futon1 Failed to get devices for domain futon1 That really doesn't bother me, and it's likely my fault anyway (it's not a fully configured domain; it's a dom-U sitting in the anaconda install screen). Of course, it's moot if we get a guaranteed synchronous reboot flag for virDomainReboot()... hint hint ;) What bothers me is that if I *don't* put the sleep in, the domain never actually gets destroyed. In this particular case, the domain is still sitting at the anaconda install screen; all I have to do is reconnect using xm console. If I only do a virDomainDestroy(), the domain gets destroyed. So, it looks like like the virDomainCreateLinux() cancels the destroy request before it can be completed. This makes it look like that the destroy request is not synchronous, and/or the result of the operation is not guaranteed (only that the request was made). Is it supposed to work this way, or is this a bug/problem? -- Lon

4 7

[Libvir] Proposal for virtual devices described in XML
by michel.ponceau＠bull.net 28 Sep '06

28 Sep '06

After comments from Daniel P. Berrange and from Bull people, my proposal is reduced to following 2 functions: /* Create a virtual device attachment to backend */ int virDomainAttachDevice(virDomainPtr domain, char *xml); /* Destroy a virtual device attachment to backend */ int virDomainDetachDevice(virDomainPtr domain, char *xml); /* @domain: pointer to domain object * @xml: pointer to XML description of one device * Returns 0 in case of success, -1 in case of failure. */ The XML would be in same form as the part of domain description for a single device, either <disk.../disk> or <interface.../interface>. The device is identified by its target name. This attribute is optional for "interface" in domain description, but would become mandatory in Attach/Detach description. It is not yet processed in Libvirt-0.1.6 source xml.c (function virDomainParseXMLIfDesc). I have successfully tried the attached patch, which tranlates "target" into Xen "vifname". (It processes "ip" attribute in same way, but my try failed, maybe because address value was invalid for Xen).

2 1

[Libvir] Flag to virDomainReboot to immediately reboot a domain?
by Lon Hohberger 23 Sep '06

23 Sep '06

Hi, For fencing Xen domains, I would like the ability to guarantee an immediate reboot of a domain without notifying the OS inside. Basically, I would like something equivalent to pressing the reset button on a physical machine. There's a currently unused "flags" option to virDomainReboot which would allow such an addition without breaking the ABI. Doing getXMLDesc/Destroy/Create introduces a race condition in clusters: What if outside management software notices notices the VM is missing and decides to start it up on *another* host node before we bring up the VM again using the Create call? An immediate reboot should eliminate the race (even though it's a very small window), and probably will not add any complexity. For now, 'reboot' is done as above, and 'off' is a simple Destroy call. 'On' is not possible to implement for various reasons, the most obvious of which is that the caller does not know any of the configuration information about particular domUs (except for their names). -- Lon

1 0

[Libvir] Release of libvirt-0.1.6
by Daniel Veillard 22 Sep '06

22 Sep '06

Available at ftp://libvirt.org/libvirt/ Mostly a few bug fixes, preparing the upcoming xen-3.0.3, and localization support were added in the last 2 weeks: * Support for localization of strings using gettext (Daniel Berrange) * Support for new Xen-3.0.3 cdrom and disk configuration (Daniel Berrange) * Support for setting VNC port when creating domains with new xend config files (Daniel Berrange) * Fix bug when running against xen-3.0.2 hypercalls (Jim Fehlig) * Fix reconnection problem when talking directly to http xend thanks to everybody who helped testing, improving and fixing it ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] gettext i18n support for libvirt
by Daniel P. Berrange 22 Sep '06

22 Sep '06

Attached is an updated version of my previous patch to add gettext support to libvirt. It should be pretty self-explanatory - basically wrapping all strings with _(..) or gettext_noop(...) where appropriate. I also took the opportunity to make some of the messages more consistent with each other. (To cut down size, I'm not including the actual libvirt.pot file ) Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 5

[Libvir] problem with virConnectClose in libvirt 0.1.5
by Philippe Berthault 21 Sep '06

21 Sep '06

After closing libvirt with virConnectClose, it's possible to open libvirt again in the same program with virConnectOpen but following operations on domains systematically fail. In example: conn = virConnectOpen(NULL); dom = virDomainLookupByID(conn, id); virDomainFree(dom); virConnectClose(conn); ... conn = virConnectOpen(NULL); dom = virDomainLookupByID(conn, id); ==> ERROR The second virDomainLookupByID call fails because of the do_connect() function in xend_internal.c source file. In this function, the connect() API returns ENOENT on the second virDomainLookupByID() call. ENOENT return code isn't documented in the man of connect API ! I suppose that some cleaning are missing when virConnectClose is called or in the opposite, too cleaning is done. Regards.

2 2

[Libvir] New style CDROM config in Xen 3.0.3
by Daniel P. Berrange 15 Sep '06

15 Sep '06

So in a recent change to xen-unstable.hg the way CDROM devices are configured for HVM guests changed. They are now treated as regular IDE devices, and a CDROM is signified by presence of ':cdrom' suffix on the device name http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00369.html libvirt obviously needs to support both this new style config, and the old (<= 3.0.2) style configs. Thus I requested addition of 'xend_config_format' attribute in the /xend/node SEXPR data from XenD. Christian recently committed this patch, so we can now support both CDROM style configs in libvirt. I am attaching a patch to implement this support - basically it touches xend_internal.c to fix XML->SEXPR conversion, and xml.c to fix SEXPR->XML conversion. Then this is corresponding additions to the unit tests to validate the new code, and also validate that I didn't break existing code. I am attaching the patches, but I don't intend to commit them to libvirt just yet because I don't actually have the new 3.0.3 xend running on my test systems fully yet. If anyone is using 3.0.3 any testing would be appreciated, otherwise I aim to test this towards end of next week. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 2

[Libvir] Configuration and building libvirt.
by Michel Gauthier 13 Sep '06

13 Sep '06

We want to configure and build libvirt library (0.1.4 for instance) from tar.gz file on a IA32 platform with RHEL4U2 distro without installing and build all Xen modules. The steps are the following: tar -xzvf libvirt-0.1.4.tar.gz cd libvirt-0.1.4 ./configure --prefix=/usr make make install Unfortunatly, the "./configure --prefix=/usr " aborts with: checking for library containing xs_read... no configure: error: Xen store library not found (see attached file) corresponding to lines: dnl search for the Xen store library AC_SEARCH_LIBS(xs_read, [xenstore], [], [AC_MSG_ERROR([Xen store library not found])]) in the configure file. We have then transfered the libxenstore.so file into /usr/lib directory of our machine, but the result is the same. (NB: We had previously transferred all Xen public C header files into /usr/include/xen directory) 1- Could you tell us what are the Xen files strictly necessary to achieve this operation? 2- Is this operation also possible with a IA64 building environment on our IA32 platform? Regards.

3 2

[Libvir] [PATCH] Support setting vnc port
by Jeremy Katz 12 Sep '06

12 Sep '06

We display the vncport, but never used it when creating the Xen sexpr. Attached fixes that. It also adds support for "port=-1" implying "use the first unused port"[1] Jeremy [1] The xen and qemu "vncunused" parameter

2 2

[Libvir] Proposal for virtual devices
by michel.ponceau＠bull.net 08 Sep '06

08 Sep '06

I previously made a proposal for block devices. It was rejected because it was VBD-specific and Xen-specific. Here is a proposal for transparent interface with Xen or other. The virtual device attributes (VDA) are transferred from/to application without considering their meaning, except backend domain, previously requested to be the name for user, while it is the ID for Xen. typedef struct virVDA { /* virtual device attribute */ char name[16]; char value[64]; } virVDA; int virDomainGetVdevs(virDomainPtr domain, char *type, virVDA *attr, int maxattr); * @type: pointer to device type, "disk", "network" ... * @attr: pointer to an array of virVDA structures * @maxattr: number of structures in attr array * Return: (number of VDAs per device)<<16 + (number of devices), if success; * -1 if failure. For "disk" type, Xen provides the following VDA names: "virtual-device" (virtual device number) "backend-id" (backend domain ID) "state" "backend" (backend device or file) "ring-ref" "event-channel" This function changes "backend-id" to "bkdom-name" and translates value ID into name. int virDomainCreateVdev(virDomainPtr domain, char *type, virVDA *attr, int nbattr); * @type: pointer to device type, "disk", "network" ... * @attr: pointer to an array of virVDA structures * @nbattr: number of structures in attr array For "disk" type, Xen requires the following VDA names: "uname" (backend device, value either "phy:<>" or "file:<>" "dev" (virtual device number) "mode" (value "ro" for read-only, or "rw" for read/write) "backend" (backend domain ID) This function translates "backend" user value (name) into ID. int virDomainDestroyVdev(virDomainPtr domain, char *type, char *ref); * @type: pointer to device type, "disk", "network" ... * @ref: pointer to virtual device reference (number for Xen...)

2 1

[Libvir] libvirt-0.1.5 release
by Daniel Veillard 05 Sep '06

05 Sep '06

With the recent Xen hypervisor breakage, I think it was urgent to push a new release for testing even if some parts are still in development and not finished. So expect a new release in a couple of weeks. In the meantime 0.1.5 is available at: ftp://libvirt.org/libvirt/ * Support for new hypercalls change in Xen changeset 86d26e6ec89b * bug fixes: - virParseUUID() was wrong, netwoking for paravirt guests (Daniel Berrange) - virsh on non-existent domains (Daniel Berrange) - string cast bug when handling error in python (Pete Vetere) - HTTP 500 xend error code handling (Pete Vetere and Daniel Berrange) * improvements: - test suite for SEXPR <-> XML format conversions (Daniel Berrange) - virsh output regression suite (Daniel Berrange) - new environ variable VIRSH_DEFAULT_CONNECT_URI for the default URI when connecting (Daniel Berrange) - graphical console support for paravirt guests (Jeremy Katz) - parsing of simple Xen config files (with Daniel Berrange) - early work on defined (not running) domains (Daniel Berrange) - virsh output improvement (Daniel Berrange) Thanks for everyone who helped out, please check that everything is working with the new hypervisor code, I could not test all entry points, I am on the road ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] [Patch 3/4]: Xen inactive domains: stop xend/xs/xen using inactive domains
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The existing xend, xs, xen, proxy driver backends all assume that if they're given a virDomainPtr object, the handle member is non-zero (ie its a running domain). With the addition of inactive domain support this assumption is no longer value. Thus this patch modifies all these drivers, so that if the handle is -1, then they return without doing any work. This lets the operation be correctly delegated to the new driver for inactive domains. In addition, the XenD driver assumed that if XenD returns a 404 when looking up a domain based on its name, this was a fatal error condition. Since inative domains are not known to XenD, this assumption is also now false. The attached patch modifies xend_internal so that if a 404 is returned, the error is not propagated to the libvirt error handlers. Instead the methods in question simply return -1, and control continues to the new backend for managing inactive domains. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] [Patch 2/4]: Xen inactive domains: hash file
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The management of inactive domains uses the hashtable APIs for managing its list of config files. In doing so it needed some extra capabilities. This patch adds 3 new routines: - virHashForEach - iterate over all values in the hashtable invoking a callback for each one. Modifying the hashtable from the callback is forbidden, or bad stuff will happen. - virHashRemoteSet - iterate over all values in the hashtable invoking a callback for each one. If the callback returns non zero, the element will be removed. - virHashSearch - iterate over all values in the hashtable invoking a callback for each one. The first entry for which the callback returnbs non-zero will be returned. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] [Patch 1/4] Xen inactive domains: config file APIs
by Daniel P. Berrange 04 Sep '06

04 Sep '06

This patch adds an extra API to the config file management API. This API lets you add a new config parameter to the file. Previously you could only modify existing values, not define extra ones. It also exposes an API for creating a new empty config file record, which is needed if you're creating a brand new config file, rathre than processing an existing one. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] [Pach 4/4]: Xen inactive domains: new XM driver
by Daniel P. Berrange 04 Sep '06

04 Sep '06

This patch adds a new driver xm_internal.c which manages inactive domains whose config files are found in /etc/xen. On certain operations the driver will scan /etc/xen for new domains - the scanning is throttled to only occur at most every 10 seconds. When scanning any new domains are loaded into memory, and any domains deleted off disk are removed. This driver can start new domains, define domains, get/set memory, max memory, vcpus, can dump XML, and list inactive domains. The list of inactive domains is filtered to remove any domains which are running. This driver is still work in progress. There is more work needed to report error exact conditions via libvirt error APIs, and the code for serializing from XML -> XM config file is not yet complete. The code for serializing from XM config files into XML is pretty much complete although needs more testing. All the APIs can be tested via the commands added to virsh for inactive domains last week. eg list --inactive, start, define, undefine I'll post another update of this patch tomorrow which should be more complete Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] [Patch 0/4] Xen inactive domain
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The following series of patches add support for managing inactive domains with Xen. Based on DV's recent xm config file reader, it processes all domains in /etc/xen (skipping known bogus files, xmexmaple*, xend-config.sxp). It can do all the operations you'd expect for managing inactive domains. Create a new domain, start a domain, list domains, delete a domain, change cpu / memory, get XML for domain. The impact on existing driver backends is very small - the only place which needed changing is the XenD code which lookups existing domains - making it be quiet if it get s a 404 error from XenD - this is to be expected if the domain is inactive. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Semantics for ListDomains/ ListDefinedDomains
by Daniel P. Berrange 04 Sep '06

04 Sep '06

So I was thinking a little about lifecycle support for passive domains in libvirt and wanted to clarify the intended semantics of the two methods: virConnectListDomains virConnectListDefinedDomains Am I correct in thinking that virConnectListDefinedDomains will list a domain if-and-only-if its state == 'shutoff', and that virConnectListDomains will list a domain if-and-only-if its state != 'shutoff' ie, when I start a defined domain with 'virDomainCreate', it will be removed from the 'ListDefinedDomains' set and added to the 'ListDomains' set. Likewise when shutting down it'll move back the other way. Or will the virConnectListDefinedDomains call always list a domain with a config file, even if it is running ? I realize this is a little hypothetical since XenD doesn't have lifecycle management yet, but it matters to the test backend, and any potential QEMU / UML backend, and the future XenD XML-RPC backend Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

4 9

[Libvir] Libvirt / Xen incompatible versions.
by Michel Gauthier 01 Sep '06

01 Sep '06

We've just installed the last advanced version of Xen on our IA64 platform. Unfortunatly, the build of the 0.1.4 version of libvirt with this version of Xen is not successful. The C header file of Xen /usr/include/xen/dom0_ops.h used by libvirt in xen_internal.c has been modified. The dom0_getdomaininfo_t structure is no more decared in this header file. Are you aware of this problem? What is the latest version of Xen on which libvirt has been successfully built and tested? Thanks.

2 1