Re: [libvirt] libvirt modifying iptables rules
On Mon, 2010-03-08 at 23:02 +0100, Felix Schwarz wrote: > Am 07.03.2010 15:09, schrieb Varrun Ramani: > > I am right now undertaking a project which deals with verification of > > firewall rules. I wish to know which applications/libraries modify/query > > firewall rules. I came to know that libvirt modifies iptables rules. Can > > anyone let me know for what purposes/how libvirt modifies the rules? > > I suggest you look through the archives, the topic comes up pretty regularly. > > Bottom line: > - It should 'just work' for most users. > - iptables modification are considered safe, more complex setups are out of >scope for libvirt. How do you define 'safe' in this context ? David -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Avoid segv if ncf_init fails
On Tue, 2009-10-27 at 14:23 +, David Lutterkort wrote: > On Fri, 2009-10-23 at 20:31 +0100, Daniel P. Berrange wrote: > > On Fri, Oct 23, 2009 at 03:13:17PM -0400, Laine Stump wrote: > > > If ncf_init() fails, it takes responsibility to call ncf_close() when > > > appropriate. Having libvirt call it results in a double close, which > > > ends up segv'ing. > > > > Hmm, it would be good if ncf_init set the passed in pointer to NULL > > when it failed, then your existing cleanup check would have been > > safe. > > Agreed - that that doesn't happen was an oversight. I'll fix that. Spoke too soon - ncf_init returns -2 when allocations fail so badly that we can't even allocate the struct netcf (in which case ncf_init should reset the pointer to NULL, but doesn't - that's the bug that needs to be addressed) It can also return -1 for all kinds of other failures; in that case you have a struct netcf that's good enough to pass to ncf_error to get more error details. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Avoid segv if ncf_init fails
On Fri, 2009-10-23 at 20:31 +0100, Daniel P. Berrange wrote: > On Fri, Oct 23, 2009 at 03:13:17PM -0400, Laine Stump wrote: > > If ncf_init() fails, it takes responsibility to call ncf_close() when > > appropriate. Having libvirt call it results in a double close, which > > ends up segv'ing. > > Hmm, it would be good if ncf_init set the passed in pointer to NULL > when it failed, then your existing cleanup check would have been > safe. Agreed - that that doesn't happen was an oversight. I'll fix that. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Support for IPv6 / multiple ifaces in interface_conf.[ch]
On Mon, 2009-10-05 at 22:47 -0400, Laine Stump wrote: > On 10/05/2009 06:06 PM, David Lutterkort wrote: > > On Sun, 2009-10-04 at 22:58 -0400, Laine Stump wrote: > > > >> Note that netcf appears to not accept defining both ipv4 and ipv6 on > >> the same interface, and still can't report live config of IPv6 (or > >> multiple IPv4 addresses), so the usefulness of this patch is limited > >> until those items are fixed in netcf. > >> > > It does - you need to specify IPv4 addresses before IPv6; anything else > > that doesn't work in that area is a bug. This just worked for me: > > > > > That explains it. I stand corrected. I'm guessing it must be difficult > to remove that restriction? No, not difficult at all - I'll fix it up in the schema. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Support reporting live interface IP/netmask.
On Tue, 2009-10-06 at 14:17 -0400, Laine Stump wrote: > On 10/06/2009 01:36 PM, David Lutterkort wrote: > > On Tue, 2009-10-06 at 10:13 +0100, Daniel P. Berrange wrote: > > > >> The live XML should *always* say what the inteface is doing right > >> now. > >> > > And from the rest of this exchange, I think the word 'only' should be > > added to that sentence. In other words, the XML for live setups contains > > *only* what we have figured out from the live setup, completely > > disregarding config files - that also leaves us room to add more live > > info as we gather more. For example, the entire live XML for any > > interface will now look like > > > > > > > > > > > > > > > > Note that that doesn't even indicate the type of the interface (which we > > may add at some point, but since we do not have that info right now, we > > won't pretend we know what the interface is) > > > > > Interesting extrapolation. I can't say that I hadn't thought of it once > or twice, but figured it would be more convenient to have one-stop > shopping. (Also it will require a separate codepath for parse/format, > but maybe that's better anyway.) Not necessarily - you just have to be mindful when parsing/formatting that many things the schema says are mandatory are in fact optional. > Should I code this up and see how it flies? That's what I would do. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Support reporting live interface IP/netmask.
On Tue, 2009-10-06 at 10:13 +0100, Daniel P. Berrange wrote: > The live XML should *always* say what the inteface is doing right > now. And from the rest of this exchange, I think the word 'only' should be added to that sentence. In other words, the XML for live setups contains *only* what we have figured out from the live setup, completely disregarding config files - that also leaves us room to add more live info as we gather more. For example, the entire live XML for any interface will now look like Note that that doesn't even indicate the type of the interface (which we may add at some point, but since we do not have that info right now, we won't pretend we know what the interface is) David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Support for IPv6 / multiple ifaces in interface_conf.[ch]
On Sun, 2009-10-04 at 22:58 -0400, Laine Stump wrote: > Note that netcf appears to not accept defining both ipv4 and ipv6 on > the same interface, and still can't report live config of IPv6 (or > multiple IPv4 addresses), so the usefulness of this patch is limited > until those items are fixed in netcf. It does - you need to specify IPv4 addresses before IPv6; anything else that doesn't work in that area is a bug. This just worked for me: David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Support reporting live interface IP/netmask.
On Mon, 2009-10-05 at 17:34 +0100, Daniel P. Berrange wrote: > With the domain XML format, we did have a few abortive attempts at > indicating in the live XML, whether an attribute was from the > persistent config, vs dynamically added to live config, but it all > ended up as rather a mess. Here's a concrete example where this leads to headscratching, at a minimum, with the netowrk configs. When the live XML contains you at least think that the interface is configured to use DHCP, and currently has the indicated address. Of course, if we ever poke around to see if the interface _currently_ gets its address from DHCP, we have no way to indicate that anymore, since we would indicate 'configured to use DHCP' and 'currently gets its address from DHCP' in exactly the same way. Also, US $5 to anybody who knows whether the tag above says 'is configured to use that gateway' or 'routing is through that gateway right now'. To belabor this point, when the live XML says it's completely unclear what addresses are in the config files (maybe both?) and which ones are actually assigned to the interface right now. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Support reporting live interface IP/netmask.
On Mon, 2009-10-05 at 12:02 +0100, Daniel P. Berrange wrote: > On Tue, Sep 29, 2009 at 04:02:30PM -0400, Laine Stump wrote: > > From: root > > > > This patch adds the flag VIR_INTERFACE_XML_INACTIVE to > > virInterfaceGetXMLDesc's flags. When it is *not* set (the default), > > the live interface info will be returned in the XML. in particular, > > the IP address(es) and netmask(s) will be retrieved by querying the > > device directly, rather than just reporting what's in the config > > file. The backend of this is in netcf's new ncf_if_xml_state() > > function. > > > > Any live interface ip address info in the xml will have the property > > "source" set to "device", eg: > > > > > > This new 'source' attribute is bogus. The fact that the XML is the > showing the device details, and not the config file details is > inherent in the fact that we're querying the live interface. This > distinction applies to the entire XML dump, not just the tag. That's what I meant when I said 'I am not sure how this will be used in practice'. The options for this API call are (1) report configured and live setup side-by-side in the same XML, and mark the live setup somehow (e.g., with the source='device' attribute) (2) _only_ report live setup from this call, if you want configured setup use the VIR_INTERFACE_XML_INACTIVE flag. The advantage of (2) is that you can reuse any parsing/processsing code you might already have for the configured setup variant; the disadvantage is that you may have to handle the other variant's XML doc, too, and correlate the two. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Ignores EOPNOTSUPP when attempting to access an image on an NFS share.
On Thu, 2009-08-20 at 14:40 -0400, Darryl L. Pierce wrote: > rhbz#517157 > > Signed-off-by: Darryl L. Pierce > --- > src/security_selinux.c | 23 --- > 1 files changed, 16 insertions(+), 7 deletions(-) ACK. Looks good to me. You might want to check against ENOTSUP instead of EOPNOTSUPP, since the former is what setfilecon(3) documents, but it'll not make much of a difference in practice. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] hooking a physical nic to a bridge with net-create
On Sun, 2009-06-28 at 21:39 -0700, Shahar Klein wrote: > Correct me if I'm wrong but it seems that the vlan support is not in > netcf yet... That is correct, but it will land RSN. 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 Mon, 2009-06-22 at 10:50 +0100, Daniel P. Berrange wrote: > libvirt does not require that all functionality is present on > all platforms. So as long as an error is raised if the user > requests an unsupported configuration, we're fine. As for the > XML question, libvirt requires 100% backwards compatability so > its XML format is essentially "append" only, existing features > cannot be dropped/changed. This is also the intent for netcf's XML (warning: neither the XML format nor the API can be considered stable yet, but I hope that we get to that point very soon) As for backend differences, we definitely need to address them on a case-by-case basis, weighing the headache of dealing with different backends with different feature sets against the importance of that feature. 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 Fri, 2009-06-19 at 20:14 +0200, Daniel Veillard wrote: > On Fri, Jun 19, 2009 at 05:45:33PM +0000, David Lutterkort wrote: > > Agreed .. that format wouldn't help much with static checking. > > Okay, well I think the recursive definition is really the worse > for validation and processing. I think the nested format is the easiest to validate, and make sure we encode rules like "a bridge may not enslave another bridge" or "a bond can only enslave physical NIC's" Look at the picture[1] with the edges going into the vlan node removed - that's pretty much the structure of the RelaxNG. It's precise, and fairly simple. The main thing we are missing is a distinction between toplevel bond (may have an address) and enslaved bond (no address), similar to how the RelaxNG distinguishes between ethernet-interface and bare-ethernet-interface. David [1] https://fedorahosted.org/netcf/wiki/InterfaceNesting -- 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 Fri, 2009-06-19 at 10:47 +0100, Daniel P. Berrange wrote: > IMHO that results in a bad structure, because its anot associating > the related info together, eg having an separate element to turn > on/off IPV6, and then listing addresses: > > > > > > vs having the direct association > > > > > > > the latter removes the redundancy from specifying address family in > multiple places Ok .. I agree that we should have a container tag like that - we should probably call it though instead of ... other ipv6 specific settings ... 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 Fri, 2009-06-19 at 17:17 +0100, Daniel P. Berrange wrote: > On Fri, Jun 19, 2009 at 06:13:37PM +0200, Daniel Veillard wrote: > > On Thu, Jun 18, 2009 at 10:50:10PM +0000, David Lutterkort wrote: > > > On Thu, 2009-06-18 at 20:48 +0100, Daniel P. Berrange wrote: > > > > On Thu, Jun 18, 2009 at 07:05:29PM +0100, Daniel P. Berrange wrote: > > > > > > > > > > I think this is a really unpleasant format to deal with. IMHO there > > > > > should > > > > > not be nesting for / tags. They should just refer to > > > > > their > > > > > slave device by name. So that last example would be better shown as a > > > > > set > > > > > of independant intefaces > > > > > > > > Rationalizing the reason why I don't like this format. The relationship > > > > of > > > > NICs essentially forms a DAG. This format is attempting to define a tree > > > > from the POV of a single leaf node. > > > > > > They do form a tree, with the exception of VLAN's: every other instance > > > of an interface can be contained/used by at most one other interface. We > > > need to treat VLAN's a little special, and allow them to reference > > > external (to the XML) interfaces. > > > > Trying to digest that long discussion maybe there is a solution: > > > > - Dan thin a pure tree representation is not sufficient to express > > all relationships between interfaces > > - Dave would like to preserve the ability run the checks on a single > > XML instance > > > > I think both can be accomodated but that requires a slight change of > > API, i.e. the XML will be able to define a set of interfaces. Basically > > we could do > > Urgh, no I think that's even worse. I'd prefer either of the 2 options > we've currently discussed over that. Agreed .. that format wouldn't help much with static checking. 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 Fri, 2009-06-19 at 17:39 +0100, Daniel P. Berrange wrote: > Here is a proposal that is a compromise between the single hierarchy, and > completely flat. The break point is only introduced where VLANs appear, > which is acceptable because when defining VLAns, you don't need to define > the underlying inteface at the same time Yes, that's what I was getting at in one of my mails yesterday. All subordinate interfaces, except for VLAN's, are defined by including them at the one place where they are used (e.g., inside ); when using a VLAN as a subordinate interface, the VLAN interface itself is defined where it is used, but the interface underlying the VLAN interface is only referred to. Basically, by treating VLAN's akin to symbolic links, we do a have a clean tree structure for interface nesting. > There are 4 possible arrangements of physical NIC, bond and vlan, > each of which can use a bridge. This gives 8 total configs > > 1. Physical NIC > > 2. Physical NIC + bridge > > 3. Physical NIC + bond > > 4. Physical NIC + bond + bridge > > 5. Physical NIC + vlan > > 6. Physical NIC + vlan + bridge > > 7. Physical NIC + bond + vlan > > 8. Physical NIC + bond + vlan + bridge Agreed - these examples are in line with what I had in mind. The format for VLAN's is a bit problematic still; you have > > vlan42 > > > eth0 > > > but you can't really assign an arbitrary name to a VLAN interface; it's also not necessary to indicate the type of the base interface. Therefore, for VLAN's, I would use the much more concise notation David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Patch for Ruby Bindings to include attach & detach device
On Thu, 2009-06-18 at 12:31 +0200, Martin Gajdos wrote: > What this small patch does is, it adds two functions to call > "virDomainAttachDevice" & "virDomainDetachDevice" which allow devices > to be attached & detached at run-time. The Ruby methods are called > "attach_device" & "detach_device" and belong to the Domain class. Thanks for sending this - I just committed the patch. For extra credit, any chance I can get you to add a test to tests/tc_connect.rb that calls these methods ? 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 Thu, 2009-06-18 at 09:15 +0200, Jonas Eriksson wrote: > I am a bit critical to the policy restrictions of the current > incarnation of the netcf API. Currently, a interface (or > connection) has to have an IP address and a bridge has to have > one or more interfaces attached to it. Ok .. I relent ;) You and Dan have convinced me that those restrictions are bunk, and I'll change things to remove them - though patches that do that would be much appreciated. 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 Thu, 2009-06-18 at 18:10 +0100, Daniel P. Berrange wrote: > > I don't see that that buys us anything that we wouldn't have with > > > > > > > > > > > > > > If you do this, then you'll need an explicit element to turn on / off > IPv4 or IPv6 addressing for the inteface as whole. ie to stop the > automatic addition of a link-local address. That should be stated explicitly, not implied by having an empty tag. > By having the container, for each family, the prescense or not of the > container can define whether that address family is enabled for that > inteface. What would 'enabling an address family for an interface' do ? Whatever it does should probably be stated explicitly. The one argument for tags is that it makes it cleaner to bundle addressing info like and routing info, to make sure that the user doesn't specify ipv6 routes for an interface without ipv6 addresses. 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 Thu, 2009-06-18 at 20:48 +0100, Daniel P. Berrange wrote: > On Thu, Jun 18, 2009 at 07:05:29PM +0100, Daniel P. Berrange wrote: > > > > I think this is a really unpleasant format to deal with. IMHO there should > > not be nesting for / tags. They should just refer to their > > slave device by name. So that last example would be better shown as a set > > of independant intefaces > > Rationalizing the reason why I don't like this format. The relationship of > NICs essentially forms a DAG. This format is attempting to define a tree > from the POV of a single leaf node. They do form a tree, with the exception of VLAN's: every other instance of an interface can be contained/used by at most one other interface. We need to treat VLAN's a little special, and allow them to reference external (to the XML) interfaces. > An application using this, still retains the > flexibility to display the information in the structure that is most > suitable for its needs, be it paths from the POV of a leaf, paths from > the POV of a root, the entire tree in one, or flat lists, or some other > hybrid. I don't think that what an application can display is hindered by any of the formats we've been discussing. To me, the overriding concerns are (a) exposing as much as possible for static checks in the RelaxNG grammar and (b) avoid writing the representation in a way that causes undue headaches in some of the backends we'll eventually need, by assuming e.g. we can write out the config for a partial interface. > > > >bond0 > > > > > > > > > > > > So this shows children, while the XML for the physical interface could > show the inverse. The importnat thing is that it has parent/child relations going both ways in one place, and therefore is much less likely to cause headache, no matter whether the config backend writes its config files in a more child->parent oriented manner (like initscripts) or in a parent->child oriented manner (like Debian[1]) > >eth0 > > > > No; we need to come up with _one_ way to express 'bond0 consists of eth0 and eth1', not multiple ways. There's no value in that, only headache; enterprising souls are free to create alternate views of the XML with their favorite XSL stylesheet - something tha the nested representation makes easier. > The API contract might wish to specify the order for defining new > interfaces, eg whether to require the bond0 to be defined first > and then physical interfaces added, whether physical members must > be defined first & then the bond, or whether creation of the bon0 > automatically implies that interfaces for eth0/eth1 appear in the > list. If you do that, you require that netcf stores some data in some lookaside location - with your last example above, on Debian, nothing can be written to /etc/network/interfaces, until the actual bond device is defined. Also, what would it mean if bond0 already exists (say, bonding eth1 and eth2) and an interface is defined with the above XML snippet ? Do eth1 and eth2 stay in the bond ? If so, how do you get rid of eth2 in the bond ? David [1] http://wiki.debian.org/Bonding -- 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 Thu, 2009-06-18 at 19:05 +0100, Daniel P. Berrange wrote: > > Similarly, a bond enslaved to a bridge, together with a vlan on that > > bond also enslaved to the bridge would look like > > > > > > br0 > > ... > > > > > > bond0 > > > > > > eth1 > > > > > > eth0 > > > > > > > > > > > > > > I think this is a really unpleasant format to deal with. There's two reasons why I prefer that rather than splitting everything into multiple standalone tags: 1. When as many components of the overall interface/connection are in one place, more validation can be done in RelaxNG, i.e. statically 2. Because of this, it is easier for application writers to test and validate the XML they generate - most issues can be caught by validating against the RelaxNG, and fewer issues depend on doing things in the right order (for example, with the nested format, you cna never get into a situation where you enslave an undefined bond into a bridge) I assume what you find unpleasant is that when you generate the XML you need to embed one interface in another, though that seems to me mostly an issue in what order you do your sprintf's. > IMHO there should not be nesting for / tags. For , there's nothing to worry about, since all you can add to a bond are physical interfaces (since all the possible nesting gets confusing, I drew a little picture) vlans can't contain their underlying device, since there can be many vlan's used in multiple interfaces for a device. This is the one place in the format I suggested where we need an external reference check: we need to make sure that the interface underlying the vlan is already configured. Bridges, of course, are hopeless, since they are omnivorous. But again, with the nested format, all sanity checking can happen in RelaxNG, except for the referential integrity of vlan's. > They should just refer to their > slave device by name. So that last example would be better shown as a set > of independant intefaces > > >bond0 > > > > > This requires that you check that the interfaces named there are physical NIC's at runtime. > >bond0.42 > > > > I don't think there's a good case for setting the name of a VLAN explicitly. vconfig let's you choose from one of four naming modes, but I am not even sure it's worth exposing those in the XML. > >br0 >... > > > > At this point, you need to check that bond0.42 is defined, without any address setup. > If you added more vlans, then they just appear as more interfaces at > the top level I would really like to stick to a model where toplevel interfaces are the ones that aren't contained in other interface definitions anymore. 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 Thu, 2009-06-18 at 18:06 +0100, Daniel P. Berrange wrote: > On Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote: > > >We should allow standalone IPv4 and IPv6, or both. Each could either > > use DHCP or allow one or more IP address and routes. > > You need to have allow for IP adddresses & routes to be present even > when doing DHCP, because you need to discover what was auto-configured. That only makes sense when reading an existing config, with the meaning 'the interface uses DHCP when it is brought up, and has the following address currently assigned to it'; it makes no sense when using the XML to configure a device. I would prefer for that case a separate API call to ask for currently assigned addresses. > This is overly strict, because it does not allow for an interface > without any addresses - something you want todo if configuring a > bridge device just for guest traffic and do not want any IP on it > for the host. So just need to make both optional You can achieve the same by making interface-addressing optional where it is used. > Check out this preso for an overview if you dare. > > http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf Need to read that first. > The 'ip-addr' match rule will need separate rules for IPv4 vs IP6 > addresses, since the former use '.' as a seprator, while the latter > use ':'. The 'prefix-pattern' can be same, since its just a number The valid range for prefix-pattern differs, and we should therefore between the two. > VLANs are tricky, because you can define VLANs on a physical > inteface or a bond interface, and you then may want to also > add a bridge on top of a VLAN, eg take 2 physical NICs, eth0 > and eth1, here are some possible combes > > - One NIC for storage, another for host mgmt, and put > the guests all on VLANs > > eth0 -> br0IP addr used for storage > eth1 -> br1IP addr used for host mgmt > eth1.42 -> br1.42 IP addr, used to talk to guests > eth1.43 -> br1.43 No IP, guest traffic only > eth1.44 -> br1.44 No IP, guest traffic only I don't think that's the right notation, don't you mean 'eth1.42 -> br2' etc. ? > I think the currently approach of modelling bond, bridges and NICs > makes this a little hard, particularly if the netcf API only exposes > 'connections' and not interfaces, because some of these setups are > not really connections, only building blocks for 'n' other connections For that, you'd nest them where they are used, e.g. one connection to establish the base ethernet interface (that might not exist at all): eth0 and one for the bridge with a vlan enslaved: br0 ... Similarly, a bond enslaved to a bridge, together with a vlan on that bond also enslaved to the bridge would look like br0 ... bond0 eth1 eth0 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 Thu, 2009-06-18 at 16:06 +0200, Daniel Veillard wrote: > On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote: > > On Wed, Jun 17, 2009 at 10:59:20PM +0000, David Lutterkort wrote: > > > The problem with the propsal is that it opens the door to a variety of > errors like using the same familly twice, which I would like to avoid > at the RNG level but it's not trivial. An alternative is to drop the tag and just stick a type=ipv4|ipv6 attribute on the tags .. though that requirs that we do the same for tags, and I have no idea what routing in non-IP protocols looks like. >We should allow standalone IPv4 and IPv6, or both. Each could either > use DHCP or allow one or more IP address and routes. >I think if we have routes, at most one need to be a gateway and the > other ones having destination + prefix. > > So I suggest the following rewrite of interface-addressing > > > > > > > > > > > > Ok. > This allows one or 2 blocks of addresses ipv4, ipv6 or both > > > > > ipv4 > > > > > > > > > An IPv4 addresses block, allows for either static or dhcp > > > > > ipv6 > > > > > > > interface-addr-static and interface-addr-dhcp need to be split into ipv4 and ipv6 specific branches, so that we can typecheck that we don't use an ipv6 address in an ipv4 addressing block. Ultimately, that means we need ipv4 and ipv6 versions of ip-addr and prefix-pattern. > For DHCP the only option is the peerdns yes/no attribute There's a few more options we need to add for completeness, at least PERSISTENT_DHCLIENT, DHCPRELEASE, and DHCLIENT_IGNORE_GATEWAY are supported by initscripts. > And for routes we have at least one default route Default route should be optional. > This makes parsing a bit heavier, and I didn't checked if this really > affected bridging and bonding interfaces in a wrong way, but I think > that at least at an ethernet level definition this looks more complete. It only affects it in so far as interface-addressing is also used for the toplevel bridge/bond devices, which AFAIK is ok. > That said I have no idea how much of a problem it would be on the netcf > impletmentation side. I will find out ;) > P.S.: full rng attached, double check the prefix-pattern definition > I have no idea if it's sufficient for Ipv6 For ipv4, prefix is in the range 1..32, for ipv6, it's 1..128. 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 Thu, 2009-06-18 at 10:46 +0100, Daniel P. Berrange wrote: > On Wed, Jun 17, 2009 at 10:59:20PM +0000, David Lutterkort wrote: > > 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 > > > > > > > > > > > > but I think its possibly better to have a different element name > > > > > > > > > > > > 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 element as an alternative to the > > element in the future. > > Or a 3rd option is to group addresses by family > > > > > > > > > > > > > I don't see that that buys us anything that we wouldn't have with _maybe_ enclosed in a container tag, but I don't think that's needed. 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 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
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 > > > > but I think its possibly better to have a different element name > > > > 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 element as an alternative to the 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: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: > > > > > > > > > > > > > > > > > > > > > > > > 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: so that you'll write 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, 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: [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
[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] test driver for interface config
On Fri, 2009-04-10 at 11:47 +0100, Daniel P. Berrange wrote: > I'm afraid this isn't really going to fly. The libvirt public interface > is defined by C library API/ABI, and the XML format. To provide the > guarenteed stability & consistency of this interface across releases, > we need to have the XML parser & formatting included in libvirt & used > by all the driver impls. We used to have the situation where XML parsing > was delegated to individual drivers, but that ultimately caused us > painful inconsistency between drivers. Here though you're going excactly in the opposite direction: you will have two different validators that are in danger of diverging, when you could have just one. > Now in the case of the netcf impl for the interface APIs, things will > be nice & simple, because the incoming XML can be simply parsed & then > reformatted back into same schema. You don't even need to reformat - just pass the original string on. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] 802.1q vlan-tagging support for libvirt
On Tue, 2009-04-07 at 18:39 -0300, Klaus Heinrich Kiwi wrote: > I was thinking about the semantics I described above. It ultimately > means that we'll have a bridge for each VLAN tag that crosses the trunk > interface. So for example if guests A, B and C are all associated with > VLAN ID 20, then: > > eth0 -> eth0.20 -> br0 -> [tap0, tap1, tap2] > > (where tap[0-3] are associated with guests A, B, C respectively) Yes, I think that's how it should work; it would also mean that you'd first set up eth0 as a separate interface, and new bridge/vlan interface combos afterwards. AFAIK, for the bridge, only bootproto=none would make sense. > The things that concerns me the most are: > 1) How scalable this really is I don't know either ... we'll find out ;) > 2) The semantics are really different from how physical, 802.1q-enabled > switches would work. > > Because (2) really creates new switches for each new VLAN tag, I wonder > how management would be different from what we have today with physical > switches (i.e., defining a port with a VLAN ID, assigning that port to a > physical machine) - unless we hide it behind libvirt somehow. The reason we are creating all those bridges isn't the VLAN's - it's that we want to share the same physical interface amongst several guests. And I don't know of another way to do that. > Are there other options? Since a tagged interface like eth0.20 is kind > of a virtual interface itself, would it be appropriate to use those > directly? You can use it directly, I just don't know how else you would share it amongst VM's without a bridge. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] test driver for interface config
On Tue, 2009-04-07 at 16:35 +0100, Daniel P. Berrange wrote: > Even though its doing a passthrough to netcf library, the netcf driver > would still need to parse the XML in accordance with libvirt > defined schema. It just happens that netcf uses the same XML > format, so it can then convert it back into XML and pass it on > through to netcf. While that is still the case (libvirt interafce XML == netcf XML), it makes more sense to exercise as much of netcf as possible in the tests. The 'root' argument to ncf_init makes that possible, and if there are other things needed, we should add it to netcf, and exercise as many as the same code paths as non-test uses will as possible. > The test driver wouldn't call anything in netcf. It is intended to > be an entirely self-contained in-memory impl of the APIs with all the > semantics required by the public APIs. Given that the libvirt API is just pass-through for now, that would test much less of the 'live' code than we can and should exercise. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] test driver for interface config
On Tue, 2009-04-07 at 16:50 +0100, Daniel P. Berrange wrote: > The test impl needs to be within libvirt so it is always available no > matter whether netcf is available for the build, so it shouldn't use > netcf at all. For the time being though, netcf not being available also means that the virInterface calls won't do anything with any other driver, since there is no other driver impl. It makes more sense to me to use netcf during testing until there is a different implementation of the virInterface API - at that point that impl and the test driver will also be able to share a lot of code, so that we don't have lots of test-only code. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] test driver for interface config
On Tue, 2009-04-07 at 10:39 -0400, Laine Stump wrote:
> The former (call netcf) is problematic in that many netcf functions make
> changes to the real live network config (which I don't think is a very
> nice thing to have in test code, but maybe I'm being over-cautious) and
> netcf doesn't have provisions for a test mode where changes made to the
> config aren't committed.
The ncf_init call takes a 'root' argument which determines what netcf
considers the fs root ('/' by default) It won't ever touch files outside
of that root, i.e. you can use that to set up a sandbox.
There's one smallwrinkle in that it will run iptables unconditionally
(which fails if you don't run your tests as root) - but I could change
the code to not do that.
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] How to prevent libvirt from adding iptables rules?
On Mon, 2009-04-06 at 14:36 +0200, Ludwig Nussel wrote: > SuSEfirewall2 does not have such a mechanism and TBH I pretty much > dislike the idea of allowing applications to inject arbitrary rules. > I'd prefer some higher level abstraction so it's left to the > firewall to decide how to translate the request into actual iptables > rules (or whatever else technology is used in the background). How would that be done ? I don't know of any tool that could do that, especially given the large number of existing firewall mgmt tools out there (s-c-firewall, SuSEfirewall2, whatever Debian/Ubuntu have, shorewall, pyroman, ...) David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] 802.1q vlan-tagging support for libvirt
Hi Klaus, On Thu, 2009-04-02 at 15:50 -0300, Klaus Heinrich Kiwi wrote: > My understanding is that libvirt would use vconfig to create tagged > interfaces, while using a physical interface as trunk (e.g., eth0 is the > trunk, eth0.20 the interface with the '20' vlan tag). > > Then it would add the tagged interface (eth0.20) to a bridge with the > guest virtual interface. as Dan said, the actual functionality will be provided by netcf[1] VLAN is very high on the list of things that need to be done next - and any help with that would be much appreciated ;) David [1] https://fedorahosted.org/netcf/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] ANNOUNCE: netcf, a platform-agnostic library for network configuration
I am pleased to announce the availability of netcf 0.0.1, the initial release of a library for managing network configuration in a platform agnostic manner. If I were into code names, this would be the "what have you been waiting for" release. Netcf does its work by directly modifying the 'native' configuration files of the host it is running on; this avoids a whole class of problems caused by similar approaches that do network configuration behind the back of the native mechanisms. The API allows listing of configured interfaces, defining the configuration of an interface, retrieving the same (regardless of whether the interface was initially configured with netcf or not), and bringing interfaces up and down. This functionality is needed both by libvirt and NetworkManager, so it seemed only logical to move their common needs into a separate library. This release is mostly geared at soliciting feedback and sparking spirited reviews. In particular, the API is not stable yet (it will be with the release of netcf 0.1.0) Besides general comments, criticism and the customary praise, I am particularly interested in reviews on the following: * The API (barring any strong objections, I will declare it stable) * The XML schema for describing network interfaces (in data/xml/interface.rng) * General code review Where can I get it ? Main website https://fedorahosted.org/netcf/ A tarball can be downloaded from https://fedorahosted.org/released/netcf/ The git repo is at http://git.fedorahosted.org/git/netcf.git git clone git://git.fedorahosted.org/netcf.git For those running Fedora 10, I built some preliminary RPM's and made them available at http://people.redhat.com/dlutter/netcf/download/ (and if you are a Fedora reviewer, the review BZ is 493750 ;) How can I help ? Join the mailing list at https://fedorahosted.org/mailman/listinfo/netcf-devel Currently, netcf can set up simple Ethernet interfaces, bridges with enslaved physical devices and bonds on Fedora. This points to two areas where improvements are most needed: * support other Linux distros and operating systems * expand what kind of interfaces netcf can handle (most sorely needed are VLAN's and adding bonds to a bridge) If you can help with either of these two, or anything, really, drop a note on the mailing list so wecan discuss. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Fwd: first cut public API for physical host interface configuration]
On Tue, 2009-03-31 at 10:24 +0100, Daniel P. Berrange wrote: > Simply that if the admin configures a new NIC using DHCP / IPV6 they will > wish to know what address it got after it was brought online. libvirt > does not have todo anything with these addresses, merely provide info > about them in the XML for the interface. Applications using libvirt may > do stuff with the addresses, for example they may wish todo a direct > node<->node migration over an interface that's separate from the one > used for talking to libvirtd. As such they'd need to know the IP addr > of such an interface. This sounds very much like a job for DNS + DHCP with fixed MAC/IP mappings. libvirt might want to offer this IP lookup capability for adhoc setups, but it encourages very bad administration practices. > NB, I don't think this neccessarily has to be part of netcf library. My objection isn't so much to where this should live, as that it's unnecessary at best and wallpapers over broken setups/apps at worst. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Fwd: first cut public API for physical host interface configuration]
On Mon, 2009-03-30 at 12:40 +0100, Daniel P. Berrange wrote: > Well you'll need to be able to query live interfaces anyway, because > you'll need to be able to report IPv4 addresses assigned by DHCP and > report IPv6 addresses that auto-configure themselves. What's the use case behind that ? I would argue that any infrastructure that requires libvirt to get addresses of interfaces is fundamentally broken - I can see the case for getting the MAC address of interfaces on a host, but the MAC/IP address mapping really needs to be managed centrally. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Fwd: first cut public API for physical host interface configuration]
On Wed, 2009-03-25 at 19:59 +, Daniel P. Berrange wrote: > When 'virNetwork' talks about "defined" vs "active" interfaces > there are a few things to be aware of: > > - There is a concept of a persistent network. This is a network >which has a config file associated with it. > - There is a concept of a transient network. This is a network >which does not have any config file associated wit hit. For interfaces, I don't think it makes much sense to deal with transient interfaces, especially since implementing them would require that we reimplement the ifup functionality. > You can also have transient interfaces for which there is no > ifcfg-eth0 file. eg, if someone does 'brctl addbr foo' you > now have a transient interface which is active, but has no > config. But then you'd need to run dhclient or ifconfig agaonst foo etc. Transient interfaces get us to where we initially said we do not want to go: reimplementing a distro's network config scripts. > Typically name + UUID is sufficient > for most of our APIs. So given a virInterffacePtr you should be > able to lookup a corresponding netcf data structure based on either > UUID or name - whichever works best. Actually, UUID isn't so fun, since there's no place in the stock network config script to store it. For initscripts, we can just stick a NETCF_UUID or whatever variable into the interface config. On Debian, we would have to store that info in some lookaside file - and associate it by name with an interface, i.e. do something the application might as well do on its own. So I am not convinced that UUID is all that useful. > To support transient networks, there's also be a use case for an API > taking an XML file & calling ifup on the definition immediately > without writing out an ifcfg-XXX file. eg Unless somebody feels like reimplementing ifup, no transient interfaces. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] * qemud/libvirtd_qemu.aug: Add "security_driver".
On Tue, 2009-03-03 at 19:39 +0100, Jim Meyering wrote: > Daniel P. Berrange wrote: > > On Tue, Mar 03, 2009 at 05:43:28PM +0100, Jim Meyering wrote: > >> >From 0e79e00614e8c6cd2b7fe7bcad1d52b2de1a3a58 Mon Sep 17 00:00:00 2001 > >> From: Jim Meyering > >> Date: Tue, 3 Mar 2009 17:42:53 +0100 > >> Subject: [PATCH] * qemud/libvirtd_qemu.aug: Add "security_driver". > >> > >> --- > >> qemud/libvirtd.conf |4 ++-- > >> qemud/libvirtd_qemu.aug |2 +- > > > > If changing this, should also change qemud/test_libvirtd_qemu.aug > > so it validates the parsing of it. > > Hmm... rather than continue the duplication, > [qemud/test_libvirtd_qemu.aug has the entire content of src/qemu.conf > two times, first with double quotes escaped, second with curly braces] > > this patch makes it so test_libvirtd_qemu.aug is generated, Ugh .. I guess I really need to add a function to Augeas to read a string from a file. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Update on host interface configuration
On Fri, 2009-02-27 at 10:07 +0200, Dan Kenigsberg wrote:
> The real issue is, that in this stage, management may have lost
> connectivity to the node.
What exactly is the scenario here ? Are you trying to manage any old
node as long as it has libvirt installed ? As soon as you need any sort
of management-specific code on the node, you might as well implement the
logic below in your management code.
> > if (! newConfigIsWorking()) {
> > virInterfaceDefine(goodConfig);
> > virInterfaceRestart(ifaceName);
> > }
>
> How about having netcf/libvirt be aware of what is a goodConfig (with
> additional API verb), and back it up somewhere? Any change to to network
> configuration would have immediate effect, but unless explicitly set as
> "good", reverted on next boot.
While what you suggest will work in theory (with the minor caveat that
reverting to a "good" config can only be triggered by a restart of
libvirtd, not a reboot) it is a poor man's workaround for management
systems that do not provide proper failsafe functionality.
In particular, if you are part of the management system, you have a much
better idea (on the node) what it means to have a working network
configuration, and can recover from misconfigured network much more
gracefully than with the big hammer of a system reboot.
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 0/3: Run QEMU guests within a CGroup
On Thu, 2009-02-26 at 16:36 +, Daniel P. Berrange wrote: > Recent Linux kernels have a new concept of 'CGroups' which is a way to > group tasks on the system and apply policy to them as a whole. We already > use this in the LXC container driver, to control total memory usage of > things runing within a container. > > This patch series is a proof of concept to make use of CGroups in the > QEMU driver. The idea is that we have a 3 level cgroup hierarchy > > - Top level; contains the libvirtd daemon itself > - 2nd level: one per libvirt driver, but dos not contain any > processes. > - 3rd level: one per guest VM. Contains the QEMU process Why the separate group for the driver ? Do you see partitioning of resources by driver as an important requirement ? David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Update on host interface configuration
On Thu, 2009-02-26 at 12:40 -0500, Dan Williams wrote: > On Fri, 2009-02-13 at 09:12 +, Mark McLoughlin wrote: > > Hi David, > > > > Nice work ... > > > > A thought as I update this Fedora feature page[1], given that the goal > > of the feature could be described as fixing things so that the "shared > > physical device" section of libvirt's Networking wiki page[2] isn't so > > nasty and 'orrible. > > > > Aside from just writing out the interface configuration, will we also > > handle the case where NetworkManager is disabled/unavailable and > > manually bring up the interface with initscripts and update iptables? > > > > Also, will NetworkManager automatically notice the configuration > > changing on disk and apply the configuration? Will we be able to detect > > what configurations NetworkManager can handle? > > NM currently doesn't re-configure the connection on-the-fly when the > backing store (ie, ifcfg or gconf) changes, but the changes will get > applied the next time the connection is activated. The user (or some > other program) can certainly re-activate the connection after writing > out the bits to get the new settings applied. > > nm-system-settings would notice the changes via inotify, and read in the > new settings. Then, when the ActivateConnection method was called for > that specific connection, NM would re-activate it and apply the new > settings. Yes, that agrees with how I've been thinking about this: changing the config and bringing an interface/connection up/down are different operations. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] networking with two hosts
On Tue, 2009-02-24 at 14:25 +0100, Andreas Rittershofer wrote: > Task 1.) Each VM must have network access to each other VM and to the > outside. > Task 2.) When one host fails, all VMs are running on the remainig host > and 1.) must still be fulfilled. > > Does somebody has any hints about realising this scenario with libvirt > and KVM? What you want is a 'shared network interface'[1] David [1] http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Update on host interface configuration
On Tue, 2009-02-24 at 18:24 +0200, Dan Kenigsberg wrote:
> I know I'm arriving very late to this discussion and should have read
> it all before posting, but...
>
> The project I'm working on wanted to be able to setup network
> configuration without making persistant changes to configuration files.
> This would allow testing if everything works well, and reboot without
> fear if things got broken. The greatest fear when configuring network
> remotely, is being locked out of your host.
>
> Do you plan something like this feature in netcf?
No, not for netcf or libvirt. The host interface mgmt uses the
distribution's native network scripts, which implies that all config
changes are changes to those scripts.
The fundamental difficulty with providing some sort of rollback
functionality at the libvirt level is that libvirt has no idea whether
the new config is working or not, and doesn't know how to test it. So
any (syntactically valid) configuration of a network interface is as
good as any other from libvirt's POV.
That means that this type of functionality really belongs in a layer
above libvirt - the API (will) make it pretty easy though to implement
that: if you know that the current config for an interface is
good/working, just do something like
goodConfig = virInterfaceGetXmlDesc(..);
virInterfaceDefine(newConfig);
virInterfaceRestart(ifaceName);
if (! newConfigIsWorking()) {
virInterfaceDefine(goodConfig);
virInterfaceRestart(ifaceName);
}
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Update on host interface configuration
On Fri, 2009-02-13 at 09:12 +, Mark McLoughlin wrote: > A thought as I update this Fedora feature page[1] Thanks a ton for doing that - nice overview. > Aside from just writing out the interface configuration, will we also > handle the case where NetworkManager is disabled/unavailable and > manually bring up the interface with initscripts and update iptables? That side of the integration is still a little murky to me ... ideally, we wouldn't have to worry about whether NM is running or not, and just bring interfaces up independently, with NM noticing any changes - Dan W: does that sounds reasonable ? Also, to make a shared phys interface useful, we'd defintiely need to add the right --physdev-is-bridged rule, contradicting what I said elsewhere about modifying iptables ;) > Also, will NetworkManager automatically notice the configuration > changing on disk and apply the configuration? Yes, NM either needs to be told what files/dirs to look at so that it can set up its own inotify watches, or (preferrably) we'll need to let it register callbacks and do the inotify biz ourselves. > Will we be able to detect what configurations NetworkManager can handle? I am hoping we (i.e., libvirt) don't have to; though netcf will have to be taught how to deal with the interfaces that NM cares about and libvirt likely doesn't all that much (wireless) David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Update on host interface configuration
Hi, I thought I'd write an update of what I've been doing with the host interface configuration previously discussed[1] After talking with Dan Williams, who is working in NetworkManager, it is clear that the network interface functionality for libvirt is also useful for NM and would help them with handling system-wide interface configuration. To accomodate that, I will implement network interface configuration in a separate library (inspiringly called 'netcf', until somebody thinks of something catchier) and add public API to libvirt that will use netcf to do the actual work. One thorny issue is how libvirt's public API and netcf's public API relate to each other, especially since both libvirt and netcf use XML descriptions to describe network interfaces (netcf does that for exactly the same reasons that libvirt does it, since it will have to deal with similar stability issues) For the time being, I am assuming that the two XML descriptions are identical, with no guarantee that that will always be the case. If and when we run into a case where libvirt's and netcf's needs diverge, we'll break that identity. On the implementation side, that means that, for now, netcf will do all the validation and pass errors back to libvirt. In more concrete terms, I put up a git repo[2] for netcf. There's hardly any code in there, the things I'd particularly appreciate review/feedback on are * the RelaxNG specification of the interface XML (in xml/interface.rng) together with examples of such interface specifications (in tests/interface/) * the (very rough) sketch of the netcf public API, which should map almost 1-1 to the public libvirt API in src/netcf.h I know that the XML schema doesn't cover everything we've discussed in [1], but I think it's a small enough subset to tackle relatively quickly and large enough to be useful. So, one of the main things to think about when looking at the schema is places where the schema would make it hard to make desirable enhancements in the near future (like Marius' point about default routes/gateways) One important point about the model of network config in the schema is that it is centered around what NM calls a 'connection' (though it's called 'interface' in the schema): a grouping of the components that make up the interface the user really cares about (a bridge or a bond) together with the components subordinate to it (e.g. ethernet interfaces enslaved to the bridge or bond) It's those groups that netcf deals with, i.e. if eth0 is enslaved to br0, netcf won't list eth0 as an interface, but only br0, with eth0 as a subinterface. For the implementation, netcf will have a separate backend for each network configuration regime (initscripts for Fedora/RHEL, /etc/network/interfaces for Debian, ...) - once the initscripts backend is done, I'd be very grateful for contributions for the other backends. To sketch out the initscripts implementation, I wrote two XSL stylesheets, xml/initscripts-get.xml that goes from interface XML -> initscripts files (via Augeas) and xml/initscripts-put.xml to go the other way for querying; I'll use those for the core of the initscripts backend. Whether other backands can be done in a similar manner is TBD. David [1] https://www.redhat.com/archives/libvir-list/2009-January/msg00350.html [2] http://git.et.redhat.com/?p=netcf.git;a=tree -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] iptables and libvirt
On Fri, 2009-02-06 at 13:36 -0500, Karl Wirth wrote: > What if we could flexibly change the iptables rules for the different > guests as they are deployed onto the node/host. The idea would be to do > all of this within the iptables of the host leaving alone the iptables > of the guests themselves. The first issue with this is that the host does not know the IP addresses in use by the guests; it might be possible to work around that with setting up rules matching on bridge ports in some cases. Secondly, network devices may be directly assigned to guests - in that case, we won't even see any of the packets the guest sends or receives. I also don't see how you can implement that in the general case, given what a management nightmare iptables is. The trouble is that in a general libvirt installation, we could have arbitrary iptables rules in effect that are not controlled by libvirt. To reliably say, for example, that we reliably block all ports for VM x, we'd either need to understand all the existing iptables rules, or insert our rules first in the appropriate chains and be confident that they will never conflict with any other manually set up rules. It would be nice to do this, to offer an additional layer of security, especially around insecure OS's; to pull that off in practice, you'd need to assume fairly tight control of the host (e.g., only use shared network interfaces, only deal with iptables rules set up by a known application) With that, iptables management belongs into a higher-level management app, like ovirt, not libvirt. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Mon, 2009-02-02 at 10:59 +0100, Marius Tomaschewski wrote: > > >For now, I want to stay out of setting up static routes, but I think > > >that has to come sooner or later. > > It is OK to limit routes to the default route for now, but IMO > it is better to use separate xml nodes, e.g.: > > > and something like: > # implicit destination=default > > > rather than mixing the gateway into the IP address related attributes: > > netmask="255.255.255.0"/> > > because as soon as you start to support static routes, there are two > nodes/places where the default gateway can be defined. Yeah, that's a good catch; I'll change the schema accordingly. > Another way would be to say, there is either no STP parameter at all > (and use always stp="off" + fowarddelay=0) or only the STP parameter > and the backend implementation has to handle the another parameters > and write them "using real world defaults" into the ifcfg file. A third option would be to allow specifying parameters that only _some_ backends support, and produce an error, e.g. if you try to set maxage on Fedora. We don't necessarily have to support only the lcd. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Thu, 2009-01-29 at 13:34 -0800, Kaitlin Rupert wrote: > Mark McLoughlin wrote: > > > >>> I don't think we want to define a bridge here, but more that an > >>> interface is shared - i.e. this is a property of eth2. > > > > Note this line. > > > >>> The main concern is that this is the way I'd expect NetworkManager to > >>> support it - i.e. that you could configure NetworkManager to share eth0, > >>> rather than ask it to create br0 and add eth0 to it. > >>> > >>> If you just want to create a bridge, you can creati a virtual network. > > Sorry to chime in so late... the virtual network support only allows > the user to define bridges with NAT/routed forwarding. I tripped over this the first time, too; to put words in Mark's mouth, he meant 'bridge' here in the sense of a 'vritual network'. He calls a bridge with one enslaved physical NIC a 'shared network interface' (and doesn't much care for bridges with more NIC's ;) After talking to NM people, there doesn't seem to be a concern with NM compat - they are fine with the more explicit representation of a bridge. > Would the still behave as a virtual network pool in this case? If > multiple guests are tied to the same bridge, it would be useful to > represent this as some kind of pool or grouping. Not sure what you mean here ... with all this, you'd still set your guests up the way you do today, with appropriate sources for their network interfaces, e.g. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] setting up dnsmasq options for PXE boot
On Thu, 2009-01-22 at 15:20 +, Daniel P. Berrange wrote: > On Thu, Jan 22, 2009 at 03:12:39PM +, Richard W.M. Jones wrote: > > On Tue, Jan 20, 2009 at 02:05:26PM +0300, Dmitry Guryanov wrote: > > > But for working PXE boot it should have also something like > > > --dhcp-boot=pxelinux.0,itchy,192.168.107.1 > > > > This isn't supported by libvirt at the moment, but it would great to > > have a patch which enabled this. PXE-booting using dnsmasq is very > > reliable, and there's no particular reason why we shouldn't support > > it. > > Well the virtual network stuff is local to the host only, and so it > is even more reliable if you just boot the guest in question from > the kernel+initrd directly, instead indirectly giving it the kernel+ > initrd via a dodgy PXE server. > > We have a hammer, but I don't think we should use it in this case. When you NAT the virtual network to the outside world (like Dmitry does), there's no reason why the TFTP part of a PXE boot should not work. And if you're on a laptop, connected to a network with a working TFTP server, I don't see why you should have to screw around with kernel +initrd. I always felt it's a mistake to work so hard to hide the actual dnsmasq config from users - it would be much more extensible if we plonked a config file into /etc/dnsmasq.d David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Tue, 2009-01-20 at 11:35 -0700, Jim Fehlig wrote: > David Lutterkort wrote: > > For certain applications, we want libvirt to be able to configure host > > network interfaces in a variety of ways; currently, we are most > > interested in teaching libvirt how to set up ordinary ethernet > > interfaces, bridges, bonding and vlan's. > > > > Below is a high-level proposal of how that could be done. Please comment > > copiously ;) > > > > 1. XML Format > > = > > > > The first question is how the user would describe the host interfaces they > > want. Below are some sketches of what an XML representation of the various > > kinds of interfaces would look like. This covers the minimal amount of > > settings for these to be useful, though I am sure we'll need to add more > > over time. > > > > > > 00:19:d2:9f:88:96 > > > > > > > > For onboot="yes", something like startmode="onboot" would be better > IMO. A startmode attribute would allow also using "manual", "hotplug", > "ifplug", "nfsroot", etc. This makes only sense if these additional modes are completely orthogonal; I am not sure what the start modes 'manual', 'ifplug', and 'nfsroot' should do. For onboot, I assume you mean that they translate into assignments in ifcfg in the following way no startmode attribute -> ONBOOT=no startmode='onboot' -> ONBOOT=yes startmode='hotplug' -> ONBOOT=yes and HOTPLUG=yes > WRT dhcp element, would it make sense to consider hostname (hostname to > send to server) and if to change the local hostname to the hostname > delivered via dhcp? E.g. > hostname="foo" (default `hostname`) > sethostname > > Also route: > setrouting (default "yes") > setdefaultroute (default "yes") > > and NIS: > nis (default "yes") > setnisdomain (default "yes") Yes, they all make sense, though I would probably not support them in the very first cut. > What about dhcpv6? A separate element? Yeah, we probably need a separate element for that since it pulls in a slew of other config options. > > > > 00:19:d2:9f:88:97 > >> netmask="255.255.255.0"/> > > > > > > Similarly, support for IPv6 here. Either 2 formats: > > ipaddr="192.168.0.5" netmask="255.255.255.0" > ip6addr="2001:DB8:C::5/64" > > or allow /len for both: > > ipaddr="192.168.0.5/24" > ipaddr="2001:DB8:ABCD::1/64" Looks a little strange, but it would simplify notation. > As for routing info, how about a separate route element: > > # destination=default > > > > # unrecheable route (loopback) > > It would perhaps make sense to use iproute2 names, that is prefix > instead of destination and nexthop instead of gateway. For now, I want to stay out of setting up static routes, but I think that has to come sooner or later. > Don't recall if this was already brought up, but need a way to specify > MTU and perhaps ethtool settings as well. Yeah, that is definitely needed. > > > > 00:19:d2:9f:88:98 > > > > > > > > > > > > > > > > In addition to mode attribute for bonds, support for miimon, > arp_interval, and arp_ip_target? Sure .. if the initscript suports it, it's easy enough to do ;) > > > > > > > > > > > > Attributes to support hellotime, forwarddelay, and maxage? This would allow > ..> My main concern with these is that only forwarddelay, stp, and gcint are controllable by Fedora/RHEL networking scripts. For hellotime and maxage, we'd need to hook into the various ifup scripts atthe right place. Are these directly supported by the SuSe infrastructure ? David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, 2009-01-16 at 13:49 +, Daniel P. Berrange wrote: > On Fri, Jan 16, 2009 at 09:00:16AM +, Mark McLoughlin wrote: > > > > The thing is, this has to integrate with existing configuration - > > there's no point in futzing about with "ip link set eth0 ..." if the > > user has configured eth0 with NetworkManager or the distro's networking > > scripts. > > Yes, I think option 2 is pretty much doomed to fail. If you don't > integrate with the native distro mgmt scripts, or with NetworkManager > then you are forever going to have a fight between who's managing > what. You can already see this with Xen's network-bridge script > which cna be considered option 2. If you restart your network using > the distro scripts, after Xen's network-bridge script has run, then > you end up wwith a completely trashed host network. That goes for pretty much any config munging task - don't ever change the canonical place where config data is stored; for network devices that's dictated by the distro. Whatever we do for libvirt can only ever be an (updatable) view of that data. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
Hi Mark, On Fri, 2009-01-16 at 09:00 +, Mark McLoughlin wrote: > Hi David, > > On Fri, 2009-01-16 at 01:13 +0000, David Lutterkort wrote: > > > > > > > > > > > > > > > > > > > > > > I don't think we want to define a bridge here, but more that an > interface is shared - i.e. this is a property of eth2. > > The main concern is that this is the way I'd expect NetworkManager to > support it - i.e. that you could configure NetworkManager to share eth0, > rather than ask it to create br0 and add eth0 to it. > > If you just want to create a bridge, you can creati a virtual network. Is it possible to use DHCP to configure the bridge device itself using that, similar to what's described in [1] ? And have guest's DHCP requests forwarded across the bridge ? The docs only talk about static IP assignments for the bridge device. > > > > I think these last three are also interfaces and should be described > with an tag e.g. Agreed. > I don't think I like this much - these APIs manage a "virtual network" > which I see as a distinct concept from configuring host hardware. > > Really, I think keeping the two things separate will actually reduce > confusion in the long run. Agreed. > This sounds good, but "interface" is pretty damn generic :-) > > virNetInterface > virNetDevice > ... Sure, virInterface is pretty generic; maybe virNetDevice, though we'd have to call it in the XML for consistency. Naming is NP-hard ;) > What I don't like about any of these is that I've always imagined we > might add further APIs to libvirt for changing a domain's configuration > without munging XML e.g. > > int virDomainGetInterfaces(virDomainPtr domain, > virInterfacePtr interfaces, > int *ninterfaces); > int virInterfaceSetMacAddress(virInterfacePtr interface, > const uint8_t mac[6]); > > So, you can see the potential namespace conflicts ... Not really, since this still follows the naming convention 'vir' + class_name + method_name. There's a virDomainInterfaceStats, and it doesn't seem all that confusing to me to distinguish that from a virInterfaceStats (i.e. stats for all interfaces on the host) > > 3. Implementation > > = > > > > Configuring network interfaces is highly OS and OS-variant/distro > > dependant. There are at least two different ways how libvirt can go about > > modifying the host to create interfaces: > > > > 1. Modify the system's network setup scripts (ifcfg-XXX on RH) > > > > 2. Directly use the system's network utilities like ifconfig > > > > 3. Rely on NetworkManager (not an option right now, as NM doesn't know > > about bridges and the like) > > It has to be an option - even if it only supports a subset of what the > other options support. > > I really wouldn't like to see us push ahead with this until we have a > plan for how this will work with NetworkManager (and a rough agreement > for how future support for bonding etc. in NetworkManager might be > configured) Yeah, I started talking to Dan Williams about their plans etc. Of course, their main use case (wireless networking) is unimportant for libvirt. But we should be able to find a way to share some of the backend bits and the general model for interfaces, umm, net-devices ;) > The thing is, this has to integrate with existing configuration - > there's no point in futzing about with "ip link set eth0 ..." if the > user has configured eth0 with NetworkManager or the distro's networking > scripts. Agreed. > > If we want 'autostart' for an interface to mean 'bring up the interface > > as soon as the system boots', we are pretty much forced to go with > > option (1). > > Why? Because those are what brings up networking at boot - otherwise we'd define 'autostart' as 'whenever libvirtd starts' - but it doesn't seem like nay of this is controversial, anyway. David [1] http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, 2009-01-16 at 15:06 +, Daniel P. Berrange wrote: > On Fri, Jan 16, 2009 at 01:13:18AM +0000, David Lutterkort wrote: > > From a style point of view I'd prefer these to all have the same > top level XML element name, and use type='phys|bond|vlan|bridge' > attribute for distinction, since this follows the pattern we use > in the XML for other objects we describe. Type speciic sub-elements > can be used where there are specific extra metadat pieces we need > for that type. Agreed - I initially thought you couldn't describe that with Relax-NG (element content being completely different depending on the value of an attribute), but found out that you actually can do that. > I think the fact that the XML description of the devices is quite > different, and the underling impl will be quite different, suggests > that re-using existing APIs is not worthwhile. Agreed - that seems to be the consensus. > > * Do we expect interfaces to be in a specific state before we create them > > or do we just tear them down and reconfigure them no matter what ? > > I think we should expect the mgmt app to have put the device > in suitable state. eg, if you're creating a bridge containing > eth0, we should expect that the eth0 has been taken offline > already. What's the mgmt app in this context ? I am thinking that if you tell libvirt to change the config of eth0, it should just nuke whatever config it may already have. > > * Are there crucial config options that are not covered by the sketches > > above (e.g., setting an explicit MTU) ? Are there things in the XML > > sketches above that will be impossible to implement on some OS ? > > There are almost certainly things we won't be able to implement for certain > backends. XenAPI's API does not allow for VLANs for example. This brings up an important wrinkle: selection of the 'interface' driver will mostly be independent of the HV, since it depends more on the OS/distro you are running as your host than on your HV. I've been hoping we could just sidestep Xen's network handling altogether and just focus on doing the right thing for the host platform, regardless of HV. Since we need that for kvm anyway, dealing with the networking part of Xen would just add redundant driver implementations. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, 2009-01-16 at 03:29 +, John Levon wrote: > On Fri, Jan 16, 2009 at 02:59:17AM +0000, David Lutterkort wrote: > > > I am not disagreeing with you, but either way, libvirt needs _some_ way > > to control host interfaces. > > This is far from obvious to me. Could you explain more? The reasoning goes - similar to what Mark said - something like: virtualization is concerned with splitting up the physical resources of a host and presenting them as virtual resources to guests. Physical resources are (at a minimum) CPU, memory, storage and networking; in order to split up resources, we need very fine-grained and low-level control over them - we have that in libvirt for CPU and memory (via the hypervisor) and for storage through libvirt's storage API. Adding API to control host interfaces rounds that picture out by adding fine-grained control for the last major physical resource libvirt isn't managing yet. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: configuring host interfaces with libvirt
On Fri, 2009-01-16 at 01:26 +, John Levon wrote: > On Fri, Jan 16, 2009 at 01:13:18AM +0000, David Lutterkort wrote: > > > * Should this even be done as part of libvirt ? It seems like a very > > generic network config tool, and libvirt merely the conduit to exposing > > this through an API, most importantly, a remotable API. > > My humble opinion would be "no". This argument equally applies to > everything you could configure on a host, and I don't think anyone wants > to turn libvirt into libmanagement. Would it be feasible for libvirtd to > have a 'passthrough' mode that feeds unknown stuff off to some other > daemon? > > Especially in this case - interface management is very complex as you > note. I am not disagreeing with you, but either way, libvirt needs _some_ way to control host interfaces. And seeing how there are no tools that do something like the above in a portable way, it seems worthwhile, too. The question is probably more whether some of this functionality should be split out in a way that can be used independenty of libvirt. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] RFC: configuring host interfaces with libvirt
For certain applications, we want libvirt to be able to configure host
network interfaces in a variety of ways; currently, we are most
interested in teaching libvirt how to set up ordinary ethernet
interfaces, bridges, bonding and vlan's.
Below is a high-level proposal of how that could be done. Please comment
copiously ;)
1. XML Format
=
The first question is how the user would describe the host interfaces they
want. Below are some sketches of what an XML representation of the various
kinds of interfaces would look like. This covers the minimal amount of
settings for these to be useful, though I am sure we'll need to add more
over time.
00:19:d2:9f:88:96
00:19:d2:9f:88:97
00:19:d2:9f:88:98
All of these should also allow a element for specifying a uuid; I
omitted that for brevity.
2. API Changes
==
There are two options for dealing with network interfaces: (1) use the
existing virNetwork* calls or (2) add completely new API calls.
Repurposing existing virNetwork* calls
--
The existing calls map well to the operations we need for managing
interfaces, with a few exceptions:
- virNetworkGetAutostart/SetAutostart: depending on how we implement all
this (see below), 'autostart' might actually mean 'on boot', not 'when
libvirtd starts'
- virNetworkGetBridgeName doesn't make sense for interfaces, and should
return NULL for interfaces
We'll probably also end up adding some functions to query details about an
interface, in particular, a call to see what kind of network/interface a
virNetworkPtr represents
Add completely new virInterface* calls
--
This would add roughly the same API calls as the virNetwork* calls,
i.e. we'd have something like
typedef struct virInterface *virInterfacePtr;
int virInterfaceCreate(virInterfacePtr);
virInterfacePtr virInterfaceCreateXML(..);
...
plus some calls to extract information from a virInterfacePtr
The second option seems cleaner to me and easier to implement, and avoids
any subtle changes in the behavior of existing API, though I don't like
that we'll be adding another 20 or so calls to libvirt's public API, with
attendant churn both in the drivers and in virsh.
3. Implementation
=
Configuring network interfaces is highly OS and OS-variant/distro
dependant. There are at least two different ways how libvirt can go about
modifying the host to create interfaces:
1. Modify the system's network setup scripts (ifcfg-XXX on RH)
2. Directly use the system's network utilities like ifconfig
3. Rely on NetworkManager (not an option right now, as NM doesn't know
about bridges and the like)
Option (1) saves us from replicating every bit of network setup
functionality that those scripts already have - besides configuring the
interface, we also might have to setup routes, run dhclient etc.
Option (2) would require far fewer backend implementations than (1) - we
should be able to get away with one implementation for Linux, rather than
one for Fedora/RHEL, one for Debian, one for SuSe, three for gentoo
etc.
If we want 'autostart' for an interface to mean 'bring up the interface
as soon as the system boots', we are pretty much forced to go with
option (1).
All in all, option (1) seems more attractive, since it should save us from
dealing with a lot of low-level details of network setup, and the distro
scripts should be much better integrated with the rest of the system than
what we come up with for libvirt.
4. Misc issues
==
* Should interfaces have labels/roles ('data-interface') to help admins
make sense of the current config ?
* Do we expect interfaces to be in a specific state before we create them
or do we just tear them down and reconfigure them no matter what ?
* Are there crucial config options that are not covered by the sketches
above (e.g., setting an explicit MTU) ? Are there things in the XML
sketches above that will be impossible to implement on some OS ?
* Should this even be done as part of libvirt ? It seems like a very
generic network config tool, and libvirt merely the conduit to exposing
this through an API, most importantly, a remotable API.
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 5/5] read saved vm status on libvirtd startup
On Fri, 2008-12-12 at 23:21 +0100, Guido Günther wrote: > On Fri, Dec 12, 2008 at 08:30:26PM +, Daniel P. Berrange wrote: > > This is crying out for us to write a virASprintf() that explicitly > > always sets path = NULL upon failure. And then blacklist 'asprintf' > > in make syntax-check. > Possible virAsprintf attached. I've already moved the posted patch > series over to it. I'll blacklist it once this is in and we have more > calles moved over. O.k.? ACK .. very nice. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 5/5] read saved vm status on libvirtd startup
On Fri, 2008-12-12 at 19:27 +0100, Guido Günther wrote:
> diff --git a/src/qemu_driver.c b/src/qemu_driver.c
> index d8b87e4..57a396c 100644
> --- a/src/qemu_driver.c
> +++ b/src/qemu_driver.c
> @@ -183,6 +183,46 @@ qemudAutostartConfigs(struct qemud_driver *driver) {
> }
>
>
> +static int
> +qemudGetProcFD(pid_t pid, int fdnum)
> +{
> +int fd;
> +
> +#ifdef __linux__
> +char *path = NULL;
> +
> +if (!asprintf(&path, "/proc/%d/fd/%d", pid, fdnum)) {
> +qemudReportError(NULL, NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
> +return -1;
> +}
One more use of asprintf that needs to set path = NULL on error.
Cheers,
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/5] save domain status during vm creation and remove it on shutdown.
On Fri, 2008-12-12 at 19:27 +0100, Guido Günther wrote:
> diff --git a/src/qemu_driver.c b/src/qemu_driver.c
> index 7804094..d8b87e4 100644
> --- a/src/qemu_driver.c
> +++ b/src/qemu_driver.c
> @@ -182,6 +182,44 @@ qemudAutostartConfigs(struct qemud_driver *driver) {
> virConnectClose(conn);
> }
>
> +
> +/**
> + * qemudRemoveDomainStatus
> + *
> + * remove all state files of a domain from statedir
> + *
> + * Returns 0 on success
> + */
> +static int
> +qemudRemoveDomainStatus(virConnectPtr conn,
> +struct qemud_driver *driver,
> +virDomainObjPtr vm)
> +{
> +int rc = -1;
> +char *file = NULL;
> +
> +if (asprintf(&file, "%s/%s.xml", driver->stateDir, vm->def->name) < 0) {
> +qemudReportError(conn, vm, NULL, VIR_ERR_NO_MEMORY,
> + "%s", _("failed to allocate space for status
> file"));
> +goto cleanup;
> +}
This needs to set file = NULL on error. (Praise the joy that is
asprintf)
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/5] write pid file into stateDir
On Fri, 2008-12-12 at 19:26 +0100, Guido Günther wrote:
> diff --git a/src/qemu_driver.c b/src/qemu_driver.c
> index ca96223..a2e573e 100644
> --- a/src/qemu_driver.c
> +++ b/src/qemu_driver.c
> @@ -220,6 +220,10 @@ qemudStartup(void) {
>
> if ((base = strdup (SYSCONF_DIR "/libvirt")) == NULL)
> goto out_of_memory;
> +
> +if (asprintf (&qemu_driver->stateDir,
> + "%s/run/libvirt/qemu/", LOCAL_STATE_DIR) == -1)
> +goto out_of_memory;
You need to explicitly set qemu_driver->stateDir to NULL if asprintf
fails, since it leaves the pointer in an undefined state.
> +
> +if (asprintf (&qemu_driver->stateDir,
> + "%s/run/libvirt/qemu/", base) == -1)
> +goto out_of_memory;
> +}
Same here
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virConnectGetHostname: return a fully qualified hostname
On Thu, 2008-12-11 at 10:29 +, Daniel P. Berrange wrote: > ACK to the rest of the patch - particularly the removal of all those > duplicated impls ! I would have liked to have just one impl of virConnectGetHostname that does the whole gethostname dance, but each driver uses slightly different ways to report errors, and I didn't feel like getting into that for this simple change, though it should definitely be simplified. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virConnectGetHostname: return a fully qualified hostname
Here is a revised patch that addresses all the comments from Jim and
Dan:
* Use getaddrinfo instead of gethostbyname
* Terminate hostname explicitly with NUL_TERMINATE
* Do not repeat constant HOST_NAME_MAX+1
* Use tabs, not spaces in libvirt_sym.version.in
David
>From 65bee217eb80a3be39f80a7c229305180e5786c6 Mon Sep 17 00:00:00 2001
From: David Lutterkort
Date: Wed, 10 Dec 2008 18:34:39 -0800
Subject: [PATCH] virConnectGetHostname: return a fully qualified hostname
Instead of doing the equivalent of 'hostname', do 'hostname --fqdn',
i.e. try to qualify the local host name by an additional call to
getaddrinfo(3)
---
src/libvirt_sym.version.in |1 +
src/qemu_driver.c | 16
src/test.c | 16 +---
src/uml_driver.c | 15 ---
src/util.c | 33 +
src/util.h |2 ++
src/xen_unified.c | 15 +--
7 files changed, 54 insertions(+), 44 deletions(-)
diff --git a/src/libvirt_sym.version.in b/src/libvirt_sym.version.in
index de0bc4a..71a47b7 100644
--- a/src/libvirt_sym.version.in
+++ b/src/libvirt_sym.version.in
@@ -594,6 +594,7 @@ libvirt_priva...@version@ {
virFileReadLimFD;
virFileReadPid;
virFileLinkPointsTo;
+ virGetHostname;
virParseNumber;
virRun;
virSkipSpaces;
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 5f6fbd1..d6b7515 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -1562,23 +1562,16 @@ cleanup:
static char *
qemudGetHostname (virConnectPtr conn)
{
-int r;
-char hostname[HOST_NAME_MAX+1], *str;
+char *result;
-r = gethostname (hostname, HOST_NAME_MAX+1);
-if (r == -1) {
+result = virGetHostname();
+if (result == NULL) {
qemudReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
"%s", strerror (errno));
return NULL;
}
/* Caller frees this string. */
-str = strdup (hostname);
-if (str == NULL) {
-qemudReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
- "%s", strerror (errno));
-return NULL;
-}
-return str;
+return result;
}
static int qemudListDomains(virConnectPtr conn, int *ids, int nids) {
@@ -4249,4 +4242,3 @@ int qemuRegister(void) {
virRegisterStateDriver(&qemuStateDriver);
return 0;
}
-
diff --git a/src/test.c b/src/test.c
index 257fc8a..cb623ed 100644
--- a/src/test.c
+++ b/src/test.c
@@ -651,22 +651,16 @@ static int testGetVersion(virConnectPtr conn
ATTRIBUTE_UNUSED,
static char *testGetHostname (virConnectPtr conn)
{
-int r;
-char hostname [HOST_NAME_MAX+1], *str;
+char *result;
-r = gethostname (hostname, HOST_NAME_MAX+1);
-if (r == -1) {
+result = virGetHostname();
+if (result == NULL) {
testError (conn, VIR_ERR_SYSTEM_ERROR, "%s",
strerror (errno));
return NULL;
}
-str = strdup (hostname);
-if (str == NULL) {
-testError (conn, VIR_ERR_SYSTEM_ERROR, "%s",
- strerror (errno));
-return NULL;
-}
-return str;
+/* Caller frees this string. */
+return result;
}
static int testGetMaxVCPUs(virConnectPtr conn ATTRIBUTE_UNUSED,
diff --git a/src/uml_driver.c b/src/uml_driver.c
index 408096e..52a4e5b 100644
--- a/src/uml_driver.c
+++ b/src/uml_driver.c
@@ -1150,23 +1150,16 @@ cleanup:
static char *
umlGetHostname (virConnectPtr conn)
{
-int r;
-char hostname[HOST_NAME_MAX+1], *str;
+char *result;
-r = gethostname (hostname, HOST_NAME_MAX+1);
-if (r == -1) {
+result = virGetHostname();
+if (result == NULL) {
umlReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
"%s", strerror (errno));
return NULL;
}
/* Caller frees this string. */
-str = strdup (hostname);
-if (str == NULL) {
-umlReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
- "%s", strerror (errno));
-return NULL;
-}
-return str;
+return result;
}
static int umlListDomains(virConnectPtr conn, int *ids, int nids) {
diff --git a/src/util.c b/src/util.c
index da26009..c5e406b 100644
--- a/src/util.c
+++ b/src/util.c
@@ -47,6 +47,7 @@
#ifdef HAVE_PATHS_H
#include
#endif
+#include
#include "virterror_internal.h"
#include "logging.h"
@@ -1306,3 +1307,35 @@ int virDiskNameToIndex(const char *name) {
return idx;
}
+
+#ifndef AI_CANONIDN
+#define AI_CANONIDN 0
+#endif
+
+char *virGetHostname(void)
+{
+int r;
+char hostname[HOST_NAME_MAX+1], *result;
+struct addrinfo hints, *info;
+
+r = gethostname (hostname, sizeof(hostname));
+if (r == -1)
+return NULL;
+NUL_T
[libvirt] [PATCH] virConnectGetHostname: return a fully qualified hostname
The attached patch makes virConnectGetHostname try a little harder to get a
FQDN on systems where gethostname only returns a short name without a
domain (which is pretty useless). The behavior is equivalent to 'hostname
--fqdn'.
> From 2ae57d0c8c68c453b3f9715fcc9f83af0ebe84a0 Mon Sep 17 00:00:00 2001
From: David Lutterkort <[EMAIL PROTECTED]>
Date: Wed, 10 Dec 2008 18:34:39 -0800
Subject: [PATCH] virConnectGetHostname: return a fully qualified hostname
Instead of doing the equivalent of 'hostname', do 'hostname --fqdn',
i.e. try to qualify the local host name by an additional call to
gethostbyname(3)
---
src/libvirt_sym.version.in |1 +
src/qemu_driver.c | 16
src/test.c | 16 +---
src/uml_driver.c | 15 ---
src/util.c | 17 +
src/util.h |2 ++
src/xen_unified.c | 15 +--
7 files changed, 38 insertions(+), 44 deletions(-)
diff --git a/src/libvirt_sym.version.in b/src/libvirt_sym.version.in
index de0bc4a..f02d9e0 100644
--- a/src/libvirt_sym.version.in
+++ b/src/libvirt_sym.version.in
@@ -594,6 +594,7 @@ [EMAIL PROTECTED]@ {
virFileReadLimFD;
virFileReadPid;
virFileLinkPointsTo;
+virGetHostname;
virParseNumber;
virRun;
virSkipSpaces;
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 5f6fbd1..d6b7515 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -1562,23 +1562,16 @@ cleanup:
static char *
qemudGetHostname (virConnectPtr conn)
{
-int r;
-char hostname[HOST_NAME_MAX+1], *str;
+char *result;
-r = gethostname (hostname, HOST_NAME_MAX+1);
-if (r == -1) {
+result = virGetHostname();
+if (result == NULL) {
qemudReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
"%s", strerror (errno));
return NULL;
}
/* Caller frees this string. */
-str = strdup (hostname);
-if (str == NULL) {
-qemudReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
- "%s", strerror (errno));
-return NULL;
-}
-return str;
+return result;
}
static int qemudListDomains(virConnectPtr conn, int *ids, int nids) {
@@ -4249,4 +4242,3 @@ int qemuRegister(void) {
virRegisterStateDriver(&qemuStateDriver);
return 0;
}
-
diff --git a/src/test.c b/src/test.c
index 257fc8a..cb623ed 100644
--- a/src/test.c
+++ b/src/test.c
@@ -651,22 +651,16 @@ static int testGetVersion(virConnectPtr conn
ATTRIBUTE_UNUSED,
static char *testGetHostname (virConnectPtr conn)
{
-int r;
-char hostname [HOST_NAME_MAX+1], *str;
+char *result;
-r = gethostname (hostname, HOST_NAME_MAX+1);
-if (r == -1) {
+result = virGetHostname();
+if (result == NULL) {
testError (conn, VIR_ERR_SYSTEM_ERROR, "%s",
strerror (errno));
return NULL;
}
-str = strdup (hostname);
-if (str == NULL) {
-testError (conn, VIR_ERR_SYSTEM_ERROR, "%s",
- strerror (errno));
-return NULL;
-}
-return str;
+/* Caller frees this string. */
+return result;
}
static int testGetMaxVCPUs(virConnectPtr conn ATTRIBUTE_UNUSED,
diff --git a/src/uml_driver.c b/src/uml_driver.c
index 408096e..52a4e5b 100644
--- a/src/uml_driver.c
+++ b/src/uml_driver.c
@@ -1150,23 +1150,16 @@ cleanup:
static char *
umlGetHostname (virConnectPtr conn)
{
-int r;
-char hostname[HOST_NAME_MAX+1], *str;
+char *result;
-r = gethostname (hostname, HOST_NAME_MAX+1);
-if (r == -1) {
+result = virGetHostname();
+if (result == NULL) {
umlReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
"%s", strerror (errno));
return NULL;
}
/* Caller frees this string. */
-str = strdup (hostname);
-if (str == NULL) {
-umlReportError (conn, NULL, NULL, VIR_ERR_SYSTEM_ERROR,
- "%s", strerror (errno));
-return NULL;
-}
-return str;
+return result;
}
static int umlListDomains(virConnectPtr conn, int *ids, int nids) {
diff --git a/src/util.c b/src/util.c
index da26009..7188239 100644
--- a/src/util.c
+++ b/src/util.c
@@ -47,6 +47,7 @@
#ifdef HAVE_PATHS_H
#include
#endif
+#include
#include "virterror_internal.h"
#include "logging.h"
@@ -1306,3 +1307,19 @@ int virDiskNameToIndex(const char *name) {
return idx;
}
+
+char *virGetHostname(void)
+{
+int r;
+char hostname[HOST_NAME_MAX+1], *str;
+struct hostent *he;
+
+r = gethostname (hostname, HOST_NAME_MAX+1);
+if (r == -1)
+return NULL;
+if (!(he = gethostbyname(hostname)))
+return NULL;
+
+/* Caller frees this string. */
+return strdup (he->h_n
[libvirt] ANNOUNCE: Ruby bindings for libvirt, version 0.1.0
I am pleased to announce the release of version 0.1.0 of the ruby-libvirt bindings. NEWS: * Add binding for virConnectFindStoragePoolSources (clalance) * Fix dom_migrate (clalance) * Add the MIGRATE_LIVE (enum virDomainMigrateFlags) flag * Slight improvements of the unit tests The main site for the bindings is http://libvirt.org/ruby API docs can be found at http://libvirt.org/ruby/api/index.html Tarballs/src RPM's are at http://libvirt.org/ruby/download Packages for Fedora and EPEL5 are in the works and should show up on a friendly mirror near you soon. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Implement ruby-libvirt storage pool discovery binding
On Thu, 2008-10-23 at 12:04 +0200, Chris Lalancette wrote: > Attached is a pretty simple patch to implement the > virConnectFindStoragePoolSources() binding for ruby-libvirt.This capability > went > into libvirt-0.4.5, so any version of libvirt that has storage API support > should have support for this call. There's not much more to say; it works in > my > testing, and the implementation is pretty straightforward. > > Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> ACK David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Update ruby-libvirt migrate binding to use rb_scan_args
On Thu, 2008-10-23 at 12:04 +0200, Chris Lalancette wrote: > It's really not a good idea to hand parse variable number of args to a ruby > binding, like I implemented for the "migrate" method. Convert this to use > rb_scan_args, which is the proper way to do it, and matches all of the other > variable argument implementations in the binding. > > Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> ACK .. nice cleanup. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [augeas-devel] PATCH: Add a augeas lens for libvirtd.conf
On Wed, 2008-08-27 at 12:31 +0100, Daniel P. Berrange wrote: > On Tue, Aug 26, 2008 at 09:40:41PM +0000, David Lutterkort wrote: > > On Tue, 2008-08-26 at 21:05 +0100, Daniel P. Berrange wrote: > > > > > + let empty = [ label "empty" . del /[ \t]*\n/ "" ] > > > > Do you really care that empty entries show up in the tree ? If you don't > > want to see them, you can remove the 'label' from the above, and > > possibly also the '[ .. ]'. > > Ok, this gets fun. I don't particularly want the label or tree node. > I can remove the label OK, but that gives anonymous tree nods. Thinking about this some more, anonymous (or labelled) nodes are probably your best bet here, because: > If I remove the [...], then I end up with > > test -x /usr/bin/augparse && /usr/bin/augparse -I . test_libvirtd.aug > ./libvirtd.aug:63.3-.43:Failed to compile lns > ./libvirtd.aug:63.13-.43:exception: ambiguous tree iteration > 'ca_file/' can be split into > '|=|ca_file/' > > and > 'ca_file/|=|' > > Iterated lens: ./libvirtd.aug:63.15-.39 > > test_libvirtd.aug:253.8-.20:Could not load module Libvirtd for Libvirtd.lns > test_libvirtd.aug:253.8-.20:Undefined variable Libvirtd.lns > test_libvirtd.aug: error: Loading failed > > And I'm utterly stuck on what this means / how to fix it. I didn't > expect removing the square brackets to change the DFA. The error message is admittedly obtuse (though I am not sure how to improve it, suggestions welcome) What Augeas is telling you (or trying to, atleast) is that when it goes to write a tree back into the file (that's why it mentions 'tree iteration') it has a choice, and doesn't know what to do in the lens on line 63, columns 3 - 43, which is the toplevel 'lns' lens: let lns = ( record | comment | empty ) * The '|=|' mark in the error message shows where Augeas thinks it could split a tree with a single node 'ca_file': either into (no node, cafile/) or (cafile/, no node) .. what makes this error message doubly heinous is that there's no good notation for 'no node' - it's the empty string in the error message. The issue is that when it sees a tree with a single node 'ca_file' it doesn't know whether to process that as a single 'record' or as a 'record . empty' or 'empty . record', since all of these match the tree with a single 'ca_file' entry, simply because the 'empty' lens now leaves no traces in the tree that it had been used. When you define 'empty' as '[ eol ]', Augeas knows how to process that tree since every time 'empty' should be used, there must be a node in the tree with a NULL label, so a single tree node 'ca_file' can only be processed by using 'record', and not 'record . empty' or similar. As I said, the simplest way around this is to define 'empty' as '[ eol ]' - you could also try to change things so that empty lines are pulled into record or comment entries, but that's probably more trouble than it's worth. > > I've been thinking that we need to have some function that reads a file > > and returns a string so we don't have to clutter tests with these long > > strings. But for now, that's what it is :( > > Yes, that would be very nice - and/or supporting use of < for strings, so I don't have to escape " throughout the embedded config > file One more note on this: to get started, pulling in a whole config file and checking that that gets processed in a reasonable way is deifnitely the best thing to do. Over time, as you make changes to the file format and/or fix bugs in the lens, you're probably better off writing small tests that check for one particular thing (the test_shellvars.aug in Augeas hg is a good example for this) I put a ticket into Trac for this[1] > One other useful improvement would be for the test suite to only print > out sections of the tree which differ. In debugging this it printed > out a 400 line 'Expected' tree structure, and then a 400 line 'Actual' > tree structure and wanted me to play "Where's Waldo" to find the typo. > > It would be good to trim the leading and trailing nodes which are the > same Yeah, I've run into this before, too. Yet another ticket[2] > > All in all, very nice, and I am really glad that upstream is shipping a > > lens :) > > Just discovered one minor issue. The Fedora RPM guidelines require that > an RPM either own a directory, or require an RPM that owns it, and two > RPMs aren't allowed to own the same directory. I don't want/need to > depend on Augeas directly, but equally I need someone to own the > /usr/share/augeas/lens directory. Wonder if that directory should be put > into the 'filesystem' RPM ? Yeah, that's the only feasible solution. I'll need to figure out what the process for that is. David [1] http://fedorahosted.org/augeas/ticket/10 [2] http://fedorahosted.org/augeas/ticket/11 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [augeas-devel] PATCH: Add a augeas lens for libvirtd.conf
On Wed, 2008-08-27 at 12:15 +0100, Richard W.M. Jones wrote: > Dan pointed out that you have your own DFA implementation. Actually, libf does everything but matching - it does all the regexp calculations needed for the typechecker; for matching, I use GNU regex. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [augeas-devel] PATCH: Add a augeas lens for libvirtd.conf
On Wed, 2008-08-27 at 12:03 +0100, Richard W.M. Jones wrote: > Out of interest, do you ever hit the 16 bit limit in the size of > compiled regexps? The "bytecode" used to represent compiled GNU > regexps has (or perhaps had) a 16 bit limit in the jump offsets, which > I hit a few years back. Had to switch to using a flex-compiled > pattern matcher in the end. No, I haven't run into that. Was that with the 'old' GNU regex implementation (before ~ 2002) or with the current one ? David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [augeas-devel] PATCH: Add a augeas lens for libvirtd.conf
On Tue, 2008-08-26 at 22:01 +0100, Daniel P. Berrange wrote: > > While I can see why it is useful to gather these entries logically, it's not > > very optimised for the parser. Eventually, all this will be compiled into a > > huge regexp, so it's more efficient to regroup entries by type and feed the > > functions with regexps instead of strings, like > > Is performance really that much of a problem ? The libvirt config file > only has 20 or so different settings, and while we'll add more I can't > see it getting very much larger. Changing these settings is also not > something that would be done on a frequent basis / performance critical > path. I find it more readable to group them by functional area unless > there is a serious real world performance issue. We've seen some cases where it made a _dramatic_ difference. But if it's fast enough now, I wouldn't worry about it - just keep that in mind when either running augparse or augtool on it becomes unbearably slow. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [augeas-devel] PATCH: Add a augeas lens for libvirtd.conf
On Tue, 2008-08-26 at 22:37 +0200, Raphaël Pinson wrote: > Hi Daniel, > > On Tue, Aug 26, 2008 at 10:05 PM, Daniel P. Berrange > <[EMAIL PROTECTED]> wrote: > THis patch is intended to be committed to libvirt, so the > config file rules > are distributed alongside libvirt. I'm CC'ing augeas-devel for > feedback on > the lens itself. > > Very nice idea. This might have to be thought about for the future > since so far we're only adding lenses to the Augeas repository. Long term, it was always my plan to have upstream ship their lenses - it gets around a whole host of worries you need to have otherwise that the lenses that come with Augeas really do match every version of upstream's config file format. > === > RCS file: qemud/libvirtd.aug > diff -N qemud/libvirtd.aug > --- /dev/null 1 Jan 1970 00:00:00 - > +++ qemud/libvirtd.aug 26 Aug 2008 20:03:48 - > @@ -0,0 +1,64 @@ > +(* /etc/libvirt/libvirtd.conf *) > + > +module Libvirtd = > + autoload xfm > + > + let eol = del /[ \t]*\n/ "\n" > > This is also Util.eol In general, I would agree that you should use definitions from Util etc. But since we are not really that good yet at defining which of the modules that come with Augeas are fixed (let alone having tests for all that), and since these are all relatively small things, it's safer to just leave the Libvirtd module standalone. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [augeas-devel] PATCH: Add a augeas lens for libvirtd.conf
On Tue, 2008-08-26 at 21:05 +0100, Daniel P. Berrange wrote: > Now instead of telling people > > 'edit /etc/libvirt/libvirtd.conf and change listen_tls to 1, >and auth_tls to sasl' > > we can say run > ># augtoolset /files/etc/libvirt/libvirtd.conf/auth_tls sasl >save >EOF Very nice. > THis patch is intended to be committed to libvirt, so the config file rules > are distributed alongside libvirt. I'm CC'ing augeas-devel for feedback on > the lens itself. > > libvirt.spec.in |2 > qemud/Makefile.am |8 > qemud/libvirtd.aug | 64 ++ > qemud/test_libvirtd.aug | 484 > > 4 files changed, 558 insertions(+) > > > Daniel > > Index: qemud/Makefile.am > === > RCS file: /data/cvs/libvirt/qemud/Makefile.am,v > retrieving revision 1.51 > diff -u -p -r1.51 Makefile.am > --- qemud/Makefile.am 20 Aug 2008 20:48:35 - 1.51 > +++ qemud/Makefile.am 26 Aug 2008 20:03:48 - > @@ -24,6 +24,8 @@ EXTRA_DIST = > \ > libvirtd.policy \ > libvirtd.sasl \ > libvirtd.sysconf\ > +libvirtd.aug\ > +test_libvirtd.aug \ > $(AVAHI_SOURCES)\ > $(DAEMON_SOURCES) > > @@ -56,6 +58,12 @@ sbin_PROGRAMS = libvirtd > confdir = $(sysconfdir)/libvirt/ > conf_DATA = libvirtd.conf > > +augeasdir = $(datadir)/augeas/lenses > +augeas_DATA = libvirtd.aug > + > +augeastestsdir = $(datadir)/augeas/lenses/tests > +augeastests_DATA = test_libvirtd.aug > + > libvirtd_SOURCES = $(DAEMON_SOURCES) You might also add a test that runs augparse -I . test_libvirtd.aug during 'make check' > #-D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=1 -D_POSIX_C_SOURCE=199506L > Index: qemud/libvirtd.aug > === > RCS file: qemud/libvirtd.aug > diff -N qemud/libvirtd.aug > --- /dev/null 1 Jan 1970 00:00:00 - > +++ qemud/libvirtd.aug26 Aug 2008 20:03:48 - > @@ -0,0 +1,64 @@ > +(* /etc/libvirt/libvirtd.conf *) > + > +module Libvirtd = > + autoload xfm > + > + let eol = del /[ \t]*\n/ "\n" > + let value_sep = del /[ \t]*=[ \t]*/ " = " > + let prespace = del /[ \t]*/ "" > + > + let array_sep = del /,[ \t\n]*/ ", " > + let array_start = del /\[[ \t\n]*/ "[ " > + let array_end = del /\]/ " ]" Augeas should throw an error here, but doesn't ;) The default value you give as the second argument of del really should match the first (regexp) argument. Also, Augeas automatically promotes strings to regexps as needed, so you can say let array_end = del "]" "]" > + let str_val = del /\"/ "\"" . store /[^\"]*/ . del /\"/ "\"" > + let bool_val = store /0|1/ > + let str_array_element = [ str_val ] . del /[ \t\n]*/ "" > + let str_array_val = array_start . ( str_array_element . ( array_sep . > str_array_element ) * ) ? . array_end You should really have some sort of label on each array element/str val (either the same for all of them using 'label' or just consecutive numbers using 'seq') - without that, you won't be able to get to individual entries through the public API. > + let comment = [ label "comment" . del /#[ \t]*/ "# " . store /([^ > \t\n][^\n]*)?/ . del /\n/ "\n" ] We've been trying to label all comments as '#comment'; it's not an issue for libvirt, but with some other file formats, using 'comment' leads to conflicts with actual entries. Would be good to stick to that convention. > + let empty = [ label "empty" . del /[ \t]*\n/ "" ] Do you really care that empty entries show up in the tree ? If you don't want to see them, you can remove the 'label' from the above, and possibly also the '[ .. ]'. And the missing check for 'del' strikes again - that needs to be 'del /[ \t]*\n/ "\n"' - I really need to fix that. > Index: qemud/test_libvirtd.aug > === > RCS file: qemud/test_libvirtd.aug > diff -N qemud/test_libvirtd.aug > --- /dev/null 1 Jan 1970 00:00:00 - > +++ qemud/test_libvirtd.aug 26 Aug 2008 20:03:48 - > @@ -0,0 +1,484 @@ > +module Test_libvirtd = > + let conf1 = "# Master libvirt daemon configuration file I've been thinking that we need to have some function that reads a file and returns a string so we don't have to clutter tests with these long strings. But for now, that's what it is :( > +{ "tls_allowed_dn_list" > + { = "DN1"} > + { = "DN2"} > +} This happens because str_array_element produces tree nodes without labels. Users won't have a way to change e.g. the 'DN1' value to 'myDN' since
Re: [libvirt] [PATCH]: ruby-libvirt migration fixes
On Fri, 2008-08-08 at 16:22 +0200, Chris Lalancette wrote:
> Jim Meyering wrote:
> >> diff -r c6a3e36cdf54 ext/libvirt/_libvirt.c
> >> --- a/ext/libvirt/_libvirt.c Thu Jul 17 15:24:26 2008 -0700
> >> +++ b/ext/libvirt/_libvirt.c Fri Aug 08 06:04:56 2008 -0400
> >> @@ -637,16 +637,51 @@ VALUE libvirt_conn_num_of_defined_storag
> >> }
> >> #endif
> >>
> >> +static char *get_string_or_nil(VALUE arg)
> >> +{
> >> +if (TYPE(arg) == T_NIL)
> >> +return NULL;
> >> +else if (TYPE(arg) == T_STRING)
> >> +return STR2CSTR(arg);
> >
> > STR2CSTR is marked as obsolete in ruby.h, where it says
> > to use StringValuePtr instead:
> >
> > /* obsolete API - use StringValuePtr() */
> > #define STR2CSTR(x) rb_str2cstr((VALUE)(x),0)
>
> Yeah, you are right. I looked through the ruby source code, actually, and I
> ended up using StringValueCStr (which is used elsewhere in the ruby-libvirt
> bindings). It's basically the same as StringValuePtr, but does an additional
> check to make sure the string is not of 0 length and that there aren't
> additional embedded \0 in the string.
>
> I also updated the patch with the const pointers as you suggested. Attached.
> Thanks for the review!
ACK .. committed.
I'll try and roll a new release tomorrow.
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] default networking issues
On Thu, 2008-07-31 at 09:55 +0100, Daniel P. Berrange wrote: > The libvirt default networking capability will automatically setup the > correct iptables rules to allow outbound NAT based connectivity for guest > VMs. If this wasn't working there are two likely causes: > > - You run 'service iptables stop' which blew away the rules libvirt >added This is a terrible situation; it will be a big surprise to many sysadmins and lead to lots of confusion - is this only temporary until iptables/lokkit has facilities for cleaner addition of persistent firewall rules ? David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: ruby-libvirt on debian based systems
On Mon, 2008-07-21 at 16:48 +0200, Tom Verhaeghe wrote: > Solved, i had to install libxen3-dev in order to make it work. I assume that that contains the pkgconfig for libvirt; the extconf.rb in ruby-libvirt needs that. With that ruby-libvirt works fine on Ubuntu ? I am glad to hear that. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH]: Add MIGRATE_LIVE definition to ruby-libvirt bindings
On Mon, 2008-07-07 at 17:28 +0200, Chris Lalancette wrote: > Attached is a trivial patch to add the MIGRATE_LIVE flag into the > ruby-libvirt > bindings. > > Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> ACK .. Committed. (1) Do you need a new ruby-libvirt release for this ? (2) How far back has 'enum virDomainMigrateFlags' been around ? IOW, do I need to worry about compilation breaking on old libvirt releases ? David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Bash auto-completion for virsh
On Mon, 2008-07-14 at 11:57 +0100, Daniel P. Berrange wrote: > Everyone[1] seems to be doing funky bash auto-completion for commands these > days, so I thought I'd make a stab at doing something for virsh. I guess the completions I did previously[1] never were committed then - I'm using them quite happily. Though having virsh provide the info dynamically is of course much nicer. David [1] https://www.redhat.com/archives/libvir-list/2007-October/msg00231.html -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH]: fix ruby-libvirt bindings when virConnectNum* returns 0
On Tue, 2008-06-17 at 11:16 +0200, Chris Lalancette wrote: > Attached is a simple patch to fix a problem I ran into when using the > ruby-libvirt bindings with libvirt 0.4.3. Basically, if you call any of the > virConnectList* functions with a "max" of 0, it returns "Invalid Arg". To get > around this, modify the ruby-libvirt bindings to return an empty list if we > get > num == 0 when calling the corresponding virConnectNumOf* function. This > should > solve: https://bugzilla.redhat.com/show_bug.cgi?id=451666 > > Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> I committed the patch with a couple more places to shortcircuit added. Making a release and pushing an update will likely have to wait till next week. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC: safer memory allocation APIs with compile time checking
On Mon, 2008-04-28 at 20:16 +0100, Daniel P. Berrange wrote: > I've just hacked up a similar approach to the one DBus uses to fail > the 'nth' malloc Does that fail exactly the nth malloc or the nth malloc and after (or from nth malloc to (n+k)th malloc) ? The latter two are more realistic for an OOM scenario, and make sure you don't blow up in some error handling routine. > and run the 'xmconfigtest' test case for every 'n' > between 1 and 200 and OOM handling worked correctly in every case. Excellent. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC: safer memory allocation APIs with compile time checking
On Mon, 2008-04-28 at 13:38 +0100, Richard W.M. Jones wrote: > On Mon, Apr 28, 2008 at 03:39:41AM -0400, Daniel Veillard wrote: > > Calling abort() in a library is a major NO-NO and one of the reasons > > I avoided glib in most of the code I developped. You just can't > > exit()/abort() > > from a library. > > That depends ... If you can override the abort() function with an > error handler, then I'd say it is OK. I used to not think very highly of calling abort() by default, but reading Havoc's blog post about that a while ago[1] is making me doubt conventional wisdom. He cites libxml2 as one example where OOM leads to crashes - I take that not as an indication that there is something wrong with libxml2, but with the approach of checking and correctly handling all allocation failures. Allocation failure happens very rarely, and testing it properly is near impossible; allocation failures amount to an additional input stream that is read deep down in the call hierarchy and can generally not be checked by the caller like other arguments. So maybe taking a hint from all the languages that contain 'fat' runtimes isn't the worst of strategies: die loudly by default, and let the application specify other handlers. In practice, the usefulness of those handlers is limited by their inability to unwind the stack and free dead memory on the way out. Has anybody seen such handlers be useful short of a full exception implementation ? David [1] http://log.ometer.com/2008-02.html#4 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] ANNOUNCE: Ruby bindings for libvirt, version 0.0.7
I am pleased to announce the release of version 0.0.7 of the ruby-libvirt bindings. The main reason for this release is to fix a nasty crash caused by the use of virResetError. NEWS: * Binding for virDomainMigrate * Fix crash caused by using virResetError * More sensible message included in exceptions The main site for them is http://libvirt.org/ruby API docs can be found at http://libvirt.org/ruby/api/index.html Tarballs/src RPM's are at http://libvirt.org/ruby/download Packages for F-8/F-9 are in the works and should show up on a friendly mirror near you soon. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] new release of ruby bindings
On Tue, 2008-04-15 at 11:37 -0700, Vadim Zaliva wrote: > Since last official release of ruby bindings is causing nasty crash in > error handling code, wouldn't it be good idea to issue new bugfix > release. Yes, you are right. I am in the middle of getting 0.0.7 out .. should be available in a couple of hours or so. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] crash on domain shutdown (via ruby)
On Mon, 2008-04-14 at 11:04 -0700, Vadim Zaliva wrote: > On Apr 11, 2008, at 16:55, David Lutterkort wrote: > > Try commenting the call to virResetError in _libvirt.c in the ruby > > bindings out entirely, and see if you still get a crash. > > > Yes, that helped. Do you plan to fix in in mercurial soon? I just committed a change so that we don't use the copy methods anymore; the ruby bindings now use the get error methods instead. The copy methods offer little advantage over the get methods. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] new ruby error handling
On Sun, 2008-04-13 at 20:13 -0700, Vadim Zaliva wrote: > I guess my main complaint is that in some cases message is not a > coherent English phrase, something I can show to users. So I would > prefer to have "Error during call to XXX" instead of just "XXX". I just committed a change so that the message of the exception is set to such a message. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] crash on domain shutdown (via ruby)
On Fri, 2008-04-11 at 15:32 -0700, Vadim Zaliva wrote: > I was too quick to speak. I got another crash: > > *** glibc detected *** ruby: double free or corruption (out): > 0x08e78608 *** > === Backtrace: = > /lib/i686/nosegneg/libc.so.6[0x5166a6] > /lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x519c10] > /usr/lib/libvirt.so.0(virResetError+0x44)[0x64af3f4] > /usr/lib/libvirt.so.0(virConnResetLastError+0x24)[0x64af634] > /usr/lib/libvirt.so.0[0x649f618] > /usr/lib/libvirt.so.0(virDomainLookupByUUID+0xb7)[0x648e7d7] > /usr/lib/libvirt.so.0(virDomainLookupByUUIDString+0x14d)[0x648f90d] > /usr/lib/ruby/site_ruby/1.8/i386-linux/ > _libvirt.so(libvirt_conn_lookup_domain_by_uuid+0x3d)[0x15f8cd] Did your program while it ran have any errors before ? This is somewhere in the guts of libvirt, and I would guess it's a double free caused by the ruby bindings first calling virResetError on an unrelated error, and then libvirt crashing on a second error since the first virResetError freed various strings it didn't really own. Try commenting the call to virResetError in _libvirt.c in the ruby bindings out entirely, and see if you still get a crash. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] new ruby error handling
On Thu, 2008-04-10 at 23:28 -0700, Vadim Zaliva wrote: > I have a dumb question about new error handling. What is the rationale > for using > 'libvirt_message' instead of 'message' in new Libvirt Ruby error > classes? The 'message' in the exception is set, too, usually to the name of the libvirt function that returned the error. libvirt_message stores additional error details from virError, which is not always available. That's how it works at the moment, but I am open to suggestions to change that. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] crash on domain shutdown (via ruby)
Hi Vadim, seems you're having the honor of testing the new improved error reporting in ruby-libvirt. The way virResetError was used was incorrect: it can only be called if virConnCopyLastError returned a positive result. For some reason, in your example virDomainShutdown fails, but the error status on the connection seems to still be VIR_ERR_OK. I just committed a change to ruby-libvirt to address that; can you give that a try ? The virResetError docs are not clear on when it can be called, and when it must not be called. It seems like a useless optimization that the memcpy of the error only happens when there was an error - the virConnCopyLastError/virCopyLastError routines also need to strdup the various strings in a virError, otherwise it is possible that the same string gets freed multiple times when there are multiple matching copy/reset calls. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] ANNOUNCE: Ruby bindings for libvirt, version 0.0.6
I'm pleased to announce version 0.0.6 of the Ruby bindings for libvirt. The most notable addition is support for the libvirt storage API. From the NEWS file: * Explicit free methods for various objects (based on a patch by Vadim Zaliva) * Make the FLAGS argument for various calls optional, and default it to 0. (Chris Lalancette) * More finegrained exceptions on errors, containing libvirt error message (Mohammed Morsi) * Bindings for the libvirt storage API (requires libvirt 0.4.1) * Suppress some bindings if the underlying libvirt doesn't support it * Bindings for virDomainSetMemory, virDomainPinVcpu, and virDomainSetVcpus (Vadim Zaliva) The main site for ruby-libvirt is http://libvirt.org/ruby API docs can be found at http://libvirt.org/ruby/api/index.html Please send all your patches (and comments/questions) to this list. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] [RUBY-LIBVIRT]: Make the flags parameter optional
On Tue, 2008-04-01 at 18:54 -0400, Chris Lalancette wrote: > While using the ruby-libvirt bindings, I usually end up setting the > "flags" > parameter to various calls to 0. While this is required by the C side of > things, for Ruby we have no such constraint; we can have methods with optional > arguments. Excellent ... comitted. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] uuid of newly created domain
On Wed, 2008-04-02 at 17:24 +0100, Richard W.M. Jones wrote: > OCaml bindings have the same problem as well, but it's not something I > feel any urge to fix there. To me it seems more like a C/libvirt bug. The Ruby bindings now have methods to call virXXXFree manually; but I agree, it feels to me like leaking an implementation detail through the API. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] patch: Domain.free() in Ruby bindings
On Tue, 2008-04-01 at 10:04 -0700, Vadim Zaliva wrote: > Attached patch adds new method free() to Domain class. Invocation of > this method > calls virDomainFree(). After this call, all other calls to this domain > object would > fail. Thanks for the patch. I just committed a slight variation of the patch - for symmetry, I added free methods for Network, StorageVol and StoragePool, too. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] ruby binding patch
On Fri, 2008-03-28 at 18:10 -0700, Vadim Zaliva wrote: > Attached is a patch, implementing Domain.pin_vcpu method. > I have tested it locally and it works. Here is my test code: Excellent. I just committed it with some minor modifications (use ALLOC/ALLOC_N instead of malloc, since the former will raise proper out-of-memory exceptions and runs the gc when memory is low) > However, when I try this method from test/tc_connect.rb it fails: > > # rake test > (in /home/lord/src/ruby-libvirt) > Loaded suite /usr/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/ > rake_test_loader > Started > libvir: error : this function is not supported by the hypervisor: > virDomainPinVcpu > E > Finished in 0.006319 seconds. > >1) Error: > test_domain(TestConnect): > SystemCallError: unknown error - libvir call virDomainPinVcpu failed > ./tests/tc_connect.rb:113:in `pin_vcpu' > ./tests/tc_connect.rb:113:in `test_domain' It looks like virDomainPinVcpu is simply not implemented in the test driver; I'll take your word for it that it works properly ;) David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] uuid of newly created domain
On Sat, 2008-03-29 at 15:53 -0700, Vadim Zaliva wrote: > I am running into interesting problem with UUID. I am using Ruby > bindings, but I think the > problem is not specific to Ruby. I am doing roughly the following: > > dom = c.define_domain_xml(xml) > dom1 = c.ookup_domain_by_uuid(dom.uuid) > > and I got an error that domain with given UUID is not found. Very strange .. I just tried the same, albeit with the KVM backend, and it works fine. The two UUID's are the same, both if the XML used to define it has an explicit UUID, and if it is assigned in the backend. I don't have a Xen host set up right now, so it's probably a silly question: Does Xen assign UUID's when domains are defined, or only once a domain is created ? David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] ruby binding patch
Hi Vadim, thanks a lot for the patch. First off, can you send patches in the future as text patches, either attached or inline[1] ? I was able to apply your hg bundle though. On Thu, 2008-03-27 at 23:59 -0700, Vadim Zaliva wrote: > I have attempted to add following methods to Domain class: > > 1. vcpus= > 2. memory= > > This is my first patch to libvirt-ruby, and I will appreciate your > feedback. > My next goal is to add binding for virDomainPinVcpu() method. The patch overall looks good, and I committed it. There were some minor nits: * libvirt_dom_memory_set called virDomainSetMaxMemory instead of virDomainSetMemory (probably cut&paste error) * there were no tests for the two new methods. In general, try to add/expand the tests in tests/tc_connect.rb when you add to the bindings, though that is highly dependent on what the test driver supports. In this case though it was pretty easy. Thanks again for doing this, and I am looking forward to the virDomainPinVcpu patch. David [1] the hg patchbomb extension makes that very easy: http://hgbook.red-bean.com/hgbookch14.html#x18-32100014.4 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] building ruby bindings
On Wed, 2008-03-26 at 16:42 -0700, Vadim Zaliva wrote: > On Mar 26, 2008, at 16:24, David Lutterkort wrote: > > > This is very strange since the NORETURN macro is defined by ruby-devel > > (for gcc it amounts to __attribute__((noreturn)) ) It seems that gcc-4.1.1/gcc-4.1.2 don't like __attribute__((noreturn)) after the function declaration if that's also the function definition; I checked a fix into the mercurial repo. David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] building ruby bindings
On Wed, 2008-03-26 at 14:53 -0700, Vadim Zaliva wrote:
> The offending line is:
>
> NORETURN(static void vir_error(virConnectPtr conn, const char *fn)) {
> rb_raise(rb_eSystemCallError, "libvir call %s failed", fn);
> }
This is very strange since the NORETURN macro is defined by ruby-devel
(for gcc it amounts to __attribute__((noreturn)) )
I just checked in my RHEL5 build root, and it's set to a noop in ruby.h
if it is not defined by config.h
This is with ruby-devel-1.8.5-5.el5 .. which version of ruby-devel are
you using ? Can you grep for NORETURN in ruby.h and config.h ? They are
in /usr/lib/ruby/1.8/i386-linux
David
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
