Re: [libvirt] Problem compiling latest code from libvirt CVS
On Fri, Jun 05, 2009 at 01:43:15PM -0400, Dave Allan wrote: Daniel P. Berrange wrote: On Fri, Jun 05, 2009 at 12:08:13PM -0400, Dave Allan wrote: Daniel P. Berrange wrote: snip which is failing because neither of the node device driver implementations are turned on. This is a bug in the storage_backend.c file. This is a generic shared file and as such, it should not have any dependancy on the node device driver code, since the latter is guarenteed to be available. I'd split out this code to avoid duplication, but I'll refactor it again to avoid the dependency on the node device code submit a patch. Simply having the dependancy reversed should be OK. storage_backend.c is a shared file always available to drivers. Daniel Here's a patch that should remove the dependency on the node device code. Oops totally forgot about it ! Applied and commited, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Undefined symbol: virNodeDeviceWaitForDevices
On Tue, Jun 16, 2009 at 10:44:18PM +0200, Matthias Bolte wrote: 2009/6/16 Dave Allan dal...@redhat.com: Matthias Bolte wrote: Hi, GIT commit f7b12afc7b67b6727151f74683e7cb9d6fc2b36f adds a new function: virNodeDeviceWaitForDevices In storage_backend.c virStorageBackendWaitForDevices was changed to call virNodeDeviceWaitForDevices, but the code for virNodeDeviceWaitForDevices is only compiled and linked into libvirtd if the nodedev driver is build, but the nodedev driver is only build if the hal or devkit development packages are installed. If neither hal nor devkit is installed, compiling libvirt yields an undefined symbol error for virNodeDeviceWaitForDevices Regards, Matthias Hi Matthias, Somebody reported that a week or so ago and I submitted a patch that fixes it. I believe it's been applied to the source repository, but I'm not 100% certain. Dave Ah, I should have searched the mailing list first. I found the thread you referred to: [libvirt] Problem compiling latest code from libvirt CVS started by Anna Fischer. It also contains your proposed patch to solve the issue. I complied from current GIT HEAD, so your patch have not been applied yet. Done now, I had forgotten about it :-\ Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: Future release schedule
On Tue, Jun 16, 2009 at 09:18:40PM +0200, Matthias Bolte wrote: I'm currently checking the VI API to see where to gather the information for dump-xml, but it seems one needs to read most of it from the .vmx file of a virtual machine located on the host. Luckily all files of a virtual machine are readable via HTTP: http://example-esx-host.com/folder/... So the .vmx file is easily accessible using libcurl. Luckily (again) there is some unofficial documentation about the VMX format available: http://www.sanbarrow.com/vmx.html Yeah the VMX file format is quite straightforward to read / write. We already do a similar thing for Xen's configs in /etc/xen - the raw config file parsing code for that is in src/conf.c, and the code to convert XML - XM Config is in src/xm_internal.c Within the next few days I'll post a proposal on how to map a .vmx file into the libvirt xml representation. For create-xml the ESX driver would need to write a .vmx file to the ESX host, because the .vmx file is essential to create a virtual machine. Luckily (once again) the ESX host allows putting files to http://example-esx-host.com/folder/... via HTTP. Again, sounds pretty straightforward a reasonable way to go. 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] Fix logging in libvirt_lxc controller
On Tue, Jun 16, 2009 at 06:12:04PM -0400, Amy Griffis wrote: Cole Robinson wrote: [Tue Jun 16 2009, 02:44:28PM EDT] On 06/16/2009 01:35 PM, Amy Griffis wrote: The lxc controller can't see libvirtd's log level setting so it needs to re-query it from the environment. The parsing code has a few users now, so I added a new function to the internal API, virLogParseDefaultPriority() along the lines of the other parse functions. I'd say go the extra step and add something like virLogSetFromEnv, which encapsulates the duplicate getenv calls as well. I thought about that, but wanted to keep consistent behavior with the other two parsing routines. I think we could go ahead and change all of them to include the getenv(). Only minor gotcha is qemud wants to call virLogParseOutputs() with it's own string in one case. So we'd need to make the getenv() conditional on not getting an input string. I think this would be cleaner. What do you think? I think there's valid reasons for both suggested APIs. I'd suggest a slight variation on your original API, instead of: +logPrio = virLogParseDefaultPriority(debugEnv); +virLogSetDefaultPriority(logPrio); Just have a 'virLogSetDefaultPriorityFromString(char *str)', eg so it'd parse the string and then call virLogSetDefaultPriority for you. Also then having a virLogSetFromEnv() method which uses getenv to fetch the vars and then calls the virLogSet... methods 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] domain.info() sometimes returns state zero for running machines
I found that virt-manager 0.7.0 does the following: def _normalize_status(self, status): if status == libvirt.VIR_DOMAIN_NOSTATE: return libvirt.VIR_DOMAIN_RUNNING elif status == libvirt.VIR_DOMAIN_BLOCKED: return libvirt.VIR_DOMAIN_RUNNING return status def _update_status(self, status=None): if status == None: info = self.vm.info() status = info[0] status = self._normalize_status(status) if status != self.lastStatus: if self.lastStatus in [ libvirt.VIR_DOMAIN_SHUTDOWN, libvirt.VIR_DOMAIN_SHUTOFF, libvirt.VIR_DOMAIN_CRASHED ]: # Domain just started. Invalidate inactive xml self._orig_inactive_xml = None self.lastStatus = status self.emit(status-changed, status) VIR_DOMAIN_NOSTATE doesn't make much sense in that case?! Andreas Sommer wrote: I'm using Xen-3.2-1 on Debian 5.0.1-lenny and retrieve information about running domains using domain.info()[0] The domain object is retrieved via connection.lookupByUUIDString(...) and stored as a variable called domain. Usually the running domains have the state 1 (VIR_DOMAIN_RUNNING) or 2 (VIR_DOMAIN_BLOCKED), but sometimes it happens that 0 (VIR_DOMAIN_NOSTATE) is returned. Why does that happen? I don't think it is an error because then it would've raised an exception... Regards Andreas -- 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
[libvirt] Re: [netcf-devel] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Tue, 2009-06-16 at 15:12 -0400, Laine Stump wrote: I've already been working on incorporating physical host interface configuration into libvirt by way of using libnetcf on the backend. It's becoming apparent that, in addition to modifying and reporting the current configuration of interfaces, libvirt users also want to query current status of each interface (up/down, possibly other flags, packet/byte/error counts, current IP address, etc). There are two possible ways of doing this: 1) maintain libnetcf's focus on just interface configuration, and add code directly into libvirt to grab this information via appropriate ioctls or 2) add the functionality to libnetcf, and have libvirt call the new libnetcf API. (2) seems to make the most sense, because likely other libnetcf consumers will want this capability too. I agree that netcf is the right place for this functionality; the downside either way is that we'll wind up reimplementing a good bit of ifconfig's functionality. But seeing how net-tools does not expose a library that's inevitable (and it's mostly an exercise in calling ioctl anyway). I'm thinking of a single API, something like: int netcf_if_status(netcf_if *, netcf_if_stats *); (or maybe int netcf_if_info(netcf_if *, netcf_if_info *)) I haven't really put much thought into the details of what should be in netcf_if_stats yet (beyond what I listed above), but wanted to get this idea out there so people can start sounding off (if I'm going down the wrong road, I'd rather be put on the right path before I get too far along!) There should really be multiple API's to cover the functionality; rolling it all into one giant struct seems too inflexible. I am thinking there should be at least 3 calls * int netcf_if_operstate(netcf_if *) - return 1 if interface is up, 0 if not * int netcf_if_stats(netcf_if *, netcf_if_stats *) - get rx/tx statistics; which ones needs to be figured out in detail * int netcf_if_addrinfo(netcf_if *, netcf_if_addrinfo *) - get address info, i.e. IPv4 and/or IPv6 addresses assigned to the interface One wrinkle is that netcf operates at the level of 'connections', not with individual interfaces, e.g. when a physical NIC eth0 is enslaved to a bridge br0, only the bridge is currently visible through the netcf API. So for statistics gathering, you'd only see the statistics for br0 - if statistics for individual devices on the bridge are needed, we can either report all of them in netcf_if_stats, or provide a mechanism to get at the subinterfaces so that netcf_if_stats etc. can be called separately for br0 and eth0. But netcf could do it with an extra argument to ncf_list_interfaces(). If the latter, should the default behavior be to list all interfaces, with flags set to eliminate up or down interfaces? 0 (list all) NETCF_NOLIST_UP NETCF_NOLIST_DOWN Or should the values be something like this: 0 (list all) NETCF_LIST_UP_ONLY NETCF_LIST_DOWN_ONLY (UP_ONLY + DOWN_ONLY would be equivalent to 0. As long as nobody came up with a good reason for 0. So should we do one of those, or should we mimic libirt's virNetwork API in libnetcf too? I'd lean towards the flag approach, but without the special meaning for 0 - if you specify any flags, you won't get any interfaces ;) Since we're dealing with compound interfaces, we also need to define what it means for a bridge to be up - e.g., the bridge device and all enslaved physical NICs need to be up. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Tue, Jun 16, 2009 at 03:12:36PM -0400, Laine Stump wrote: I've already been working on incorporating physical host interface configuration into libvirt by way of using libnetcf on the backend. It's becoming apparent that, in addition to modifying and reporting the current configuration of interfaces, libvirt users also want to query current status of each interface (up/down, possibly other flags, packet/byte/error counts, current IP address, etc). This function could be exposed in the libvirt API as something like: int virInterfaceStatus|Info(virInterffacePtr iface, virInterfaceStats|Info *info); That is reasonable. Any comments/ideas on this? (One possible complication I can see is interfaces with multiple associated IPs. On some platforms, each interface can have only a single IPv4 and a single IPv6 address (more IPs == more interfaces), but on others there can be multiples.) IP address information should be in the XML, and indeed surely it is already there in order to allow non-DHCP based IP address config on interfaces ? 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] Fix logging in libvirt_lxc controller
Daniel P. Berrange wrote: [Wed Jun 17 2009, 06:44:31AM EDT] On Tue, Jun 16, 2009 at 06:12:04PM -0400, Amy Griffis wrote: Cole Robinson wrote: [Tue Jun 16 2009, 02:44:28PM EDT] On 06/16/2009 01:35 PM, Amy Griffis wrote: The lxc controller can't see libvirtd's log level setting so it needs to re-query it from the environment. The parsing code has a few users now, so I added a new function to the internal API, virLogParseDefaultPriority() along the lines of the other parse functions. I'd say go the extra step and add something like virLogSetFromEnv, which encapsulates the duplicate getenv calls as well. I thought about that, but wanted to keep consistent behavior with the other two parsing routines. I think we could go ahead and change all of them to include the getenv(). Only minor gotcha is qemud wants to call virLogParseOutputs() with it's own string in one case. So we'd need to make the getenv() conditional on not getting an input string. I think this would be cleaner. What do you think? I think there's valid reasons for both suggested APIs. I'd suggest a slight variation on your original API, instead of: +logPrio = virLogParseDefaultPriority(debugEnv); +virLogSetDefaultPriority(logPrio); Just have a 'virLogSetDefaultPriorityFromString(char *str)', eg so it'd parse the string and then call virLogSetDefaultPriority for you. Since the config file parser in libvirtd is returning an integer, it actually needs one function to get the environment setting and convert it to integer, and then a second function to set the value in the log module from an integer. Also then having a virLogSetFromEnv() method which uses getenv to fetch the vars and then calls the virLogSet... methods But I see what you guys are saying. I'll make these changes and send a new patch. Thanks, Amy -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [netcf-devel] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, 2009-06-17 at 19:27 +0100, Daniel P. Berrange wrote: Hmm, this seems wrong to me. 'connections' are an application level concept. The libvirt API should be exposing all the interfaces on the host, so you should see all the br0, bond0, and eth0 eth1 devices for a bridge on top of a bond. An application using libvirt can filter this to only show the logical 'connections' if required. If you start out with a fresh machine and virConnectListInterfaces gives you back 2 objects for 'eth0' and 'eth1', I would not expect these objects to disappear from the API when I created a 'bond0' out of them. We probably need two different views of the network setup: one that considers network devices (and in that area, you would always see eth0, eth1 etc. even when they are enslaved to bridges/bonds) and one that considers connections; on some OS's, it doesn't make sense to talk about eth0 when it's enslaved to a bridge br0 for config purposes. [1] has an example of how a bridge is configured on Debian - note that eth0 should not be mentioned anymore outside of the br0 setup. Of course, eth0 is still around as an interface/device, and, at a minimum, has statistics that are different from the bridge's statistics. From the netcf side, we should probably restructure the model to talk about connections (roughly what netcf_if is today, maybe renamed to netcf_conn) and interfaces/devices, and a way to get the devices from a connection, so that you can list all the interfaces involved in a bridge (connection) David [1] http://compsoc.dur.ac.uk/~djw/qemu.html -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, 2009-06-17 at 19:24 +0100, Daniel P. Berrange wrote: IP address information should be in the XML, and indeed surely it is already there in order to allow non-DHCP based IP address config on interfaces ? Yes, for statically configured interfaces, the IP information is in the XML - that is the _configured_ IP info though, not necessarily the one that the interface actually uses. The two can diverge, for example, if an interface is already up and then reconfigured. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, 2009-06-17 at 22:10 +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 09:03:32PM +0100, Daniel P. Berrange wrote: On Wed, Jun 17, 2009 at 09:42:11PM +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 12:22:13PM -0700, David Lutterkort wrote: On Wed, 2009-06-17 at 19:24 +0100, Daniel P. Berrange wrote: IP address information should be in the XML, and indeed surely it is already there in order to allow non-DHCP based IP address config on interfaces ? Yes, for statically configured interfaces, the IP information is in the XML - that is the _configured_ IP info though, not necessarily the one that the interface actually uses. The two can diverge, for example, if an interface is already up and then reconfigured. BTW I was looking at the Relax-NG grammar and found the following confusing when providing an IP address: element name=ip optional attribute name=addressref name=ip-mask//attribute /optional /element I'm not really sure what ip-mask really means, are you trying to put in a single attribute both the IP address and the netmask ? If that's the case I would really suggest to split the two as separated IP and netmask in the XML structure, either separate attributes or another element for the netmask. Best to us the explicit structure of XML than a construct hidden inside the text field, unless I misunderstood the use case... 'netmask' should really be avoided these days, in preference to 'prefix' since the latter works for IPv4 and IPv6, while the former only works for IPv4. 'netmask' can be auto-calculated from 'prefix' by apps if they really care about it. Fine by me, just that I think they should be hold by 2 separate attributes or element if possible at this point. Yes, good point; and I don't know what I was thinking when I made the address attribute optional. I'll change the schema to this: element name=ip attribute name=addressref name=ip-addr//attribute attribute name=prefixref name=prefix-pattern//attribute /element so that you'll write ip address=172.32.12.10 prefix=24/ I haven't declared the schema or the API stable yet, but I want to do that once there is a libvirt release out there that relies on netcf. So if there are any other issues with any of these aspects, raise them now or forever hold your peace. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, Jun 17, 2009 at 01:27:14PM -0700, David Lutterkort wrote: On Wed, 2009-06-17 at 22:10 +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 09:03:32PM +0100, Daniel P. Berrange wrote: On Wed, Jun 17, 2009 at 09:42:11PM +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 12:22:13PM -0700, David Lutterkort wrote: On Wed, 2009-06-17 at 19:24 +0100, Daniel P. Berrange wrote: IP address information should be in the XML, and indeed surely it is already there in order to allow non-DHCP based IP address config on interfaces ? Yes, for statically configured interfaces, the IP information is in the XML - that is the _configured_ IP info though, not necessarily the one that the interface actually uses. The two can diverge, for example, if an interface is already up and then reconfigured. BTW I was looking at the Relax-NG grammar and found the following confusing when providing an IP address: element name=ip optional attribute name=addressref name=ip-mask//attribute /optional /element I'm not really sure what ip-mask really means, are you trying to put in a single attribute both the IP address and the netmask ? If that's the case I would really suggest to split the two as separated IP and netmask in the XML structure, either separate attributes or another element for the netmask. Best to us the explicit structure of XML than a construct hidden inside the text field, unless I misunderstood the use case... 'netmask' should really be avoided these days, in preference to 'prefix' since the latter works for IPv4 and IPv6, while the former only works for IPv4. 'netmask' can be auto-calculated from 'prefix' by apps if they really care about it. Fine by me, just that I think they should be hold by 2 separate attributes or element if possible at this point. Yes, good point; and I don't know what I was thinking when I made the address attribute optional. I'll change the schema to this: element name=ip attribute name=addressref name=ip-addr//attribute attribute name=prefixref name=prefix-pattern//attribute /element so that you'll write ip address=172.32.12.10 prefix=24/ Cool :-) I haven't declared the schema or the API stable yet, but I want to do that once there is a libvirt release out there that relies on netcf. So if there are any other issues with any of these aspects, raise them now or forever hold your peace. Well I'm writing the parser, so sure I will raise those :-) There is also a lot of suggested extensions from Jim Fehlig, but I think they all can be handled as extension from the original schemas. One thing which needs to be ironed out IMHO is IPv6, better clean this up now than later. I'm not a IPv6 fan but making sure the schemas is ready for it is important I guess. The comment about dhcp6 / should probably be decided before first release. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, Jun 17, 2009 at 10:33:02PM +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 01:27:14PM -0700, David Lutterkort wrote: On Wed, 2009-06-17 at 22:10 +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 09:03:32PM +0100, Daniel P. Berrange wrote: On Wed, Jun 17, 2009 at 09:42:11PM +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 12:22:13PM -0700, David Lutterkort wrote: On Wed, 2009-06-17 at 19:24 +0100, Daniel P. Berrange wrote: IP address information should be in the XML, and indeed surely it is already there in order to allow non-DHCP based IP address config on interfaces ? Yes, for statically configured interfaces, the IP information is in the XML - that is the _configured_ IP info though, not necessarily the one that the interface actually uses. The two can diverge, for example, if an interface is already up and then reconfigured. BTW I was looking at the Relax-NG grammar and found the following confusing when providing an IP address: element name=ip optional attribute name=addressref name=ip-mask//attribute /optional /element I'm not really sure what ip-mask really means, are you trying to put in a single attribute both the IP address and the netmask ? If that's the case I would really suggest to split the two as separated IP and netmask in the XML structure, either separate attributes or another element for the netmask. Best to us the explicit structure of XML than a construct hidden inside the text field, unless I misunderstood the use case... 'netmask' should really be avoided these days, in preference to 'prefix' since the latter works for IPv4 and IPv6, while the former only works for IPv4. 'netmask' can be auto-calculated from 'prefix' by apps if they really care about it. Fine by me, just that I think they should be hold by 2 separate attributes or element if possible at this point. Yes, good point; and I don't know what I was thinking when I made the address attribute optional. I'll change the schema to this: element name=ip attribute name=addressref name=ip-addr//attribute attribute name=prefixref name=prefix-pattern//attribute /element so that you'll write ip address=172.32.12.10 prefix=24/ Cool :-) I haven't declared the schema or the API stable yet, but I want to do that once there is a libvirt release out there that relies on netcf. So if there are any other issues with any of these aspects, raise them now or forever hold your peace. Well I'm writing the parser, so sure I will raise those :-) There is also a lot of suggested extensions from Jim Fehlig, but I think they all can be handled as extension from the original schemas. One thing which needs to be ironed out IMHO is IPv6, better clean this up now than later. I'm not a IPv6 fan but making sure the schemas is ready for it is important I guess. The comment about dhcp6 / should probably be decided before first release. Yeah we definitely need IPv6 stuff in the first of this since RHEL-5 and later are required to support IPv6 for every network service, and I'm sure other enterprise distros have a similar requirement 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] domain.info() sometimes returns state zero for running machines
On Wed, Jun 17, 2009 at 04:04:20PM +0100, Andreas Sommer wrote:
I'm using Xen-3.2-1 on Debian 5.0.1-lenny and retrieve information about
running domains using
domain.info()[0]
The domain object is retrieved via connection.lookupByUUIDString(...)
and stored as a variable called domain. Usually the running domains
have the state 1 (VIR_DOMAIN_RUNNING) or 2 (VIR_DOMAIN_BLOCKED), but
sometimes it happens that 0 (VIR_DOMAIN_NOSTATE) is returned.
Why does that happen? I don't think it is an error because then it
would've raised an exception...
I think it is most likely a bug in our handling of the state info
from the hypervisor with certain Xen version. I'm fairly sure we
should never get NO_STATE for any active domain
If you want to try and troubleshoot the code, then this handled in the
xenHypervisorGetDomInfo() method in src/xen_internal.c.
It currently does this:
domain_flags = XEN_GETDOMAININFO_FLAGS(dominfo);
domain_flags = ~DOMFLAGS_HVM; /* Mask out HVM flags */
domain_state = domain_flags 0xFF; /* Mask out high bits */
switch (domain_state) {
}
.
Given that you see NO_STATE, I expect that none of the 'case' inside
the 'switch' are being matched. I'd be interested to know what the
'domain_state' value is immediately after its fetched from the HV.
So you might try changing it to
domain_flags = XEN_GETDOMAININFO_FLAGS(dominfo);
DEBUG(Raw HV state flag %x, domain_flags);
domain_flags = ~DOMFLAGS_HVM; /* Mask out HVM flags */
domain_state = domain_flags 0xFF; /* Mask out high bits */
DEBUG(Masked HV state flag %x, domain_flags);
switch (domain_state) {
}
DEBUG(libvirt state flag %x, info-state);
And then running 'LIBVIRT_DEBUG=1 virsh dominfo GUEST' and
capturing the output when it reports 'nostate'
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] problems with remote authentication with policykit
Daniel P. Berrange wrote: But when accessing remotely, I get no useful error, and a hang: $ virsh -c qemu+ssh://j...@server/system libvir: Remote error : authentication failed process hangs here $ virsh --readonly -c qemu+ssh://j...@server/system libvir: Remote error : authentication failed process hangs here Furthermore, on the server, this leaves nc processes running, and eventually there are enough that libvirtd stops accepting new connections. The hang is really odd. That suggests something is not closing the socket connection properly. If you had been yusing 0.6.1/.2/.3 I would have said it was one of the libvirtd bugs, but 0.6.4 has all event handling bugs fixed. Perhaps the libvirtd client is not killing the SSH session / process when it closes the connection after auth failure. I was using 0.4.6 on the client side. I upgraded that to 0.6.4, but I still get the hang. Virsh prints nothing; the LIBVIRT_DEBUG output is: 17:34:58.524: debug : doRemoteOpen:505 : proceeding with name = qemu:///system 17:34:58.525: debug : virExecWithHook:573 : ssh server nc -U /var/run/libvirt/libvirt-sock 17:34:58.526: debug : call:6947 : Doing call 66 (nil) 17:34:58.527: debug : call:7017 : We have the buck 66 0x7fba56729010 0x7fba56729010 17:34:59.359: debug : processCallRecvLen:6605 : Got length, now need 36 total (32 more) 17:34:59.360: debug : processCalls:6873 : Giving up the buck 66 0x7fba56729010 (nil) 17:34:59.360: debug : call:7048 : All done with our call 66 (nil) 0x7fba56729010 17:34:59.360: debug : remoteAuthPolkit:6114 : Client initialize PolicyKit authentication 17:34:59.360: debug : call:6947 : Doing call 70 (nil) 17:34:59.360: debug : call:7017 : We have the buck 70 0xbccef0 0xbccef0 17:34:59.433: debug : processCallRecvLen:6605 : Got length, now need 128 total (124 more) 17:34:59.434: debug : processCalls:6873 : Giving up the buck 70 0xbccef0 (nil) 17:34:59.434: debug : call:7048 : All done with our call 70 (nil) 0xbccef0 17:34:59.434: error : server_error:7231 : authentication failed 17:35:13.585: debug : do_open:999 : driver 4 remote returned ERROR 17:35:13.585: debug : virUnrefConnect:232 : unref connection 0xbc6a60 1 17:35:13.585: debug : virReleaseConnect:191 : release connection 0xbc6a60 If I kill the libvirtd process on the server, the client then finally prints: error: authentication failed error: failed to connect to the hypervisor and the client then exits. On the server side, the libvirtd output is 17:34:59.378: debug : remoteDispatchAuthPolkit:3385 : Start PolicyKit auth 25 17:34:59.378: info : remoteDispatchAuthPolkit:3396 : Checking PID 7551 running as 1000 17:34:59.379: debug : virEventRunOnce:567 : Poll got 1 event 17:34:59.379: debug : virEventDispatchHandles:450 : Dispatch n=2 f=9 w=3 e=1 0x1a72790 17:34:59.379: debug : nodeDeviceLock:52 : LOCK node 0x1a748e0 17:34:59.379: debug : nodeDeviceUnlock:57 : UNLOCK node 0x1a748e0 17:34:59.426: error : remoteDispatchAuthPolkit:3451 : Policy kit denied action org.libvirt.unix.manage from pid 7551, uid 1000, result: auth_admin_keep_session The hang aside, it seems libvirtd should be using org.libvirt.unix.monitor for the readonly connection? Is policykit authentication supposed to work over qemu+ssh? Yes, but only if you ssh as root such that policykit is a no-op. The problem you are seeing is becaue you SSH as non-root. PolicyKit relies on ConsoleKit to determine who is authorized, and SSH does not register ConsoleKit Sessions. As I mentioned, I've modified the PolicyKit libvirtd configuration to not require a session: match action=org.libvirt.unix.manage return result=auth_admin_keep_session/ /match so I was hoping that wouldn't be a problem. With this configuration, I think even using libpam-ck-connector wouldn't change things? I was hoping it would at least not break the --readonly case. That all said --readonly is intended to work at all times. Our default policy file includes a rule allow_anyyes/allow_any which is telling policykit to allow access even if the client is not associatied with any ConsoleKit session. So this should have allowed it to work for you with --readonly. Right, it seems libvirtd is missing readonly somehow? -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] problems with remote authentication with policykit
On Wed, Jun 17, 2009 at 05:51:27PM -0400, Jim Paris wrote: Daniel P. Berrange wrote: 17:34:59.360: debug : call:6947 : Doing call 70 (nil) 17:34:59.360: debug : call:7017 : We have the buck 70 0xbccef0 0xbccef0 17:34:59.433: debug : processCallRecvLen:6605 : Got length, now need 128 total (124 more) 17:34:59.434: debug : processCalls:6873 : Giving up the buck 70 0xbccef0 (nil) 17:34:59.434: debug : call:7048 : All done with our call 70 (nil) 0xbccef0 17:34:59.434: error : server_error:7231 : authentication failed 17:35:13.585: debug : do_open:999 : driver 4 remote returned ERROR 17:35:13.585: debug : virUnrefConnect:232 : unref connection 0xbc6a60 1 17:35:13.585: debug : virReleaseConnect:191 : release connection 0xbc6a60 If I kill the libvirtd process on the server, the client then finally prints: error: authentication failed error: failed to connect to the hypervisor and the client then exits. Ok, this bit definitely sounds like a server side bug, unless perhaps there is some buffering taking place in ssh or nc causing the errore reply packet to not be send back promptly On the server side, the libvirtd output is 17:34:59.378: debug : remoteDispatchAuthPolkit:3385 : Start PolicyKit auth 25 17:34:59.378: info : remoteDispatchAuthPolkit:3396 : Checking PID 7551 running as 1000 17:34:59.379: debug : virEventRunOnce:567 : Poll got 1 event 17:34:59.379: debug : virEventDispatchHandles:450 : Dispatch n=2 f=9 w=3 e=1 0x1a72790 17:34:59.379: debug : nodeDeviceLock:52 : LOCK node 0x1a748e0 17:34:59.379: debug : nodeDeviceUnlock:57 : UNLOCK node 0x1a748e0 17:34:59.426: error : remoteDispatchAuthPolkit:3451 : Policy kit denied action org.libvirt.unix.manage from pid 7551, uid 1000, result: auth_admin_keep_session The hang aside, it seems libvirtd should be using org.libvirt.unix.monitor for the readonly connection? In this case the problem is that the remote client end is using netcat on the wrong UNIX socket. In remote_internal.c it does cmd_argv[j++] = strdup (sockname ? sockname : LIBVIRTD_PRIV_UNIX_SOCKET); When it should be doing cmd_argv[j++] = strdup (sockname ? sockname : (flags VIR_CONNECT_IO ? LIBVIRTD_PRIV_UNIX_SOCKET_RO : LIBVIRTD_PRIV_UNIX_SOCKET); that would make libvirtd use the correct permission check 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] problems with remote authentication with policykit
Daniel P. Berrange wrote: On Wed, Jun 17, 2009 at 05:51:27PM -0400, Jim Paris wrote: Daniel P. Berrange wrote: 17:34:59.360: debug : call:6947 : Doing call 70 (nil) 17:34:59.360: debug : call:7017 : We have the buck 70 0xbccef0 0xbccef0 17:34:59.433: debug : processCallRecvLen:6605 : Got length, now need 128 total (124 more) 17:34:59.434: debug : processCalls:6873 : Giving up the buck 70 0xbccef0 (nil) 17:34:59.434: debug : call:7048 : All done with our call 70 (nil) 0xbccef0 17:34:59.434: error : server_error:7231 : authentication failed 17:35:13.585: debug : do_open:999 : driver 4 remote returned ERROR 17:35:13.585: debug : virUnrefConnect:232 : unref connection 0xbc6a60 1 17:35:13.585: debug : virReleaseConnect:191 : release connection 0xbc6a60 If I kill the libvirtd process on the server, the client then finally prints: error: authentication failed error: failed to connect to the hypervisor and the client then exits. Ok, this bit definitely sounds like a server side bug, unless perhaps there is some buffering taking place in ssh or nc causing the errore reply packet to not be send back promptly I'll try to get some better traces of what's going on here. The hang aside, it seems libvirtd should be using org.libvirt.unix.monitor for the readonly connection? In this case the problem is that the remote client end is using netcat on the wrong UNIX socket. Thanks, that's it. With the attached patch on the client side, virsh --readonly and virt-viewer work fine over qemu+ssh://. -jim --- libvirt-0.6.4-orig/src/remote_internal.c2009-05-29 10:55:26.0 -0400 +++ libvirt-0.6.4/src/remote_internal.c 2009-06-17 18:21:34.0 -0400 @@ -700,7 +700,10 @@ cmd_argv[j++] = strdup (priv-hostname); cmd_argv[j++] = strdup (netcat ? netcat : nc); cmd_argv[j++] = strdup (-U); -cmd_argv[j++] = strdup (sockname ? sockname : LIBVIRTD_PRIV_UNIX_SOCKET); + cmd_argv[j++] = strdup (sockname ? sockname : + (flags VIR_CONNECT_RO +? LIBVIRTD_PRIV_UNIX_SOCKET_RO +: LIBVIRTD_PRIV_UNIX_SOCKET)); cmd_argv[j++] = 0; assert (j == nr_args); for (j = 0; j (nr_args-1); j++) -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, 2009-06-17 at 21:32 +0100, Daniel P. Berrange wrote: How do you deal with IPv6 currently ? With lots of Aspirin (actually, not at all) I was thinking of sugesting an attribute ip type=ipv6 address=2001:23::2 prefix=24/ but I think its possibly better to have a different element name ip6 address=2001:23::2 prefix=24/ since the former would not work if we ever needed to worry about non-IP based addresses. Either works for me, with a slight preference for the first version, on purely esthetic grounds. And even if we go with that, there's nothing keeping us from adding an ipx element as an alternative to the ip element in the future. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, 2009-06-17 at 22:33 +0200, Daniel Veillard wrote: On Wed, Jun 17, 2009 at 01:27:14PM -0700, David Lutterkort wrote: I haven't declared the schema or the API stable yet, but I want to do that once there is a libvirt release out there that relies on netcf. So if there are any other issues with any of these aspects, raise them now or forever hold your peace. Well I'm writing the parser, so sure I will raise those :-) There is also a lot of suggested extensions from Jim Fehlig, but I think they all can be handled as extension from the original schemas. One thing which needs to be ironed out IMHO is IPv6, better clean this up now than later. I'm not a IPv6 fan but making sure the schemas is ready for it is important I guess. The comment about dhcp6 / should probably be decided before first release. The most important thing is that we do not need to break the schema in an incompatible way. Extensions can always be added later. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
