Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, Jun 17, 2009 at 01:27:14PM -0700 David Lutterkort wrote: or forever hold your peace. While talking about the relax-ng schema, I would like to again raise my question earlier raised at the netcf-devel-list in order to get some input from the libvirt developers on this matter as well. 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. Not having the IP address restriction may collide head on with the connection-approach for some, as a connection probably have to be addressable. I however argue that this severly limits the uses for netcf, say for example to only bridge two interfaces without caring (and perhaps not wanting) to be something other then a package forwarder and not care about IP-address collisions. And in another case, the addressing is done using something other then IP. For the bridges without added interfaces, an example is libvirt that have these private networks that I don't think I have to go in to in detail. My strongest point in both cases is that both restrictions is policy-driven. If for example an option in a configuration file for an interface is not recognized by netcf, it may be simply ignored and later merged back in to the configuration if this is updated through netcf. The restrictions in IP-addresses and bridge members can however make an existing configuration clash with netcf. In the end, there is nothing that stops end applications to implement this policy if required. As said, I raised this question on netcf-devel, and David and I have been having some back-and-forth about this [1]. I also promised to raise this question here as per request about a month ago. What are the views of the libvirt community? Is netcf planned to be used for the isolated libvirt-networks? Will there be a case where a forwarding bridge perferably would lack an IP address? Other thoughts? Best regards, Jonas [1] https://fedorahosted.org/pipermail/netcf-devel/2009-May/thread.html https://fedorahosted.org/pipermail/netcf-devel/2009-June/12.html https://fedorahosted.org/pipermail/netcf-devel/2009-June/13.html -- Jonas Eriksson Consultant at AS/EAB/FLJ/IL Combitech AB Dlvsjv, Sweden -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] domain.info() sometimes returns state zero for running machines
I executed the commands export LIBVIRT_DEBUG=1 and virsh dominfo 2
(ID 2 was a running domU), this is the output:
-
DEBUG: libvirt.c: virInitialize (register drivers)
DEBUG: xen_internal.c: xenHypervisorInit (Using new hypervisor call: 30002
)
DEBUG: xen_internal.c: xenHypervisorInit (Using hypervisor call v2, sys
ver6 dom ver5
)
DEBUG: libvirt.c: virConnectOpenAuth (name=(null), auth=0xb7f49b60, flags=0)
DEBUG: libvirt.c: do_open (Probed xen:///)
DEBUG: libvirt.c: do_open (Probed qemu:///system)
DEBUG: libvirt.c: do_open (Using xen:/// as default URI, 2 hypervisor found)
DEBUG: libvirt.c: do_open (name xen:/// to URI components:
scheme xen
opaque (null)
authority (null)
server (null)
user (null)
port 0
path /
)
DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...)
DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED)
DEBUG: libvirt.c: do_open (trying driver 1 (Xen) ...)
DEBUG: xen_unified.c: xenUnifiedOpen (Trying hypervisor sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated hypervisor sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Trying XenD sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated XenD sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Trying XS sub-driver)
DEBUG: xen_unified.c: xenUnifiedOpen (Activated XS sub-driver)
DEBUG: libvirt.c: do_open (driver 1 Xen returned SUCCESS)
DEBUG: libvirt.c: do_open (network driver 0 Test returned DECLINED)
DEBUG: libvirt.c: do_open (network driver 1 QEMU returned DECLINED)
DEBUG: remote_internal.c: doRemoteOpen (proceeding with name = xen:///)
DEBUG: libvirt.c: do_open (network driver 2 remote returned SUCCESS)
DEBUG: libvirt.c: do_open (storage driver 0 Test returned DECLINED)
DEBUG: libvirt.c: do_open (storage driver 1 storage returned DECLINED)
DEBUG: libvirt.c: do_open (storage driver 2 remote returned SUCCESS)
DEBUG: libvirt.c: virDomainLookupByID (conn=0x9b49048, id=2)
DEBUG: hash.c: __virGetDomain (New hash entry 0x9b580a0)
DEBUG: libvirt.c: virDomainGetID (domain=0x9b580a0)
DEBUG: libvirt.c: virDomainGetName (domain=0x9b580a0)
DEBUG: libvirt.c: virDomainGetUUIDString (domain=0x9b580a0, buf=0xbff74b07)
DEBUG: libvirt.c: virDomainGetUUID (domain=0x9b580a0, uuid=0xbff74aac)
DEBUG: libvirt.c: virDomainGetOSType (domain=0x9b580a0)
DEBUG: libvirt.c: virDomainGetInfo (domain=0x9b580a0, info=0xbff74b2c)
DEBUG: libvirt.c: virDomainGetAutostart (domain=0x9b580a0,
autostart=0xbff74b44)
DEBUG: libvirt.c: virDomainFree (domain=0x9b580a0)
DEBUG: hash.c: virUnrefDomain (unref domain 0x9b580a0
ac06e4f0-59b1-11de-8a39-0800200c9a66 1)
DEBUG: hash.c: virReleaseDomain (release domain 0x9b580a0
ac06e4f0-59b1-11de-8a39-0800200c9a66)
DEBUG: hash.c: virReleaseDomain (unref connection 0x9b49048 xen:/// 2)
DEBUG: libvirt.c: virConnectClose (conn=0x9b49048)
DEBUG: hash.c: virUnrefConnect (unref connection 0x9b49048 xen:/// 1)
DEBUG: hash.c: virReleaseConnect (release connection 0x9b49048 xen:///)
-
This is pretty weird because there are no debugging messages from Xen
functions?!
Daniel P. Berrange wrote:
On Wed, Jun 17, 2009 at 04:04:20PM +0100, Andreas Sommer wrote:
I'm using Xen-3.2-1 on Debian 5.0.1-lenny and retrieve information about
running domains using
domain.info()[0]
The domain object is retrieved via connection.lookupByUUIDString(...)
and stored as a variable called domain. Usually the running domains
have the state 1 (VIR_DOMAIN_RUNNING) or 2 (VIR_DOMAIN_BLOCKED), but
sometimes it happens that 0 (VIR_DOMAIN_NOSTATE) is returned.
Why does that happen? I don't think it is an error because then it
would've raised an exception...
I think it is most likely a bug in our handling of the state info
from the hypervisor with certain Xen version. I'm fairly sure we
should never get NO_STATE for any active domain
If you want to try and troubleshoot the code, then this handled in the
xenHypervisorGetDomInfo() method in src/xen_internal.c.
It currently does this:
domain_flags = XEN_GETDOMAININFO_FLAGS(dominfo);
domain_flags = ~DOMFLAGS_HVM; /* Mask out HVM flags */
domain_state = domain_flags 0xFF; /* Mask out high bits */
switch (domain_state) {
}
.
Given that you see NO_STATE, I expect that none of the 'case' inside
the 'switch' are being matched. I'd be interested to know what the
'domain_state' value is immediately after its fetched from the HV.
So you might try changing it to
domain_flags = XEN_GETDOMAININFO_FLAGS(dominfo);
DEBUG(Raw HV state flag %x, domain_flags);
domain_flags = ~DOMFLAGS_HVM; /* Mask out HVM flags */
domain_state = domain_flags 0xFF; /* Mask out high bits */
DEBUG(Masked HV state flag %x, domain_flags);
switch (domain_state) {
}
DEBUG(libvirt state flag %x, info-state);
And then running 'LIBVIRT_DEBUG=1 virsh dominfo GUEST' and
[libvirt] [PATCH] fix virsh dominfo returns error when virNodeGetSecurityModel() is not supported.
Hi all
I try virsh dominfo in upstream libvirt on xen machine,
the commands returns -1 as follows:
[r...@vmi20 ~]# virsh dominfo rhel53rc2_pv_sdb3
Id: 1
Name: rhel53rc2_pv_sdb3
UUID: 05ba9be8-f4e9-e208-11c7-fc936655cd8e
OS Type:linux
State: idle
CPU(s): 2
CPU time: 8.8s
Max memory: 1048576 kB
Used memory:716800 kB
Autostart: disable
error: this function is not supported by the hypervisor:
virNodeGetSecurityModel
[r...@vmi20 ~]# echo $?
1
The explanation of virNodeGetSecurityModel() and
virNodeGetSecurityModel() in libvirt.c is return -2
when hypervisor drivers don't support these operations.
But these functions return -1 in this case, and so
cmdDominfo() in virsh.c returns FALSE.
I make a patch.
- virNodeGetSecurityModel() and virNodeGetSecurityModel()
return -2 when drivers don't supprted these operations.
- In CmdDominfo(), it is no operation when virNodeGetSecurityModel()
and virNodeGetSecurityModel() return -2.
Signed-off-by: Tatsuro Enokura fj202...@aa.jp.fujitsu.com
Thanks
Tatsuro Enokura
Index: src/libvirt.c
===
RCS file: /data/cvs/libvirt/src/libvirt.c,v
retrieving revision 1.214
diff -u -r1.214 libvirt.c
--- src/libvirt.c 12 Jun 2009 13:20:13 - 1.214
+++ src/libvirt.c 18 Jun 2009 02:51:23 -
@@ -4412,8 +4412,9 @@
if (conn-driver-domainGetSecurityLabel)
return conn-driver-domainGetSecurityLabel(domain, seclabel);
+/* the operation is not supported */
virLibConnWarning(conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
-return -1;
+return -2;
}
/**
@@ -4442,8 +4443,9 @@
if (conn-driver-nodeGetSecurityModel)
return conn-driver-nodeGetSecurityModel(conn, secmodel);
+/* the operation is not supported */
virLibConnWarning(conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
-return -1;
+return -2;
}
/**
Index: src/virsh.c
===
RCS file: /data/cvs/libvirt/src/virsh.c,v
retrieving revision 1.210
diff -u -r1.210 virsh.c
--- src/virsh.c 3 Jun 2009 12:13:52 - 1.210
+++ src/virsh.c 18 Jun 2009 02:51:25 -
@@ -1582,7 +1582,7 @@
virDomainPtr dom;
virSecurityModel secmodel;
virSecurityLabel seclabel;
-int ret = TRUE, autostart;
+int ret = TRUE, ret_code, autostart;
unsigned int id;
char *str, uuid[VIR_UUID_STRING_BUFLEN];
@@ -1642,9 +1642,13 @@
/* Security model and label information */
memset(secmodel, 0, sizeof secmodel);
-if (virNodeGetSecurityModel(ctl-conn, secmodel) == -1) {
+ret_code = virNodeGetSecurityModel(ctl-conn, secmodel);
+if (ret_code == -1) {
+/* operation failure */
virDomainFree(dom);
return FALSE;
+} else if (ret_code == -2) {
+/* operation is not supported. noop */
} else {
/* Only print something if a security model is active */
if (secmodel.model[0] != '\0') {
@@ -1653,9 +1657,13 @@
/* Security labels are only valid for active domains */
memset(seclabel, 0, sizeof seclabel);
-if (virDomainGetSecurityLabel(dom, seclabel) == -1) {
+ret_code = virDomainGetSecurityLabel(dom, seclabel);
+if (ret == -1) {
+/* operation failure */
virDomainFree(dom);
return FALSE;
+} else if (ret == -2) {
+/* operation is not supported. noop */
} else {
if (seclabel.label[0] != '\0')
vshPrint(ctl, %-15s %s (%s)\n, _(Security label:),
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] KVM root mac address
A quick question - What is the correct root for dynamically generated KVM mac addresses? The docs (man virt-install) say 54:52:00 and I've seen Ubuntu docs on-line that say 52:54:00. Has someone got these mixed up? Thanks Paul -- Paul Reeves -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Wed, Jun 17, 2009 at 10:59:20PM +, 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 ip type=ipv6 address=2001:23::2 prefix=24/ but I think its possibly better to have a different element name ip6 address=2001:23::2 prefix=24/ since the former would not work if we ever needed to worry about non-IP based addresses. Either works for me, with a slight preference for the first version, on purely esthetic grounds. And even if we go with that, there's nothing keeping us from adding an ipx element as an alternative to the ip element in the future. Or a 3rd option is to group addresses by family addresses family='ipv4' ip address='122.0.0.3' prefix='24'/ ip address='24.24.224.4' prefix='24'/ /addresses addresses family='ipv6' ip address='2001:23::2' prefix='48'/ ip address='fe:33:55::33' prefix='64'/ /addresses adddresses family='ipx' ipx address='2423.4521.66.3.252.'/ /address Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Thu, Jun 18, 2009 at 09:15:54AM +0200, Jonas Eriksson wrote: On Wed, Jun 17, 2009 at 01:27:14PM -0700 David Lutterkort wrote: or forever hold your peace. While talking about the relax-ng schema, I would like to again raise my question earlier raised at the netcf-devel-list in order to get some input from the libvirt developers on this matter as well. 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. Not having the IP address restriction may collide head on with the connection-approach for some, as a connection probably have to be addressable. I however argue that this severly limits the uses for netcf, say for example to only bridge two interfaces without caring (and perhaps not wanting) to be something other then a package forwarder and not care about IP-address collisions. And in another case, the addressing is done using something other then IP. Indeed having a bridge without an IP address is an important feature for virtualization, because you may wish to have the host completely separate from guests in terms of IP subnets. Thus you would not want the bridge to have an IP address to which the guest can connect. So IP must be optional, allowing for a choice of 'none', 'manual' or 'dhcp', or in IPv6 case 'none', 'manual', 'autoconf', or 'dhcp'. For the bridges without added interfaces, an example is libvirt that have these private networks that I don't think I have to go in to in detail. Actually the libvirt private networks should not be visible via this virInterface/netcf API IMHO. I agree with your point though, that it may be desirable to create bridges without any interface attached. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Patch for Ruby Bindings to include attach detach device
Hi
David Lutterkort asked me to send this patch to the list so it could be
reviewed.
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.
Martin
--- orig_libvirt.c2009-06-18 12:17:47.0 +0200
+++ mine_libvirt.c2009-06-18 12:22:25.0 +0200
@@ -970,6 +970,22 @@
}
/*
+ * Call +virDomainAttachDevice+[
http://www.libvirt.org/html/libvirt-libvirt.html#virDomainAttachDevice]
+ */
+VALUE libvirt_dom_attach_device(VALUE s, VALUE xml) {
+gen_call_void(virDomainAttachDevice, conn(s),
+ domain_get(s), StringValueCStr(xml));
+}
+
+/*
+ * Call +virDomainDetachDevice+[
http://www.libvirt.org/html/libvirt-libvirt.html#virDomainDetachDevice]
+ */
+VALUE libvirt_dom_detach_device(VALUE s, VALUE xml) {
+gen_call_void(virDomainDetachDevice, conn(s),
+ domain_get(s), StringValueCStr(xml));
+}
+
+/*
* Call +virDomainCreateLinux+[
http://www.libvirt.org/html/libvirt-libvirt.html#virDomainCreateLinux]
*/
VALUE libvirt_conn_create_linux(int argc, VALUE *argv, VALUE c) {
@@ -1921,6 +1937,8 @@
rb_define_method(c_domain, autostart, libvirt_dom_autostart, 0);
rb_define_method(c_domain, autostart=, libvirt_dom_autostart_set, 1);
rb_define_method(c_domain, free, libvirt_dom_free, 0);
+rb_define_method(c_domain, attach_device, libvirt_dom_attach_device,
1);
+rb_define_method(c_domain, detach_device, libvirt_dom_detach_device,
1);
/*
* Class Libvirt::Domain::Info
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Fix QEMU security model info after capabilities refresh
A recent patch made the qemudGetCapabilities() method blow away and
re-create the QEMU driver's capabilities object. Unfortunately it did
not re-initialize the security model capabilities data. It also left
open the possibility that the QEMU driver could be left with no active
capabilities object at all in the case of OOM. Thus, this patch .
- Splits the security capabilities init code out to be callable
independantly of init of the security driver itself
- Makes qemudGetCapabilities repopopulate security driver info
- Don't free the existing capabilities object until we have
successfully created a new one
Daniel
Index: src/qemu_driver.c
===
RCS file: /data/cvs/libvirt/src/qemu_driver.c,v
retrieving revision 1.255
diff -u -p -r1.255 qemu_driver.c
--- src/qemu_driver.c 16 Jun 2009 15:42:46 - 1.255
+++ src/qemu_driver.c 18 Jun 2009 11:38:10 -
@@ -347,12 +347,43 @@ qemuReconnectDomains(struct qemud_driver
}
}
+
+static int
+qemudSecurityCapsInit(virSecurityDriverPtr secdrv,
+ virCapsPtr caps)
+{
+const char *doi, *model;
+
+doi = virSecurityDriverGetDOI(secdrv);
+model = virSecurityDriverGetModel(secdrv);
+
+caps-host.secModel.model = strdup(model);
+if (!caps-host.secModel.model) {
+char ebuf[1024];
+VIR_ERROR(_(Failed to copy secModel model: %s),
+ virStrerror(errno, ebuf, sizeof ebuf));
+return -1;
+}
+
+caps-host.secModel.doi = strdup(doi);
+if (!caps-host.secModel.doi) {
+char ebuf[1024];
+VIR_ERROR(_(Failed to copy secModel DOI: %s),
+ virStrerror(errno, ebuf, sizeof ebuf));
+return -1;
+}
+
+VIR_DEBUG(Initialized caps for security driver \%s\ with
+ DOI \%s\, model, doi);
+
+return 0;
+}
+
+
static int
qemudSecurityInit(struct qemud_driver *qemud_drv)
{
int ret;
-const char *doi, *model;
-virCapsPtr caps;
virSecurityDriverPtr security_drv;
ret = virSecurityDriverStartup(security_drv,
@@ -368,36 +399,17 @@ qemudSecurityInit(struct qemud_driver *q
}
qemud_drv-securityDriver = security_drv;
-doi = virSecurityDriverGetDOI(security_drv);
-model = virSecurityDriverGetModel(security_drv);
-VIR_DEBUG(Initialized security driver \%s\ with
- DOI \%s\, model, doi);
+VIR_INFO(Initialized security driver %s, security_drv-name);
/*
* Add security policy host caps now that the security driver is
* initialized.
*/
-caps = qemud_drv-caps;
-
-caps-host.secModel.model = strdup(model);
-if (!caps-host.secModel.model) {
-char ebuf[1024];
-VIR_ERROR(_(Failed to copy secModel model: %s),
- virStrerror(errno, ebuf, sizeof ebuf));
-return -1;
-}
+return qemudSecurityCapsInit(security_drv, qemud_drv-caps);
+}
-caps-host.secModel.doi = strdup(doi);
-if (!caps-host.secModel.doi) {
-char ebuf[1024];
-VIR_ERROR(_(Failed to copy secModel DOI: %s),
- virStrerror(errno, ebuf, sizeof ebuf));
-return -1;
-}
-return 0;
-}
/**
* qemudStartup:
@@ -1866,13 +1878,29 @@ static int qemudGetMaxVCPUs(virConnectPt
static char *qemudGetCapabilities(virConnectPtr conn) {
struct qemud_driver *driver = conn-privateData;
+virCapsPtr caps;
char *xml = NULL;
qemuDriverLock(driver);
+if ((caps = qemudCapsInit()) == NULL) {
+virReportOOMError(conn);
+goto cleanup;
+}
+
+if (qemu_driver-securityDriver
+qemudSecurityCapsInit(qemu_driver-securityDriver, caps) 0) {
+virCapabilitiesFree(caps);
+virReportOOMError(conn);
+goto cleanup;
+}
+
virCapabilitiesFree(qemu_driver-caps);
-if ((qemu_driver-caps = qemudCapsInit()) == NULL ||
-(xml = virCapabilitiesFormatXML(driver-caps)) == NULL)
+qemu_driver-caps = caps;
+
+if ((xml = virCapabilitiesFormatXML(driver-caps)) == NULL)
virReportOOMError(conn);
+
+cleanup:
qemuDriverUnlock(driver);
return xml;
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Fix QEMU security model info after capabilities refresh
On Thu, Jun 18, 2009 at 12:42:15PM +0100, Daniel P. Berrange wrote: A recent patch made the qemudGetCapabilities() method blow away and re-create the QEMU driver's capabilities object. Unfortunately it did not re-initialize the security model capabilities data. It also left open the possibility that the QEMU driver could be left with no active capabilities object at all in the case of OOM. Thus, this patch . - Splits the security capabilities init code out to be callable independantly of init of the security driver itself - Makes qemudGetCapabilities repopopulate security driver info - Don't free the existing capabilities object until we have successfully created a new one Looks fine, and should fix one of the bugs reported recently, ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Patch for Ruby Bindings to include attach detach device
On Thu, Jun 18, 2009 at 12:31:12PM +0200, Martin Gajdos wrote: Hi David Lutterkort asked me to send this patch to the list so it could be reviewed. 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. That looks fairly simple but David will double check :-) thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] problems with remote authentication with policykit
On Wed, Jun 17, 2009 at 06:36:16PM -0400, Jim Paris wrote: Daniel P. Berrange wrote: On Wed, Jun 17, 2009 at 05:51:27PM -0400, Jim Paris wrote: Daniel P. Berrange wrote: 17:34:59.360: debug : call:6947 : Doing call 70 (nil) 17:34:59.360: debug : call:7017 : We have the buck 70 0xbccef0 0xbccef0 17:34:59.433: debug : processCallRecvLen:6605 : Got length, now need 128 total (124 more) 17:34:59.434: debug : processCalls:6873 : Giving up the buck 70 0xbccef0 (nil) 17:34:59.434: debug : call:7048 : All done with our call 70 (nil) 0xbccef0 17:34:59.434: error : server_error:7231 : authentication failed 17:35:13.585: debug : do_open:999 : driver 4 remote returned ERROR 17:35:13.585: debug : virUnrefConnect:232 : unref connection 0xbc6a60 1 17:35:13.585: debug : virReleaseConnect:191 : release connection 0xbc6a60 If I kill the libvirtd process on the server, the client then finally prints: error: authentication failed error: failed to connect to the hypervisor and the client then exits. Ok, this bit definitely sounds like a server side bug, unless perhaps there is some buffering taking place in ssh or nc causing the errore reply packet to not be send back promptly I'll try to get some better traces of what's going on here. The hang aside, it seems libvirtd should be using org.libvirt.unix.monitor for the readonly connection? In this case the problem is that the remote client end is using netcat on the wrong UNIX socket. Thanks, that's it. With the attached patch on the client side, virsh --readonly and virt-viewer work fine over qemu+ssh://. -jim --- libvirt-0.6.4-orig/src/remote_internal.c 2009-05-29 10:55:26.0 -0400 +++ libvirt-0.6.4/src/remote_internal.c 2009-06-17 18:21:34.0 -0400 @@ -700,7 +700,10 @@ cmd_argv[j++] = strdup (priv-hostname); cmd_argv[j++] = strdup (netcat ? netcat : nc); cmd_argv[j++] = strdup (-U); -cmd_argv[j++] = strdup (sockname ? sockname : LIBVIRTD_PRIV_UNIX_SOCKET); + cmd_argv[j++] = strdup (sockname ? sockname : + (flags VIR_CONNECT_RO + ? LIBVIRTD_PRIV_UNIX_SOCKET_RO + : LIBVIRTD_PRIV_UNIX_SOCKET)); cmd_argv[j++] = 0; assert (j == nr_args); for (j = 0; j (nr_args-1); j++) Ok, I've committed this change Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] problems with remote authentication with policykit
On Wed, Jun 17, 2009 at 07:27:22PM -0400, Jim Paris wrote:
I wrote:
Ok, this bit definitely sounds like a server side bug, unless
perhaps there is some buffering taking place in ssh or nc
causing the errore reply packet to not be send back promptly
I'll try to get some better traces of what's going on here.
The error is getting back to the client. On the client,
remoteAuthenticate does fail and return -1. The client then
ends up blocked in the waitpid at remote_internal.c:877:
865 failed:
866 /* Close the socket if we failed. */
867 if (priv-sock = 0) {
868 if (priv-uses_tls priv-session) {
869 gnutls_bye (priv-session, GNUTLS_SHUT_RDWR);
870 gnutls_deinit (priv-session);
871 }
872 close (priv-sock);
873 #ifndef WIN32
874 if (priv-pid 0) {
875 pid_t reap;
876 do {
877 reap = waitpid(priv-pid, NULL, 0);
878 if (reap == -1 errno == EINTR)
879 continue;
880 } while (reap != -1 reap != priv-pid);
881 }
882 #endif
883 }
Nothing gets printed up until this point, which is why there's no
output.
I guess the client is waiting for SSH to die, which isn't happening
for some reason. That must be a bug on the server side, although
the client should also probably be more robust in this case..
We close the socket to the 'nc' process here so in theory it should
be getting a HUP event from poll or EOF from read, etc and then
exiting. Ominously though I see several patches to Fedora's 'nc'
RPM at least one of which is related to nc hanging forever after
getting HUP fback from poll(). What distro are you using ?
http://cvs.fedoraproject.org/viewvc/rpms/nc/F-11/
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote: On Wed, Jun 17, 2009 at 10:59:20PM +, 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) Very very very slowly ... I remember in 96 IETF meetings the propaganda that we were doomed if we didn't switch *right now* :- I also saw major brands of routers failing in faily nefastous ways when anxious people activated IPv6 a bit before everybody else. But jokes apart we need to have this working now ... I was thinking of sugesting an attribute ip type=ipv6 address=2001:23::2 prefix=24/ but I think its possibly better to have a different element name ip6 address=2001:23::2 prefix=24/ since the former would not work if we ever needed to worry about non-IP based addresses. Either works for me, with a slight preference for the first version, on purely esthetic grounds. And even if we go with that, there's nothing keeping us from adding an ipx element as an alternative to the ip element in the future. Or a 3rd option is to group addresses by family addresses family='ipv4' ip address='122.0.0.3' prefix='24'/ ip address='24.24.224.4' prefix='24'/ /addresses addresses family='ipv6' ip address='2001:23::2' prefix='48'/ ip address='fe:33:55::33' prefix='64'/ /addresses adddresses family='ipx' ipx address='2423.4521.66.3.252.'/ /address Hum, right now the syntax is far more restrictive for addressing, there is one address, period, with an optional route we need to extend that IMHO. [...] 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. 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 !-- Assignment of IP address to an interface -- define name=interface-addressing choice ref name=interface-addr-ipv4/ ref name=interface-addr-ipv6/ group ref name=interface-addr-ipv4/ ref name=interface-addr-ipv6/ /group /choice /define This allows one or 2 blocks of addresses ipv4, ipv6 or both define name=interface-addr-ipv4 element name=addresses attribute name=family valueipv4/value /attribute choice ref name=interface-addr-static/ ref name=interface-addr-dhcp/ /choice /element /define An IPv4 addresses block, allows for either static or dhcp define name=interface-addr-ipv6 element name=addresses attribute name=family valueipv6/value /attribute choice ref name=interface-addr-static/ ref name=interface-addr-dhcp/ /choice /element /define same for IPv6 define name=interface-addr-static oneOrMore element name=ip attribute name=addressref name=ip-addr//attribute attribute name=prefixref name=prefix-pattern//attribute /element /oneOrMore optional ref name=interface-addr-routes/ /optional /define A static addressing scheme is made of one or more ip elements with address and prefix followed by optional routing info define name=interface-addr-dhcp element name=dhcp optional attribute name=peerdns ref name=yes-or-no/ /attribute /optional /element /define For DHCP the only option is the peerdns yes/no attribute define name=interface-addr-routes element name=route attribute name=destination valuedefault/value /attribute attribute name=gatewayref name=ip-addr//attribute /element zeroOrMore element name=route attribute name=destinationref name=ip-addr//attribute attribute name=prefixref name=prefix-pattern//attribute optional attribute name=gatewayref name=ip-addr//attribute /optional /element /zeroOrMore /define And for routes we have at least one default route and then an optional set of routes with prefixes and optional gateways for that device. To note all the ip/dhcp/route constructs are similar for IPv4 and IPv6 as we don't check content precisely here. I assume it's sufficient. I think this revamps the capabilities quite a bit but I guess it should make sure we have IPv6 support on equal footing, and also incorporates I think most of Jim Fehlig remaks noted in the RNG. Examples of working definitions: interface type=ethernet startmode=onboot nameeth1/name mtu size=1500/ mac address=00:1A:A0:8F:39:A6/ addresses family='ipv4' dhcp peerdns=no/ /addresses
Re: [libvirt] KVM root mac address
On Thursday 18 June 2009, Paul Reeves wrote: A quick question - What is the correct root for dynamically generated KVM mac addresses? The docs (man virt-install) say 54:52:00 and I've seen Ubuntu docs on-line that say 52:54:00. Does no one know? Is this the wrong list? Paul -- Paul Reeves -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] problems with remote authentication with policykit
Daniel P. Berrange wrote: We close the socket to the 'nc' process here so in theory it should be getting a HUP event from poll or EOF from read, etc and then exiting. Ominously though I see several patches to Fedora's 'nc' RPM at least one of which is related to nc hanging forever after getting HUP fback from poll(). What distro are you using ? http://cvs.fedoraproject.org/viewvc/rpms/nc/F-11/ I'm using Debian. I've already had to switch from the netcat-traditional package to the netcat-openbsd package. Debian does already include that patch, but what a mess... Since already know libvirtd is installed on the remote host, would it make sense to just add a new set of options: libvirtd --socket-connect libvirtd --socket-connect-ro that do the same thing as nc -U on the appropriate socket? Then we know it would work everywhere, and have the added benefit that the client wouldn't need to know the location of the socket. -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] problems with remote authentication with policykit
On Thu, Jun 18, 2009 at 12:20:40PM -0400, Jim Paris wrote: Daniel P. Berrange wrote: We close the socket to the 'nc' process here so in theory it should be getting a HUP event from poll or EOF from read, etc and then exiting. Ominously though I see several patches to Fedora's 'nc' RPM at least one of which is related to nc hanging forever after getting HUP fback from poll(). What distro are you using ? http://cvs.fedoraproject.org/viewvc/rpms/nc/F-11/ I'm using Debian. I've already had to switch from the netcat-traditional package to the netcat-openbsd package. Debian does already include that patch, but what a mess... I know the reason why it gets stuck on the server end too - after an auth failure, the server won't kick off the client. The connection just remains in an unauthenticated state. This allows the client to (in theory) retry the authentication step, and gives us a little more flexibility for any future protocol changes we might need to make. I think the best way to solve the problem of 'nc' potentially not quitting promptly, is to simply have the remote client kill() the SSH client pid, rather than simply closing the socket doing waitpid() on the SSH client. This would ensure the waitpid promptly cleans up. Since already know libvirtd is installed on the remote host, would it make sense to just add a new set of options: libvirtd --socket-connect libvirtd --socket-connect-ro that do the same thing as nc -U on the appropriate socket? Then we know it would work everywhere, and have the added benefit that the client wouldn't need to know the location of the socket. If we'd thought of this originally, I would certainly have done it this way, but if we did this now, it would break compatability. ie new libvirt clients would be trying to run a binary that does not exist with old server deployments. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix memory reporting for inactive domains in the qemu driver.
Currently, 'info' will always report that mem = max mem. Make sure we
actually return the correct mem value.
Signed-off-by: Cole Robinson crobi...@redhat.com
---
src/qemu_driver.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index d3eb3ad..4e3e531 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2553,16 +2553,22 @@ static int qemudDomainGetInfo(virDomainPtr dom,
}
}
-err = qemudDomainGetMemoryBalloon(dom-conn, vm, balloon);
-if (err 0)
-goto cleanup;
-
info-maxMem = vm-def-maxmem;
-if (err == 0)
-/* Balloon not supported, so maxmem is always the allocation */
-info-memory = vm-def-maxmem;
-else
-info-memory = balloon;
+
+if (virDomainIsActive(vm)) {
+err = qemudDomainGetMemoryBalloon(dom-conn, vm, balloon);
+if (err 0)
+goto cleanup;
+
+if (err == 0)
+/* Balloon not supported, so maxmem is always the allocation */
+info-memory = vm-def-maxmem;
+else
+info-memory = balloon;
+} else {
+info-memory = vm-def-memory;
+}
+
info-nrVirtCpu = vm-def-vcpus;
ret = 0;
--
1.6.0.6
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] test driver: Fix domain ID after redefining a running VM
The ID of the existing VM was being unconditionally set to -1, which was
upsetting virt-manager.
Signed-off-by: Cole Robinson crobi...@redhat.com
---
src/test.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/test.c b/src/test.c
index 7dc0840..2a672a3 100644
--- a/src/test.c
+++ b/src/test.c
@@ -1623,16 +1623,16 @@ static virDomainPtr testDomainDefineXML(virConnectPtr
conn,
def)) == NULL) {
goto cleanup;
}
+def = NULL;
dom-persistent = 1;
-dom-def-id = -1;
+
event = virDomainEventNewFromObj(dom,
VIR_DOMAIN_EVENT_DEFINED,
VIR_DOMAIN_EVENT_DEFINED_ADDED);
-ret = virGetDomain(conn, def-name, def-uuid);
-def = NULL;
+ret = virGetDomain(conn, dom-def-name, dom-def-uuid);
if (ret)
-ret-id = -1;
+ret-id = dom-def-id;
cleanup:
virDomainDefFree(def);
--
1.6.0.6
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix raw storage volume creation for allocation capacity.
CreateXMLFrom changes accidentally caused all raw volume creation to be
fully allocated (as though allocation == capacity). Fix this.
Also force CreateXMLFrom to maintain the previous behavior: sparseness
should still be maintained since we search for holes when copying, and the
clone behavior hasn't been tested with anything but the broken behavior.
Signed-off-by: Cole Robinson crobi...@redhat.com
---
src/storage_backend_fs.c |2 +-
src/storage_driver.c |5 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/storage_backend_fs.c b/src/storage_backend_fs.c
index 0e93e54..c3d66b5 100644
--- a/src/storage_backend_fs.c
+++ b/src/storage_backend_fs.c
@@ -1047,7 +1047,7 @@ static int createRaw(virConnectPtr conn,
goto cleanup;
}
-remain = vol-capacity;
+remain = vol-allocation;
if (inputfd != -1) {
int amtread = -1;
diff --git a/src/storage_driver.c b/src/storage_driver.c
index 71e64a4..57a93c1 100644
--- a/src/storage_driver.c
+++ b/src/storage_driver.c
@@ -1377,6 +1377,11 @@ storageVolumeCreateXMLFrom(virStoragePoolPtr obj,
if (newvol-capacity origvol-capacity)
newvol-capacity = origvol-capacity;
+/* Make sure allocation is at least as large as the destination cap,
+ * to make absolutely sure we copy all possible contents */
+if (newvol-allocation origvol-capacity;
+newvol-allocation = origvol-capacity;
+
if (!backend-buildVolFrom) {
virStorageReportError(obj-conn, VIR_ERR_NO_SUPPORT,
%s, _(storage pool does not support volume
creation from an existing volume));
--
1.6.0.6
--
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 +, 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 ip type=ipv6 address=2001:23::2 prefix=24/ but I think its possibly better to have a different element name ip6 address=2001:23::2 prefix=24/ since the former would not work if we ever needed to worry about non-IP based addresses. Either works for me, with a slight preference for the first version, on purely esthetic grounds. And even if we go with that, there's nothing keeping us from adding an ipx element as an alternative to the ip element in the future. Or a 3rd option is to group addresses by family addresses family='ipv4' ip address='122.0.0.3' prefix='24'/ ip address='24.24.224.4' prefix='24'/ /addresses addresses family='ipv6' ip address='2001:23::2' prefix='48'/ ip address='fe:33:55::33' prefix='64'/ /addresses adddresses family='ipx' ipx address='2423.4521.66.3.252.'/ /address I don't see that that buys us anything that we wouldn't have with ip type='ipv4' address='122.0.0.3' prefix='24'/ ip type='ipv4' address='24.24.224.4' prefix='24'/ ip type='ipv6' address='2001:23::2' prefix='48'/ ip type='ipv6' address='fe:33:55::33' prefix='64'/ ipx address='2423.4521.66.3.252.'/ _maybe_ enclosed in a addresses 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 Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote: On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote: I was thinking of sugesting an attribute ip type=ipv6 address=2001:23::2 prefix=24/ but I think its possibly better to have a different element name ip6 address=2001:23::2 prefix=24/ since the former would not work if we ever needed to worry about non-IP based addresses. Either works for me, with a slight preference for the first version, on purely esthetic grounds. And even if we go with that, there's nothing keeping us from adding an ipx element as an alternative to the ip element in the future. Or a 3rd option is to group addresses by family addresses family='ipv4' ip address='122.0.0.3' prefix='24'/ ip address='24.24.224.4' prefix='24'/ /addresses addresses family='ipv6' ip address='2001:23::2' prefix='48'/ ip address='fe:33:55::33' prefix='64'/ /addresses adddresses family='ipx' ipx address='2423.4521.66.3.252.'/ /address Hum, right now the syntax is far more restrictive for addressing, there is one address, period, with an optional route we need to extend that IMHO. [...] 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. 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. 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 !-- Assignment of IP address to an interface -- define name=interface-addressing choice ref name=interface-addr-ipv4/ ref name=interface-addr-ipv6/ group ref name=interface-addr-ipv4/ ref name=interface-addr-ipv6/ /group /choice /define This allows one or 2 blocks of addresses ipv4, ipv6 or both 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 define name=interface-addressing group optional ref name=interface-addr-ipv4/ optional optional ref name=interface-addr-ipv6/ optional /group /define define name=interface-addr-ipv4 element name=addresses attribute name=family valueipv4/value /attribute choice ref name=interface-addr-static/ ref name=interface-addr-dhcp/ /choice /element /define An IPv4 addresses block, allows for either static or dhcp define name=interface-addr-ipv6 element name=addresses attribute name=family valueipv6/value /attribute choice ref name=interface-addr-static/ ref name=interface-addr-dhcp/ /choice /element /define same for IPv6 Not quite - IPv6 needs to allow for more options - static - fully manual setup - autoconf - auto assign addresses/routes. Assume DNS etc via dhcpv4 or manual - autoconf + statless dhcp - auto assign addresses/routes. DNS etc via dhcpv6 - statefull dhcp - everything via dhcpv6 Check out this preso for an overview if you dare. http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf In all cases we need to include ip tags to show the manual, or automatically configured addresses/routes. define name=interface-addr-static oneOrMore element name=ip attribute name=addressref name=ip-addr//attribute attribute name=prefixref name=prefix-pattern//attribute /element /oneOrMore optional ref name=interface-addr-routes/ /optional /define A static addressing scheme is made of one or more ip elements with address and prefix followed by optional routing info define name=interface-addr-dhcp element name=dhcp optional attribute name=peerdns ref name=yes-or-no/ /attribute /optional /element /define For DHCP the only option is the peerdns yes/no attribute define name=interface-addr-routes element name=route attribute name=destination valuedefault/value /attribute attribute name=gatewayref name=ip-addr//attribute /element zeroOrMore element name=route attribute name=destinationref name=ip-addr//attribute attribute name=prefixref name=prefix-pattern//attribute
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Thu, Jun 18, 2009 at 09:42:40AM -0700, David Lutterkort wrote: On Thu, 2009-06-18 at 10:46 +0100, Daniel P. Berrange wrote: On Wed, Jun 17, 2009 at 10:59:20PM +, 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 ip type=ipv6 address=2001:23::2 prefix=24/ but I think its possibly better to have a different element name ip6 address=2001:23::2 prefix=24/ since the former would not work if we ever needed to worry about non-IP based addresses. Either works for me, with a slight preference for the first version, on purely esthetic grounds. And even if we go with that, there's nothing keeping us from adding an ipx element as an alternative to the ip element in the future. Or a 3rd option is to group addresses by family addresses family='ipv4' ip address='122.0.0.3' prefix='24'/ ip address='24.24.224.4' prefix='24'/ /addresses addresses family='ipv6' ip address='2001:23::2' prefix='48'/ ip address='fe:33:55::33' prefix='64'/ /addresses adddresses family='ipx' ipx address='2423.4521.66.3.252.'/ /address I don't see that that buys us anything that we wouldn't have with ip type='ipv4' address='122.0.0.3' prefix='24'/ ip type='ipv4' address='24.24.224.4' prefix='24'/ ip type='ipv6' address='2001:23::2' prefix='48'/ ip type='ipv6' address='fe:33:55::33' prefix='64'/ ipx address='2423.4521.66.3.252.'/ 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. 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [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 +, 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 addresses/ tag and just stick a type=ipv4|ipv6 attribute on the ip/ tags .. though that requirs that we do the same for route/ 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 !-- Assignment of IP address to an interface -- define name=interface-addressing choice ref name=interface-addr-ipv4/ ref name=interface-addr-ipv6/ group ref name=interface-addr-ipv4/ ref name=interface-addr-ipv6/ /group /choice /define Ok. This allows one or 2 blocks of addresses ipv4, ipv6 or both define name=interface-addr-ipv4 element name=addresses attribute name=family valueipv4/value /attribute choice ref name=interface-addr-static/ ref name=interface-addr-dhcp/ /choice /element /define An IPv4 addresses block, allows for either static or dhcp define name=interface-addr-ipv6 element name=addresses attribute name=family valueipv6/value /attribute choice ref name=interface-addr-static/ ref name=interface-addr-dhcp/ /choice /element /define 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: [libvirt] [PATCH] Fix logging in libvirt_lxc controller
Taking a second look at the log level code and documentation, there seems to be some confusion around the value of '0'. It's not one of the defined log priorities, but it is mentioned in the documentation on the website both as meaning log everything and no logging at all. In the code, there are times when it's accepted (for outputs), rejected (for filters) and ignored (for the loglevel). For the outputs, specifying level 0 is effectively the same as specifying level 1. I'm wondering if there is any historical reason for the '0' value, or if we could just do away with it completely? Thanks, Amy -- 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, Jun 18, 2009 at 06:06:27PM +0100, Daniel P. Berrange wrote: On Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote: define name=interface-addr-ipv6 element name=addresses attribute name=family valueipv6/value /attribute choice ref name=interface-addr-static/ ref name=interface-addr-dhcp/ /choice /element /define same for IPv6 Not quite - IPv6 needs to allow for more options - static - fully manual setup - autoconf - auto assign addresses/routes. Assume DNS etc via dhcpv4 or manual - autoconf + statless dhcp - auto assign addresses/routes. DNS etc via dhcpv6 - statefull dhcp - everything via dhcpv6 Of course there's also the need for a 'none' case. My proposal for addresses family='' element intended that to be implied. Check out this preso for an overview if you dare. http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf In all cases we need to include ip tags to show the manual, or automatically configured addresses/routes. Some examples might help understand all these options 1. no IPv6 sysconfig file: IPV6=no XML ...no addresses element for IPv6 2. IPv6 link local only, no autoconf, no static address, no dhcp IPV6=yes IPV6_AUTOCONF=no DHCPV6=no XML to define it addresses family='ipv6'/ XML when running addresses family='ipv6' ip address=fe80::215:58ff:fe6e:5 prefix=64/ (the link local addr) /addresses 3. IPv6 link local, no autoconf, one static address, no dhcp IPV6=yes IPV6_AUTOCONF=no DHCPV6=no IPV6ADDR=3ffe::0:5::1 XML to define it addresses family='ipv6' ip address=3ffe::0:5::1 prefix=128/ (the static addr) /addresses XML when running addresses family='ipv6' ip address=fe80::215:58ff:fe6e:5 prefix=64/ (the link local addr) ip address=3ffe::0:5::1 prefix=128/ (the static addr) /addresses 4. IPv6 link local, autoconf, no static address, no dhcp IPV6=yes IPV6_AUTOCONF=yes DHCPV6=no XML to define it addresses family='ipv6' autoconf/ /addresses XML when running addresses family='ipv6' autoconf/ ip address=fe80::215:58ff:fe6e:5 prefix=64/ (the link local addr) ip address=3ffe:1234:0:5::6 prefix=128/ (the automatic addr) /addresses 5. IPv6 link local, autoconf, no static address, dhcp for services IPV6=yes IPV6_AUTOCONF=yes DHCPV6=yes XML to define it addresses family='ipv6' autoconf/ dhcp/ /addresses XML when running addresses family='ipv6' autoconf/ dhcp/ ip address=fe80::215:58ff:fe6e:5 prefix=64/ (the link local addr) ip address=3ffe:1234:0:5::6 prefix=128/ (the automatic addr) /addresses 6. IPv6 link local, no autoconf, no static address, dhcp for everything IPV6=yes IPV6_AUTOCONF=no DHCPV6=yes XML to define it addresses family='ipv6' dhcp/ /addresses XML when running addresses family='ipv6' autoconf/ dhcp/ ip address=fe80::215:58ff:fe6e:5 prefix=64/ (the link local addr) ip address=3ffe:7891:0:5::6 prefix=128/ (the dhcp addr) /addresses It may be aso possible to list extra static addresses, even while autoconf and/or dhcp are enabled. Can't remember off hand. Basically every single combo you can think of is probably needed. For brevity, i left out routes here. You can more or less asume zero or more routes are needed in all these scenarios. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [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): interface type=ethernet startmode=none nameeth0/name mtu size=1492/ mac address=aa:bb:cc:dd:ee:ff/ dhcp peerdns=no/ /interface and one for the bridge with a vlan enslaved: interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface type=vlan device=eth0 tag=42/ /bridge /interface Similarly, a bond enslaved to a bridge, together with a vlan on that bond also enslaved to the bridge would look like interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface type=bond namebond0/name bond mode=active-backup interface type=ethernet nameeth1/name /interface interface type=ethernet nameeth0/name /interface /bond /interface interface type=vlan device=bond0 tag=42/ /bridge /interface David -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] problems with remote authentication with policykit
Daniel P. Berrange wrote: On Thu, Jun 18, 2009 at 12:20:40PM -0400, Jim Paris wrote: I'm using Debian. I've already had to switch from the netcat-traditional package to the netcat-openbsd package. Debian does already include that patch, but what a mess... I know the reason why it gets stuck on the server end too - after an auth failure, the server won't kick off the client. The connection just remains in an unauthenticated state. This allows the client to (in theory) retry the authentication step, and gives us a little more flexibility for any future protocol changes we might need to make. Makes sense -- it would be nice for the client to be able to retry with read-only authentication when read-write fails, without having to reopen the SSH connection. Or is that not possible, since it would require opening a different socket? I think the best way to solve the problem of 'nc' potentially not quitting promptly, is to simply have the remote client kill() the SSH client pid, rather than simply closing the socket doing waitpid() on the SSH client. This would ensure the waitpid promptly cleans up. Yeah, that should fix the hang. Since already know libvirtd is installed on the remote host, would it make sense to just add a new set of options: libvirtd --socket-connect libvirtd --socket-connect-ro that do the same thing as nc -U on the appropriate socket? Then we know it would work everywhere, and have the added benefit that the client wouldn't need to know the location of the socket. If we'd thought of this originally, I would certainly have done it this way, but if we did this now, it would break compatability. ie new libvirt clients would be trying to run a binary that does not exist with old server deployments. It could still be done in a backwards-compatible way. Something like: ssh server libvirtd --socket-connect || nc -U /socket Or, if you really wanted to be nice to us Debian folks, ssh server libvirtd --socket-connect || nc.openbsd -U /socket || nc -U /socket (while the Debian libvirt package does depend on netcat-openbsd, there's nothing that forces the local nc symlink to point to the openbsd version over the traditional version, if both are installed). It's definitely messy, but it would really be nice to remove the need for the client to know which netcat to use, or where sockets are located, etc. Hmm, as I think about it more, I guess netcat is also used for VNC connections? I wonder if that could be implemented as a dynamic port forward on the existing SSH connection, which would also eliminate the need for a second connection (and having to enter the password a second time)... -jim -- 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, Jun 18, 2009 at 05:53:59PM +, David Lutterkort wrote: 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): interface type=ethernet startmode=none nameeth0/name mtu size=1492/ mac address=aa:bb:cc:dd:ee:ff/ dhcp peerdns=no/ /interface and one for the bridge with a vlan enslaved: interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface type=vlan device=eth0 tag=42/ /bridge /interface Similarly, a bond enslaved to a bridge, together with a vlan on that bond also enslaved to the bridge would look like interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface type=bond namebond0/name bond mode=active-backup interface type=ethernet nameeth1/name /interface interface type=ethernet nameeth0/name /interface /bond /interface interface type=vlan device=bond0 tag=42/ /bridge /interface I think this is a really unpleasant format to deal with. IMHO there should not be nesting for bridge/bond 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 interface type='bond' namebond0/name bond mode=active-backup interface name='eth0'/ interface name='eth1'/ /bond /interface interface type='vlan' namebond0.42/name vlan tag='42' interface name='bond0' /bridge /interface interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface name=bond0.42/ /bridge interface If you added more vlans, then they just appear as more interfaces at the top level interface type='vlan' namebond0.47/name vlan tag='47' interface name='bond0' /bridge /interface interface type='vlan' namebond0.48/name vlan tag='48'
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On 06/18/2009 01:53 PM, David Lutterkort wrote: 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. I agree that the API call to retrieve the current configuration should be separate from the API call to retrieve the current state of the interface. If you mix them, a get config / write config pair would no longer be a NOP (for example, you would end up with the IP addresses/routes obtained from DHCP being written into the config file, and that can't be good.) -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/5] Add virConnectListDefinedInterfaces/NumOfDefinedInterfaces
This patch adds everything but the backend implementation of two APIs that were requested during review of my patch to add virsh commands that expose the virInterface* API. These count and list interfaces on the host that are currently inactive (ie down). virConnectListInterfaces and virConnectNumOfInterfaces will list/count *only* those interfaces that are currently active. With these functions in place, I'll be able to add the --inactive and --all flags to iface-list, as suggested by danpb. Implementation of the backend of these two functions is waiting for two things: 1) supporting code in libnetcf, and 2) implementation of the rest of the backend driver functions for virInterface* (ready in the wings and waiting to go). -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/4] Define Public API for new virInterface Functions.
This adds virConnectListDefinedInterfaces() and
virConnectNumOfDefinedInterfaces().
---
include/libvirt/libvirt.h|5 +
include/libvirt/libvirt.h.in |5 +
src/libvirt_public.syms |5 +
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h
index bff6985..78e89c3 100644
--- a/include/libvirt/libvirt.h
+++ b/include/libvirt/libvirt.h
@@ -890,6 +890,11 @@ int virConnectListInterfaces
(virConnectPtr conn,
char **const names,
int maxnames);
+int virConnectNumOfDefinedInterfaces (virConnectPtr conn);
+int virConnectListDefinedInterfaces (virConnectPtr conn,
+ char **const names,
+ int maxnames);
+
virInterfacePtr virInterfaceLookupByName (virConnectPtr conn,
const char *name);
virInterfacePtr virInterfaceLookupByMACString (virConnectPtr conn,
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 869c361..ba2b6f0 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -890,6 +890,11 @@ int virConnectListInterfaces
(virConnectPtr conn,
char **const names,
int maxnames);
+int virConnectNumOfDefinedInterfaces (virConnectPtr conn);
+int virConnectListDefinedInterfaces (virConnectPtr conn,
+ char **const names,
+ int maxnames);
+
virInterfacePtr virInterfaceLookupByName (virConnectPtr conn,
const char *name);
virInterfacePtr virInterfaceLookupByMACString (virConnectPtr conn,
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 3f0f4bc..184492f 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -285,4 +285,9 @@ LIBVIRT_0.6.4 {
virConnectDomainXMLToNative;
} LIBVIRT_0.6.3;
+LIBVIRT_0.6.5 {
+global:
+ virConnectNumOfDefinedInterfaces;
+ virConnectListDefinedInterfaces;
+} LIBVIRT_0.6.4;
# define new API here using predicted next version number
--
1.6.0.6
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/4] Implement Public API of new virInterface functions
---
src/libvirt.c | 89 +++--
1 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index bf49018..c5c868d 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -5502,9 +5502,9 @@ virInterfaceGetConnect (virInterfacePtr iface)
* virConnectNumOfInterfaces:
* @conn: pointer to the hypervisor connection
*
- * Provides the number of interfaces on the physical host.
+ * Provides the number of active interfaces on the physical host.
*
- * Returns the number of interface found or -1 in case of error
+ * Returns the number of active interfaces found or -1 in case of error
*/
int
virConnectNumOfInterfaces(virConnectPtr conn)
@@ -5540,7 +5540,8 @@ error:
* @names: array to collect the list of names of interfaces
* @maxnames: size of @names
*
- * Collect the list of physical host interfaces, and store their names in
@names
+ * Collect the list of active physical host interfaces,
+ * and store their names in @names
*
* Returns the number of interfaces found or -1 in case of error
*/
@@ -5578,6 +5579,88 @@ error:
}
/**
+ * virConnectNumOfDefinedInterfaces:
+ * @conn: pointer to the hypervisor connection
+ *
+ * Provides the number of defined (inactive) interfaces on the physical host.
+ *
+ * Returns the number of defined interface found or -1 in case of error
+ */
+int
+virConnectNumOfDefinedInterfaces(virConnectPtr conn)
+{
+DEBUG(conn=%p, conn);
+
+virResetLastError();
+
+if (!VIR_IS_CONNECT(conn)) {
+virLibConnError(NULL, VIR_ERR_INVALID_CONN, __FUNCTION__);
+return (-1);
+}
+
+if (conn-interfaceDriver
conn-interfaceDriver-numOfDefinedInterfaces) {
+int ret;
+ret = conn-interfaceDriver-numOfDefinedInterfaces (conn);
+if (ret 0)
+goto error;
+return ret;
+}
+
+virLibConnError (conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
+
+error:
+/* Copy to connection error object for back compatability */
+virSetConnError(conn);
+return -1;
+}
+
+/**
+ * virConnectListDefinedInterfaces:
+ * @conn: pointer to the hypervisor connection
+ * @names: array to collect the list of names of interfaces
+ * @maxnames: size of @names
+ *
+ * Collect the list of defined (inactive) physical host interfaces,
+ * and store their names in @names.
+ *
+ * Returns the number of interfaces found or -1 in case of error
+ */
+int
+virConnectListDefinedInterfaces(virConnectPtr conn,
+char **const names,
+int maxnames)
+{
+DEBUG(conn=%p, names=%p, maxnames=%d, conn, names, maxnames);
+
+virResetLastError();
+
+if (!VIR_IS_CONNECT(conn)) {
+virLibConnError(NULL, VIR_ERR_INVALID_CONN, __FUNCTION__);
+return (-1);
+}
+
+if ((names == NULL) || (maxnames 0)) {
+virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
+goto error;
+}
+
+if (conn-interfaceDriver conn-interfaceDriver-listDefinedInterfaces)
{
+int ret;
+ret = conn-interfaceDriver-listDefinedInterfaces (conn, names,
maxnames);
+if (ret 0)
+goto error;
+return ret;
+}
+
+virLibConnError (conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
+
+error:
+/* Copy to connection error object for back compatability */
+virSetConnError(conn);
+return -1;
+}
+
+/**
* virInterfaceLookupByName:
* @conn: pointer to the hypervisor connection
* @name: name for the interface
--
1.6.0.6
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/4] Define internal driver API for new virInterface functions
---
src/driver.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/driver.h b/src/driver.h
index ca759ff..2502c63 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -508,6 +508,12 @@ typedef int
(*virDrvListInterfaces) (virConnectPtr conn,
char **const names,
int maxnames);
+typedef int
+(*virDrvNumOfDefinedInterfaces) (virConnectPtr conn);
+typedef int
+(*virDrvListDefinedInterfaces) (virConnectPtr conn,
+ char **const names,
+ int maxnames);
typedef virInterfacePtr
(*virDrvInterfaceLookupByName) (virConnectPtr conn,
const char *name);
@@ -551,6 +557,8 @@ struct _virInterfaceDriver {
virDrvClose close;
virDrvNumOfInterfacesnumOfInterfaces;
virDrvListInterfaces listInterfaces;
+virDrvNumOfDefinedInterfaces numOfDefinedInterfaces;
+virDrvListDefinedInterfaces listDefinedInterfaces;
virDrvInterfaceLookupByName interfaceLookupByName;
virDrvInterfaceLookupByMACString interfaceLookupByMACString;
virDrvInterfaceGetXMLDescinterfaceGetXMLDesc;
--
1.6.0.6
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 4/4] Implement client and server side of RPC for new virInterface functions
---
qemud/remote.c | 51
qemud/remote_dispatch_args.h |1 +
qemud/remote_dispatch_prototypes.h | 14 +++
qemud/remote_dispatch_ret.h|2 +
qemud/remote_dispatch_table.h | 10 +
qemud/remote_protocol.c| 29 ++
qemud/remote_protocol.h| 27 +
qemud/remote_protocol.x| 20 +-
src/remote_internal.c | 74
9 files changed, 227 insertions(+), 1 deletions(-)
diff --git a/qemud/remote.c b/qemud/remote.c
index 1071c21..38cefe4 100644
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -2657,6 +2657,57 @@ remoteDispatchListInterfaces (struct qemud_server
*server ATTRIBUTE_UNUSED,
}
static int
+remoteDispatchNumOfDefinedInterfaces (struct qemud_server *server
ATTRIBUTE_UNUSED,
+ struct qemud_client *client
ATTRIBUTE_UNUSED,
+ virConnectPtr conn,
+ remote_error *rerr,
+ void *args ATTRIBUTE_UNUSED,
+ remote_num_of_defined_interfaces_ret
*ret)
+{
+
+ret-num = virConnectNumOfDefinedInterfaces (conn);
+if (ret-num == -1) {
+remoteDispatchConnError(rerr, conn);
+return -1;
+}
+
+return 0;
+}
+
+static int
+remoteDispatchListDefinedInterfaces (struct qemud_server *server
ATTRIBUTE_UNUSED,
+ struct qemud_client *client
ATTRIBUTE_UNUSED,
+ virConnectPtr conn,
+ remote_error *rerr,
+ remote_list_defined_interfaces_args *args,
+ remote_list_defined_interfaces_ret *ret)
+{
+
+if (args-maxnames REMOTE_DEFINED_INTERFACE_NAME_LIST_MAX) {
+remoteDispatchFormatError (rerr,
+ %s, _(maxnames
REMOTE_DEFINED_INTERFACE_NAME_LIST_MAX));
+return -1;
+}
+
+/* Allocate return buffer. */
+if (VIR_ALLOC_N(ret-names.names_val, args-maxnames) 0) {
+remoteDispatchOOMError(rerr);
+return -1;
+}
+
+ret-names.names_len =
+virConnectListDefinedInterfaces (conn,
+ ret-names.names_val, args-maxnames);
+if (ret-names.names_len == -1) {
+VIR_FREE(ret-names.names_len);
+remoteDispatchConnError(rerr, conn);
+return -1;
+}
+
+return 0;
+}
+
+static int
remoteDispatchInterfaceLookupByName (struct qemud_server *server
ATTRIBUTE_UNUSED,
struct qemud_client *client
ATTRIBUTE_UNUSED,
virConnectPtr conn,
diff --git a/qemud/remote_dispatch_args.h b/qemud/remote_dispatch_args.h
index 1322a54..9dacfb8 100644
--- a/qemud/remote_dispatch_args.h
+++ b/qemud/remote_dispatch_args.h
@@ -116,3 +116,4 @@
remote_interface_destroy_args val_remote_interface_destroy_args;
remote_domain_xml_from_native_args val_remote_domain_xml_from_native_args;
remote_domain_xml_to_native_args val_remote_domain_xml_to_native_args;
+remote_list_defined_interfaces_args
val_remote_list_defined_interfaces_args;
diff --git a/qemud/remote_dispatch_prototypes.h
b/qemud/remote_dispatch_prototypes.h
index a20ac4e..c114304 100644
--- a/qemud/remote_dispatch_prototypes.h
+++ b/qemud/remote_dispatch_prototypes.h
@@ -478,6 +478,13 @@ static int remoteDispatchListDefinedDomains(
remote_error *err,
remote_list_defined_domains_args *args,
remote_list_defined_domains_ret *ret);
+static int remoteDispatchListDefinedInterfaces(
+struct qemud_server *server,
+struct qemud_client *client,
+virConnectPtr conn,
+remote_error *err,
+remote_list_defined_interfaces_args *args,
+remote_list_defined_interfaces_ret *ret);
static int remoteDispatchListDefinedNetworks(
struct qemud_server *server,
struct qemud_client *client,
@@ -716,6 +723,13 @@ static int remoteDispatchNumOfDefinedDomains(
remote_error *err,
void *args,
remote_num_of_defined_domains_ret *ret);
+static int remoteDispatchNumOfDefinedInterfaces(
+struct qemud_server *server,
+struct qemud_client *client,
+virConnectPtr conn,
+remote_error *err,
+void *args,
+remote_num_of_defined_interfaces_ret *ret);
static int remoteDispatchNumOfDefinedNetworks(
struct qemud_server *server,
struct qemud_client *client,
diff --git a/qemud/remote_dispatch_ret.h b/qemud/remote_dispatch_ret.h
index d83ffd5..c1835de 100644
--- a/qemud/remote_dispatch_ret.h
+++ b/qemud/remote_dispatch_ret.h
@@ -98,3 +98,5 @@
remote_interface_define_xml_ret val_remote_interface_define_xml_ret;
remote_domain_xml_from_native_ret val_remote_domain_xml_from_native_ret;
remote_domain_xml_to_native_ret
Re: [libvirt] KVM root mac address
Paul Reeves schrieb: On Thursday 18 June 2009, Paul Reeves wrote: A quick question - What is the correct root for dynamically generated KVM mac addresses? The docs (man virt-install) say 54:52:00 and I've seen Ubuntu docs on-line that say 52:54:00. Does no one know? Is this the wrong list? Paul Yes it is. Try www.linux-kvm.org and search for a list there. This list here is for libvirt. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
CORRECTION: [PATCH 0/4]! Was: [libvirt] [PATCH 0/5] Add virConnectListDefinedInterfaces/NumOfDefinedInterfaces
Sorry, I miscounted :-) There really are only 4 patch messages, not 5. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH] Fix raw storage volume creation for allocation capacity.
Cole Robinson wrote:
CreateXMLFrom changes accidentally caused all raw volume creation to be
fully allocated (as though allocation == capacity). Fix this.
Also force CreateXMLFrom to maintain the previous behavior: sparseness
should still be maintained since we search for holes when copying, and the
clone behavior hasn't been tested with anything but the broken behavior.
Signed-off-by: Cole Robinson crobi...@redhat.com
---
src/storage_backend_fs.c |2 +-
src/storage_driver.c |5 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/storage_backend_fs.c b/src/storage_backend_fs.c
index 0e93e54..c3d66b5 100644
--- a/src/storage_backend_fs.c
+++ b/src/storage_backend_fs.c
@@ -1047,7 +1047,7 @@ static int createRaw(virConnectPtr conn,
goto cleanup;
}
-remain = vol-capacity;
+remain = vol-allocation;
if (inputfd != -1) {
int amtread = -1;
diff --git a/src/storage_driver.c b/src/storage_driver.c
index 71e64a4..57a93c1 100644
--- a/src/storage_driver.c
+++ b/src/storage_driver.c
@@ -1377,6 +1377,11 @@ storageVolumeCreateXMLFrom(virStoragePoolPtr obj,
if (newvol-capacity origvol-capacity)
newvol-capacity = origvol-capacity;
+/* Make sure allocation is at least as large as the destination cap,
+ * to make absolutely sure we copy all possible contents */
+if (newvol-allocation origvol-capacity;
+newvol-allocation = origvol-capacity;
+
Of course the tweak I make at the last second is completely invalid
syntax :(. Besides needing the obvious fix above, the patch does work as
expected.
Thanks,
Cole
if (!backend-buildVolFrom) {
virStorageReportError(obj-conn, VIR_ERR_NO_SUPPORT,
%s, _(storage pool does not support volume
creation from an existing volume));
--
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, Jun 18, 2009 at 02:22:16PM -0400, Laine Stump wrote: On 06/18/2009 01:53 PM, David Lutterkort wrote: 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. I agree that the API call to retrieve the current configuration should be separate from the API call to retrieve the current state of the interface. If you mix them, a get config / write config pair would no longer be a NOP (for example, you would end up with the IP addresses/routes obtained from DHCP being written into the config file, and that can't be good.) That is why the virInterfaceDumpXML() elements has a 'flags' argument. With no flags set it would return the config matching the interfaces' current state. If VIR_INTEFACE_INACTIVE is set, then it would always return the persistent offline config. So an app doing a read+modify+write sequence should always use VIR_INTERFACE_INACTIVE. This model matches that done for our other APIs. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [netcf-devel] [libvirt] [RFC] Reporting host interface status/statistics via netcf/libvirt, and listing active vs. inactive interfaces
On Thu, Jun 18, 2009 at 07:05:29PM +0100, Daniel P. Berrange wrote: On Thu, Jun 18, 2009 at 05:53:59PM +, David Lutterkort wrote: 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): interface type=ethernet startmode=none nameeth0/name mtu size=1492/ mac address=aa:bb:cc:dd:ee:ff/ dhcp peerdns=no/ /interface and one for the bridge with a vlan enslaved: interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface type=vlan device=eth0 tag=42/ /bridge /interface Similarly, a bond enslaved to a bridge, together with a vlan on that bond also enslaved to the bridge would look like interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface type=bond namebond0/name bond mode=active-backup interface type=ethernet nameeth1/name /interface interface type=ethernet nameeth0/name /interface /bond /interface interface type=vlan device=bond0 tag=42/ /bridge /interface I think this is a really unpleasant format to deal with. IMHO there should not be nesting for bridge/bond 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. So to deal with multiple leaf nodes you either end up having signficantly overlapping configs between leaves, or have one leaf defining the main branch, and other leaves only defining sub-branches. I don't think either is really satisfactory, and can be avoiding by defining a flat list of interfaces, and encoding the parent/ child relationships in each. 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. interface type='bond' namebond0/name bond mode=active-backup interface name='eth0'/ interface name='eth1'/ /bond /interface So this shows children, while the XML for the physical interface could show the inverse. interface type='physical' nameeth0/name master interface name='bond0'/ /master /interface 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [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 interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface type=bond namebond0/name bond mode=active-backup interface type=ethernet nameeth1/name /interface interface type=ethernet nameeth0/name /interface /bond /interface interface type=vlan device=bond0 tag=42/ /bridge /interface 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 interface 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 bridge/bond tags. For bond, 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 interface type='bond' namebond0/name bond mode=active-backup interface name='eth0'/ interface name='eth1'/ /bond /interface This requires that you check that the interfaces named there are physical NIC's at runtime. interface type='vlan' namebond0.42/name vlan tag='42' interface name='bond0' /bridge /interface 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. interface type=bridge startmode=onboot namebr0/name ... bridge stp=off interface name=bond0.42/ /bridge interface 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 attachment: nesting.png-- 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 bridge/bond 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. interface type='bond' namebond0/name bond mode=active-backup interface name='eth0'/ interface name='eth1'/ /bond /interface 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]) interface type='physical' nameeth0/name master interface name='bond0'/ /master /interface 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 18:10 +0100, Daniel P. Berrange wrote: I don't see that that buys us anything that we wouldn't have with ip type='ipv4' address='122.0.0.3' prefix='24'/ ip type='ipv4' address='24.24.224.4' prefix='24'/ ip type='ipv6' address='2001:23::2' prefix='48'/ ip type='ipv6' address='fe:33:55::33' prefix='64'/ ipx address='2423.4521.66.3.252.'/ 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 address/ 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 address tags is that it makes it cleaner to bundle addressing info like ip 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 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: [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
[libvirt] [PATCH 0/1] Make NPIV support work with older kernels
Here is a patch that makes NPIV support work with older kernels that have vport_create and delete in /sys/class/scsi_host/hostN instead of /sys/class/fc_host/hostN It doesn't look to me like there is a single place to find those files that works with both old and new kernels, so the new code checks both places at runtime. Dave -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/1] Refactor HAL Linux code
* src/node_device_hal_linux.c, src/node_device.c: Older kernels had
vport_create and delete in /sys/class/scsi_host not /sys/class/fc_host. This
patch causes libvirt to look in both places.
---
src/node_device.c | 23 +-
src/node_device.h |2 +-
src/node_device_hal_linux.c | 186 +-
3 files changed, 134 insertions(+), 77 deletions(-)
diff --git a/src/node_device.c b/src/node_device.c
index d01695d..4a936de 100644
--- a/src/node_device.c
+++ b/src/node_device.c
@@ -369,6 +369,7 @@ nodeDeviceVportCreateDelete(virConnectPtr conn,
int operation)
{
int retval = 0;
+struct stat st;
char *operation_path = NULL, *vport_name = NULL;
const char *operation_file = NULL;
@@ -388,7 +389,7 @@ nodeDeviceVportCreateDelete(virConnectPtr conn,
}
if (virAsprintf(operation_path,
-%shost%d%s,
+%s/host%d%s,
LINUX_SYSFS_FC_HOST_PREFIX,
parent_host,
operation_file) 0) {
@@ -398,6 +399,26 @@ nodeDeviceVportCreateDelete(virConnectPtr conn,
goto cleanup;
}
+if (stat(operation_path, st) != 0) {
+VIR_FREE(operation_path);
+if (virAsprintf(operation_path,
+%s/host%d%s,
+LINUX_SYSFS_SCSI_HOST_PREFIX,
+parent_host,
+operation_file) 0) {
+
+virReportOOMError(conn);
+retval = -1;
+goto cleanup;
+}
+}
+
+if (stat(operation_path, st) != 0) {
+VIR_ERROR(_(No vport operation path found for host%d), parent_host);
+retval = -1;
+goto cleanup;
+}
+
VIR_DEBUG(_(Vport operation path is '%s'), operation_path);
if (virAsprintf(vport_name,
diff --git a/src/node_device.h b/src/node_device.h
index db01624..e745eb4 100644
--- a/src/node_device.h
+++ b/src/node_device.h
@@ -30,7 +30,7 @@
#define LINUX_SYSFS_SCSI_HOST_PREFIX /sys/class/scsi_host
#define LINUX_SYSFS_SCSI_HOST_POSTFIX device
-#define LINUX_SYSFS_FC_HOST_PREFIX /sys/class/fc_host/
+#define LINUX_SYSFS_FC_HOST_PREFIX /sys/class/fc_host
#define VPORT_CREATE 0
#define VPORT_DELETE 1
diff --git a/src/node_device_hal_linux.c b/src/node_device_hal_linux.c
index b76235d..b669a3a 100644
--- a/src/node_device_hal_linux.c
+++ b/src/node_device_hal_linux.c
@@ -34,58 +34,82 @@
#ifdef __linux__
-int check_fc_host_linux(union _virNodeDevCapData *d)
+
+static int fc_file_exists(const char *prefix,
+ int host,
+ const char *file)
{
+int retval = 0;
char *sysfs_path = NULL;
-char *wwnn_path = NULL;
-char *wwpn_path = NULL;
-char *p = NULL;
-int fd = -1, retval = 0;
-char buf[64];
struct stat st;
-VIR_DEBUG(_(Checking if host%d is an FC HBA), d-scsi_host.host);
-
-if (virAsprintf(sysfs_path, %s/host%d,
-LINUX_SYSFS_FC_HOST_PREFIX,
-d-scsi_host.host) 0) {
+if (virAsprintf(sysfs_path, %s/host%d%s, prefix, host, file) 0) {
virReportOOMError(NULL);
retval = -1;
goto out;
}
-if (stat(sysfs_path, st) != 0) {
-/* Not an FC HBA; not an error, either. */
-goto out;
+if (stat(sysfs_path, st) == 0) {
+
+retval = 1;
+VIR_ERROR(_('%s' exists), sysfs_path);
+
+} else {
+VIR_ERROR(_('%s' does not exist), sysfs_path);
}
-d-scsi_host.flags |= VIR_NODE_DEV_CAP_FLAG_HBA_FC_HOST;
+out:
+VIR_FREE(sysfs_path);
+return retval;
+}
-if (virAsprintf(wwnn_path, %s/node_name,
-sysfs_path) 0) {
+
+static int open_wwn_file(const char *prefix,
+ int host,
+ const char *file,
+ int *fd)
+{
+int retval = 0;
+char *wwn_path = NULL;
+
+if (virAsprintf(wwn_path, %s/host%d/%s, prefix, host, file) 0) {
virReportOOMError(NULL);
retval = -1;
goto out;
}
-if ((fd = open(wwnn_path, O_RDONLY)) 0) {
-retval = -1;
-VIR_ERROR(_(Failed to open WWNN path '%s' for reading),
- wwnn_path);
-goto out;
+if ((*fd = open(wwn_path, O_RDONLY)) != -1) {
+VIR_ERROR(_(Opened WWN path '%s' for reading),
+ wwn_path);
+} else {
+VIR_ERROR(_(Failed to open WWN path '%s' for reading),
+ wwn_path);
+}
+
+out:
+VIR_FREE(wwn_path);
+return retval;
+}
+
+
+static int get_wwn(int host, const char *file, char **wwn)
+{
+char *p = NULL;
+int fd = -1, retval = 0;
+char buf[64];
+
+if (open_wwn_file(LINUX_SYSFS_FC_HOST_PREFIX, host, file, fd) 0) {
+goto out;
}
memset(buf, 0, sizeof(buf));
if (saferead(fd, buf, sizeof(buf)) 0) {
Re: [libvirt] [PATCH] fix virsh dominfo returns error when virNodeGetSecurityModel() is not supported.
Hi Dan,
Daniel P. Berrange wrote:
The explanation of virNodeGetSecurityModel() and
virNodeGetSecurityModel() in libvirt.c is return -2
when hypervisor drivers don't support these operations.
But these functions return -1 in this case, and so
cmdDominfo() in virsh.c returns FALSE.
This API description about returning -1 vs -2 is totally bogus.
With the remote driver we only have a boolean success vs fail
status, so there is no way to return 2 different error codes. In
addition already have a way to report methods which are not
supported, by giving back a VIR_ERR_NO_SUPPORT code, so there is
no need for a special '-2' value in any case.
I make a patch.
- virNodeGetSecurityModel() and virNodeGetSecurityModel()
return -2 when drivers don't supprted these operations.
- In CmdDominfo(), it is no operation when virNodeGetSecurityModel()
and virNodeGetSecurityModel() return -2.
I'm attaching a alternate patch which just checks for the
VIR_ERR_NO_SUPPORT code and simply ignores that error.
This should deal with the error scenario you saw with Xen.
I'm also fixing the API description to match reality and
adding in several missing 'memset()' calls, because the
drivers should not assume the caller has zero'd these
structs.
Ok, I see.
Index: src/virsh.c
===
RCS file: /data/cvs/libvirt/src/virsh.c,v
retrieving revision 1.210
diff -u -p -u -r1.210 virsh.c
--- src/virsh.c 3 Jun 2009 12:13:52 - 1.210
+++ src/virsh.c 18 Jun 2009 11:14:44 -
@@ -1643,8 +1643,10 @@ cmdDominfo(vshControl *ctl, const vshCmd
/* Security model and label information */
memset(secmodel, 0, sizeof secmodel);
if (virNodeGetSecurityModel(ctl-conn,secmodel) == -1) {
-virDomainFree(dom);
-return FALSE;
+if (last_error-code != VIR_ERR_NO_SUPPORT) {
+virDomainFree(dom);
+return FALSE;
+}
} else {
/* Only print something if a security model is active */
if (secmodel.model[0] != '\0') {
Don't check last_error-code of virDomainGetSecurityLabel()?
should check the same as virNodeGetSecurityModel().
Thanks
Tatsuro Enokura
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
