Re: [libvirt] [PATCH alternative 2/2] Change contract of virDomainGetID to make it safer
On Wed, Sep 03, 2008 at 05:22:45PM +0100, Richard W.M. Jones wrote: This changes the contract of the existing virDomainGetID call so that it is guaranteed to return the ID provided that the @domain parameter is not NULL or corrupted. Actually this isn't entirely an accurate description. Inactive domains do not have an ID of -1. This is merely a sentinal we use internally. Inactive domains simply do not have an ID at all. Thus we return the -1 error code if it is asked for. This is why tools like virt-manager virsh do not display '-1' for ID - they simply leave the space blank. This should be compatible with all preceeding versions of libvirt, since all they have ever done is to check the @domain parameter and return the dom-id field. However it might not be forwards compatible with future versions: At the moment there is an odd distinction between the local and remote case. In the local case, the dom-id field is set to -1 when the domain goes (mostly anyhow, not always). In the remote case it is not set, because this is not known. In practice, this never really matters. All significant libvirt callers grab a new virDomain object from the remote end each time, thus getting an updated ID. virDomain objects seem to be individually very short-lived. It is however a bug that the remote driver does not update its internally ID field after performing Create/Destroy operations on VMs, because it knows the ID will have changed at this point. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora Index: src/libvirt.c === RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.155 diff -u -r1.155 libvirt.c --- src/libvirt.c 2 Sep 2008 15:00:09 - 1.155 +++ src/libvirt.c 3 Sep 2008 16:16:47 - @@ -1878,7 +1878,9 @@ * * Get the hypervisor ID number for the domain * - * Returns the domain ID number or (unsigned int) -1 in case of error + * Returns the domain ID number or (unsigned int) -1 if the domain is + * not running. If @domain is NULL or its memory is corrupted + * then this can also return (unsigned int) -1. I think it needs to make it clear that an inactive domain does not have an ID of -1 - this is simply an error code indicating the domain has not valid ID at this time. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH alternative 1/2] virDomainGetID2
On Wed, Sep 03, 2008 at 05:19:20PM +0100, Richard W.M. Jones wrote:
On Wed, Sep 03, 2008 at 05:18:16PM +0100, Richard W.M. Jones wrote:
This adds virDomainGetID2 which uses a pointer to int parameter,
allowing the -1 (non-running) domain ID to be returned safely.
With the patch this time ...
I don't particularly like this because it is implying that an inactive
domain has an ID number, which is not correct. I think we primarily
have to make the documentation for the existing API clearer.
If there's a compelling need for applications to be able to determine
whether a domain has an ID, then I think an API explicitly answering
that question would be preferrable. eg something like
/*
* Return a non-zero positive number if the domain is active
* and has a valid ID. Return zero if the domain is inactive
* and does not have any ID number. Return -1 upon error
*/
int virDomainHasID(virDomainPtr dom) {
if (!VIR_IS_DOMAIN(domain)) {
virLibDomainError(NULL, VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
return -1;
}
if (dom-id == -1)
return 0;
else
return 1;
}
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add documentation for C# binding and fix Windows documentation
On Wed, Sep 17, 2008 at 04:23:22PM +0100, Richard W.M. Jones wrote: This patch changes the bindings page so that the language names are emboldened and so that Java and C# are listed too. I've also listed Windows on that page, not strictly because it is a language, but because it's a platform. Seems reasonable. The existing documentation on building libvirt on Windows is bogus and possibly wrong. This patch also replaces that with a more accurate placeholder. This looks good to me. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] cpu flags
On Wed, Sep 17, 2008 at 09:52:08AM -0400, Ben Guthro wrote: We should not have to re-write the scanning of /proc/cpuinfo in every hypervisor driver, IMHO. Yes, sharing code like that is the way to go. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] cpu flags
On Wed, Sep 17, 2008 at 09:52:08AM -0400, Ben Guthro wrote: I think the most likely place for exposing CPU flags would be in the capabilities XML format. We do in fact already expose 3 flags there, PAE, VMX and SVM. This looks like all of the info that I need - I guess I overlooked this part of the code prior to my message. The problem that I see currently is that despite the capabilities string containing the host tag, with this cpu info - it is up to each hypervisor driver to implement the broadcasting of host features. For example - Xen will report PAE,VMX,SVM - but my ovirt node running KVM currently only reports the following: host cpu archx86_64/arch /cpu /host It seems to me that it might be useful for some sort of node info driver, where we might be able to share code for hypervisor independent info about the physical machine it is running on. We already have a place for this useful reusable node info code - the cunningly named src/nodeinfo.c :-) We should not have to re-write the scanning of /proc/cpuinfo in every hypervisor driver, IMHO. Totally agreed , this is why we put the node stuff in a separate nodeinfo.c file even though only QEMU driver currently uses it. Which reminds me that I need to hook it into the LXC driver. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Don't remove devel files in spec
On Wed, Sep 17, 2008 at 02:20:17PM -0400, Cole Robinson wrote: The second iteration of the spec file enhancements didn't fully remove some pieces that were dependent on the devel package switch. The attached patch fixes 'make rpm' to work again. I've just applied the very same fix myself. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
RE: [libvirt] [PATCH] Don't remove devel files in spec
Hrm. My apologies for missing this piece. I thought I tested that prior to the second submission...but clearly I missed it. +1 for me. Ben -Original Message- From: [EMAIL PROTECTED] on behalf of Daniel P. Berrange Sent: Thu 9/18/2008 6:20 AM To: Cole Robinson Cc: libvir-list@redhat.com Subject: Re: [libvirt] [PATCH] Don't remove devel files in spec On Wed, Sep 17, 2008 at 02:20:17PM -0400, Cole Robinson wrote: The second iteration of the spec file enhancements didn't fully remove some pieces that were dependent on the devel package switch. The attached patch fixes 'make rpm' to work again. I've just applied the very same fix myself. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] read network config in OpenVZ driver
On Wed, Sep 17, 2008 at 08:28:56PM +0400, Evgeniy Sokolov wrote:
I attached patch without hunk which was commited by Daniel.
Please commit if you are agree with it.
A few comments inline..
So you're not artifically restricting the max length of the
network name.
It is limit in OpenVZ kernel. I did not remove check for max length.
Thanks for review. Corrected patch is attached.
Index: src/openvz_conf.c
===
RCS file: /data/cvs/libvirt/src/openvz_conf.c,v
retrieving revision 1.39
diff -u -p -r1.39 openvz_conf.c
--- src/openvz_conf.c 8 Sep 2008 12:45:29 - 1.39
+++ src/openvz_conf.c 18 Sep 2008 11:30:06 -
@@ -151,6 +151,146 @@ char *openvzMacToString(const unsigned c
return strdup(str);
}
+/*parse MAC from view: 00:18:51:8F:D9:F3
+ return -1 - error
+ 0 - OK
+*/
+static int openvzParseMac(const char *macaddr, unsigned char *mac)
+{
+int ret;
+ret = sscanf((const char *)macaddr, %02X:%02X:%02X:%02X:%02X:%02X,
+ (unsigned int*)mac[0],
+ (unsigned int*)mac[1],
+ (unsigned int*)mac[2],
+ (unsigned int*)mac[3],
+ (unsigned int*)mac[4],
+ (unsigned int*)mac[5]) ;
+if (ret == 6)
+return 0;
+
+return -1;
+}
+
+static virDomainNetDefPtr
+openvzReadNetworkConf(virConnectPtr conn, int veid) {
+int ret;
+virDomainNetDefPtr net = NULL;
+virDomainNetDefPtr new_net;
+char temp[4096];
+char *token, *saveptr = NULL;
+
+/*parse routing network configuration*
+ * Sample from config:
+ * IP_ADDRESS=1.1.1.1 1.1.1.2
+ * splited IPs by space
+ */
+ret = openvzReadConfigParam(veid, IP_ADDRESS, temp, sizeof(temp));
+if (ret 0) {
+openvzError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(Cound not read 'IP_ADDRESS' from config for container %d),
+ veid);
+goto error;
+} else if (ret 0) {
+token = strtok_r(temp, , saveptr);
+while (token != NULL) {
+new_net = NULL;
+if (VIR_ALLOC(new_net) 0)
+goto no_memory;
+new_net-next = net;
+net = new_net;
+
+net-type = VIR_DOMAIN_NET_TYPE_ETHERNET;
+net-data.ethernet.ipaddr = strdup(token);
+
+if (net-data.ethernet.ipaddr == NULL)
+goto no_memory;
+
+token = strtok_r(NULL, , saveptr);
+}
+}
+
+/*parse bridge devices*/
+/*Sample from config:
+ *NETIF=ifname=eth10,mac=00:18:51:C1:05:EE,host_ifname=veth105.10,host_mac=00:18:51:8F:D9:F3
+ *devices splited by ';'
+ */
+ret = openvzReadConfigParam(veid, NETIF, temp, sizeof(temp));
+if (ret 0) {
+openvzError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(Cound not read 'NETIF' from config for container %d),
+ veid);
+goto error;
+} else if (ret 0) {
+token = strtok_r(temp, ;, saveptr);
+while (token != NULL) {
+/*add new device to list*/
+new_net = NULL;
+if (VIR_ALLOC(new_net) 0)
+goto no_memory;
+new_net-next = net;
+net = new_net;
+
+net-type = VIR_DOMAIN_NET_TYPE_BRIDGE;
+
+char *p = token, *next = token;
+char cpy_temp[32];
+int len;
+
+/*parse string*/
+do {
+while (*next != '\0' *next != ',') next++;
+if (STRPREFIX(p, ifname=)) {
+p += 7;
+len = next - p;
+if (len 16) {
+openvzError(conn, VIR_ERR_INTERNAL_ERROR,
+_(Too long network device name));
+goto error;
+}
+
+if (VIR_ALLOC_N(net-data.bridge.brname, len+1) 0)
+goto no_memory;
+
+strncpy(net-data.bridge.brname, p, len);
+net-data.bridge.brname[len] = '\0';
+} else if (STRPREFIX(p, host_ifname=)) {
+p += 12;
+//skip in libvirt
+} else if (STRPREFIX(p, mac=)) {
+p += 4;
+len = next - p;
+if (len != 17) { //should be 17
+openvzError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(Wrong length MAC address));
+goto error;
+}
+strncpy(cpy_temp, p, len);
+cpy_temp[len] = '\0';
+if (openvzParseMac(cpy_temp, net-mac)0) {
+openvzError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(Wrong MAC address));
+goto error;
+}
+} else if (STRPREFIX(p, host_mac=)) {
+
[libvirt] openvz support in libvirt
Hello. To start with, I have the following questions: Does libvirt support the xml format for openvz driver described in the next thread? http://www.redhat.com/archives/libvir-list/2008-July/msg00312.html (I think, that it does not. But will it support it in future? :)) What libvirt functionality does openvz driver support? (Openvz does not mentioned in http://libvirt.org/hvsupport.html) Anton. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC] Events API
Hi - We have some folks looking into the implementation of events (just VM state transition events, for now) in libvirtd. I've been assuming that events will be XML strings, something like: event type=domain-state-transition timestamp=x domain-id22/domain-id old-statenostate/old-state new-staterunning/new-state /event where the contents of the event element are determined by the event type, and the attributes type and timestamp are required. Originally, I was thinking one would listen for events by registering a callback, something like: int virConnectAddEventHandler(virConnPtr conn, char **filter, virEventHandler handler, void *arg) where filter is either NULL, indicating interest in all events, or else a NULL-terminated vector of event type names, allowing filtering by event type. void handler(conn, const char *eventXML, arg) would be called for each matching event. I'm a little concerned that a vector of event type names isn't really adequate for specifying a filter. Does this need to be more general (XPathString exprs??) But my larger concern is that an asynchronous callback mechanism (as proposed above) assumes the presence of some thread / process from which to make the callbacks. This works fine in the libvirtd context, but not outside of it. For instance, we build a client only version of libvirt with ONLY the remote driver, which currently doesn't require pthreads at all. Introducing asynchronous callbacks into the API means pthreads is now required for this. I'm not sure how much requiring this extra thread matters. If it does, we could always define a synchronous delivery mechanism instead. For instance, we could have a virDeliverEvents(conn) call to make the callbacks for any outstanding events. Or we could just dispense with callbacks altogether, and return a readable (pipe) fd from which the client can read events. Comments?? Dave P.S. We'll also need an internal API for sending events (most likely, an extension of the existing virEvent stuff), but let's get the basic shape of the external interface agreed upon first. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] openvz support in libvirt
Hi, About libvirt functionality for openVZ. see the struct openvzDriver in libvirt/src/openvz_driver.c (around line 957) http://git.et.redhat.com/?p=libvirt.git;a=blob;f=src/openvz_driver.c Thanks Atsushi SAKAI Anton Protopopov [EMAIL PROTECTED] wrote: Hello. To start with, I have the following questions: Does libvirt support the xml format for openvz driver described in the next thread? http://www.redhat.com/archives/libvir-list/2008-July/msg00312.html (I think, that it does not. But will it support it in future? :)) What libvirt functionality does openvz driver support? (Openvz does not mentioned in http://libvirt.org/hvsupport.html) Anton. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
