Re: [libvirt] make docs fails on EL5
Le mercredi 16 novembre 2011 à 11:57 +0800, Osier Yang a écrit : 于 2011年11月16日 11:12, shu ming 写道: It seems tit is he same issue as the thread below, the docs can not be generated in some Linux distros. It may be caused by the incompatibility of document tools in these distros. http://www.mail-archive.com/libvir-list@redhat.com/msg47624.html They are not the same problem if I'm correct, as it seems xhtml1-dtd is installed on Daniel's host, (the process broke during generating the html files). And it looks like the error is caused by there is some tags in the html is not campatible with W3C, though not sure why it comes. Not sure if it's relevant, I'm using xhtml1-dtds 1.0-7.1.1 (from the base CentOS 5.7 repo) Regards, Osier -- Daniel Berteaud FIREWALL-SERVICES SARL. Société de Services en Logiciels Libres Technopôle Montesquieu 33650 MARTILLAC Tel : 05 56 64 15 32 Fax : 05 56 64 15 32 Mail: dan...@firewall-services.com Web : http://www.firewall-services.com -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] fix a bug in remoteSerializeTypedParameters
This is a fatal typo believed to be very likely to happen when using
both i and j at the same time for indexing.
---
daemon/remote.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 857835e..97c9538 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -710,7 +710,7 @@ remoteSerializeTypedParameters(virTypedParameterPtr params,
goto cleanup;
}
val[j].value.type = params[i].type;
-switch (params[j].type) {
+switch (params[i].type) {
case VIR_TYPED_PARAM_INT:
val[j].value.remote_typed_param_value_u.i = params[i].value.i;
break;
--
1.7.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib 29/37] Add GVirConfigDeviceInput
On Fri, Nov 11, 2011 at 08:32:30PM +0100, Marc-André Lureau wrote: The bus argument could be an enum too (xen (paravirtualized), ps2 and usb) I've just changed this. Christophe pgpVICztbG0IW.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt support on QNX
Hi, I'm planning to use libvirt in a remote machine which is running on QNX RTOS. Whether libvirt is ported to QNX, if not any problems in porting libvirt lib to QNX ? Appreciate your help on this. Thanks, Chandrashekhar -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib 29/37] Add GVirConfigDeviceInput
On Tue, Nov 15, 2011 at 07:32:49PM +0100, Marc-André Lureau wrote: On Tue, Nov 15, 2011 at 7:25 PM, Christophe Fergeau cferg...@redhat.com wrote: What are you referring to? GVirConfigGraphicsSpice and GVirConfigInterface? yes, all the classes that are nodes under devices I dropped the Device from GraphicsSpice because the name was getting really long (not a great reason for doing this). I used the GVirConfigInterface name because there was already such a file in git, so I reused it. GVirConfigInterfaceNetwork look better to me than GVirConfigDeviceInterfaceNetwork (DeviceInterface is awkward imo). So I'd tend to change GraphicsSpice, but keep Interface. Christophe pgpMG75DvWnDw.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] compile fail on FreeBSD
On Tue, Nov 15, 2011 at 03:24:11PM -0700, Eric Blake wrote:
On 11/15/2011 04:08 AM, Daniel P. Berrange wrote:
On Fri, Nov 11, 2011 at 05:31:14PM -0700, Eric Blake wrote:
This failure on FreeBSD 8.2 popped up this week, and I suspect Dan's
virnetdev refactoring, but haven't had time to further investigate and
fix it:
util/virnetdev.c: In function 'virNetDevExists':
util/virnetdev.c:93: error: storage size of 'ifr' isn't known
util/virnetdev.c:95: warning: implicit declaration of function
'virNetDevSetupControl'
and so on. Probably some conditional compilation going wrong when on a
non-Linux machine.
This code is protected by a
#ifdef HAVE_NET_IF_H
So if BSD's net/if.h does not provide any 'struct ifreq' then we need to
fix things.
net/if.h is standardized by POSIX, but 'struct ifreq' is not (the only
portable struct in that header is 'struct if_nameindex').
Does anyone know if the 'struct ifreq' / SIOCGIFHWADDR / SIOCGIFMTU / etc
ioctl() stuff is entirely Linux specific, or is it semi portable to other
UNIX ?
Solaris 10 has struct ifreq, also provided by net/if.h, but with
different fields:
Linux:
struct ifreq
{
union
{
char ifrn_name[16];
} ifr_ifrn;
union
{
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr ifru_netmask;
struct sockaddr ifru_hwaddr;
short int ifru_flags;
int ifru_ivalue;
int ifru_mtu;
struct ifmap ifru_map;
char ifru_slave[16];
char ifru_newname[16];
__caddr_t ifru_data;
} ifr_ifru;
};
Solaris:
struct ifreq {
char ifr_name[16];
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
char ifru_oname[16];
struct sockaddr ifru_broadaddr;
int ifru_index;
short ifru_flags;
int ifru_metric;
char ifru_data[1];
char ifru_enaddr[6];
int if_muxid[2];
struct ifr_ppaflags {
short ifrup_flags;
short ifrup_filler;
uint_t ifrup_ppa;
} ifru_ppaflags;
struct ifr_dnld_reqs {
uint32_t v_addr;
uint32_t m_addr;
uint32_t ex_addr;
uint32_t size;
} ifru_dnld_req;
struct ifr_fddi_stats {
uint32_t stat_size;
uint32_t fddi_stats;
} ifru_fddi_stat;
struct ifr_netmapents {
uint32_t map_ent_size,
entry_number;
uint32_t fddi_map_ent;
} ifru_netmapent;
struct ifr_fddi_gen_struct {
uint32_t ifru_fddi_gioctl;
uint32_t ifru_fddi_gaddr;
} ifru_fddi_gstruct;
} ifr_ifru;
};
ifr_name is common between the two, but I'm thinking the ioctl's are
going to be Linux-specific, so we're better off conditionalizing the
code to not even attempt use of 'struct ifreq' outside Linux.
Ok, lets just change it to #ifdef __linux__ then, and if someone wants
to port it to Solaris / BSD they can figure out the better approach :-)
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] Add support for systemd init service
On Tue, Nov 15, 2011 at 04:02:23PM -0700, Eric Blake wrote: On 11/15/2011 04:35 AM, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com Followup to https://www.redhat.com/archives/libvir-list/2011-November/msg00580.html This patch adds support for a systemd init service for libvirtd and libvirt-guests. The libvirtd.service is *not* written to use socket activation, since we want libvirtd to start on boot so it can do guest auto-start. Looks like you addressed all the v2 review comments. ACK with one nit: In v2: - Fix AC_MSG_HELP wrapping - Fix %makeinstall target - Explicitly handle 'none' for --with-initscript - Revert rename of libvirt-guests.sh +[AC_HELP_STRING([--with-init-script@:@=STYLE@:@], +[Style of init script to install: redhat, systemd, systemd+redhat, + upstart, auto, none @:@default=auto@:@])]) +init_redhat=no +init_systemd=no +case $with_init_script in +systemd+redhat) + init_redhat=yes + init_systemd=yes + ;; +systemd) + init_systemd=yes + ;; +redhat) + init_redhat=yes + ;; +none) + ;; +*) Where is upstart handled? Without an explicit clause, you might be accidentally turning it into with_init_script=redhat. Ha, I knew I was forgetting one bit. We have never had any rules to actually install the upstart file before, we just included it as an example. Time for a v3 Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v5 4/4] qemu/rbd: improve rbd device specification
On Tue, Nov 15, 2011 at 05:05:27PM -0700, Eric Blake wrote:
On 10/31/2011 07:29 PM, Josh Durgin wrote:
From: Sage Weil s...@newdream.net
+if (sec) {
+char *base64 = NULL;
+
+secret = (char *)conn-secretDriver-getValue(sec,
secret_size, 0,
+
VIR_SECRET_GET_VALUE_INTERNAL_CALL);
+if (secret == NULL) {
+qemuReportError(VIR_ERR_INTERNAL_ERROR,
+_(could not get the value of the secret
for username %s),
+disk-auth.username);
+goto error;
+}
+/* qemu/librbd wants it base64 encoded */
+base64_encode_alloc(secret, secret_size, base64);
+if (!base64) {
+virReportOOMError();
+goto error;
+}
+virBufferEscape(opt, :, :key=%s:auth_supported=cephx none,
+base64);
+VIR_FREE(base64);
The command line that we pass to qemu gets logged. But what happens if
the secret was marked as ephemeral - could we be violating the premise
of not exposing passwords to too broad an audience? Or are we already
safe in that the log entries created by virCommand can only be exposed
to users that already can get at the secret information by other means?
Maybe this means we should we be adding capabilities into virCommand to
prevent the logging of the actual secret (whether base64-encoded or
otherwise), and instead log an alternate string? That is, should
virCommand be tracking parallel argv arrays; the real array passed to
exec() but never logged, and the alternate array (normally matching the
real one, but which can differ in this particular case of passing an
argument that contains a password)?
The passing of secrets on the command line is just a temporary hack
we're doing to prove the overall handling of passwords for Ceph. The
real plan is to set them via monitor command in QEMU, but we're just
waiting for some QEMU work before changing libvirt todo that.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V1 1/9] Add support for VLAN filtering
On Tue, Nov 15, 2011 at 05:46:21PM -0700, Eric Blake wrote: On 10/26/2011 09:11 AM, Stefan Berger wrote: Apologies for delaying so long on reviewing this. This patch adds support for filtering of VLAN (802.1Q) traffic to the parser and makes us of the ebtables support for VLAN filtering. This code now enables the filtering of traffic in chains with prefix 'vlan'. Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com --- docs/schemas/nwfilter.rng | 47 + src/conf/nwfilter_conf.c | 102 ++ src/conf/nwfilter_conf.h | 17 + src/nwfilter/nwfilter_ebiptables_driver.c | 35 ++ 4 files changed, 201 insertions(+) This didn't apply cleanly for me. Am I missing the review of another pre-requisite series? Or is it just something where you need to rebase and post a v2 for easier review? It could be some of my netdev API renaming invalidated it ? Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] util : fix compile error on fedora14 Add src/util/virnetdevbandwidth.h, src/util/virnetdevveth.h, src/util/virnetdevvportprofile.h to private symbols.
On Wed, Nov 16, 2011 at 09:36:06AM +0800, ta...@linux.vnet.ibm.com wrote: From: Eli Qiao ta...@linux.vnet.ibm.com Signed-off-by: Eli Qiao ta...@linux.vnet.ibm.com --- src/libvirt_private.syms | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 7b96a3c..f178662 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1201,9 +1201,19 @@ virNetDevSetIPv4Address; virNetDevSetMAC; virNetDevSetMTU; virNetDevSetMTUFromDevice; +virNetDevSetName; +virNetDevSetNamespace; virNetDevSetOnline; +# virnetdevbandwidth.h +virNetDevBandwidthClear; +virNetDevBandwidthCopy; +virNetDevBandwidthEqual; +virNetDevBandwidthFree; +virNetDevBandwidthSet; + + # virnetdevbridge.h virNetDevBridgeAddPort; virNetDevBridgeCreate; @@ -1221,6 +1231,15 @@ virNetDevTapCreateInBridgePort; virNetDevTapDelete; +# virnetdevveth.h +virNetDevVethCreate; +virNetDevVethDelete; + + +# virnetdevvportprofile.h +virNetDevVPortProfileEqual; + + # virnetmessage.h virNetMessageClear; virNetMessageDecodeNumFDs; ACK Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix build with polkit0
On Tue, Nov 15, 2011 at 03:39:28PM -0700, Jim Fehlig wrote: I missed adding libvirt_driver_remote.la to libvirtd_LDADD in commit b8adfcc6, which didn't cause a problem in 0.9.6 but results in this build error in 0.9.7 libvirtd-remote.o: In function `remoteDispatchAuthPolkit': remote.c:(.text+0x188dd): undefined reference to `virNetServerGetDBusConn' --- daemon/Makefile.am |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index e8c47ae..59db217 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -156,6 +156,10 @@ endif if WITH_NWFILTER libvirtd_LDADD += ../src/libvirt_driver_nwfilter.la endif + +if HAVE_POLKIT0 +libvirtd_LDADD += ../src/libvirt_driver_remote.la +endif NACK this is wrong - it is already linked to libvirt.so, which is linked to libvirtd, so tthis results in 2 copies of the code linked. What is missing here is likely the entry for virNetServerGetDBusConn in libvirt_private.syms Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt support on QNX
On Wed, Nov 16, 2011 at 03:32:19PM +0530, Chandrashekhar Jamadarkhani (cjamadar) wrote: Hi, I'm planning to use libvirt in a remote machine which is running on QNX RTOS. Whether libvirt is ported to QNX, if not any problems in porting libvirt lib to QNX ? AFAIK, no one has ever said they've tried libvirt on QNX. I presume you are talking about the libvirt RPC client driver only, or are you planning to create some kind of hypervisor driver too ? The libvirt RPC client driver is probably the most portable bit of our code, only depending on a good sockets layer implementation GNUTLS. So if you pass flags to configure to disable all drivers, except for the remote driver, you should be able to build it without undue trouble. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt support on QNX
Hi Daniel, Thanks Daniel for the info. I was talking only about porting libvirt RPC client driver to qnx for starting/monitoring VMs running on remote RHEL based host. Let me try porting the libvirt RPC client driver to QNX. Thanks, Chandrashekhar -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Wednesday, November 16, 2011 4:07 PM To: Chandrashekhar Jamadarkhani (cjamadar) Cc: libvir-list@redhat.com Subject: Re: [libvirt] libvirt support on QNX On Wed, Nov 16, 2011 at 03:32:19PM +0530, Chandrashekhar Jamadarkhani (cjamadar) wrote: Hi, I'm planning to use libvirt in a remote machine which is running on QNX RTOS. Whether libvirt is ported to QNX, if not any problems in porting libvirt lib to QNX ? AFAIK, no one has ever said they've tried libvirt on QNX. I presume you are talking about the libvirt RPC client driver only, or are you planning to create some kind of hypervisor driver too ? The libvirt RPC client driver is probably the most portable bit of our code, only depending on a good sockets layer implementation GNUTLS. So if you pass flags to configure to disable all drivers, except for the remote driver, you should be able to build it without undue trouble. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V1 1/9] Add support for VLAN filtering
On 11/15/2011 07:46 PM, Eric Blake wrote:
On 10/26/2011 09:11 AM, Stefan Berger wrote:
Apologies for delaying so long on reviewing this.
This patch adds support for filtering of VLAN (802.1Q) traffic to the
parser and makes us of the ebtables support for VLAN filtering. This code
now enables the filtering of traffic in chains with prefix 'vlan'.
Signed-off-by: Stefan Bergerstef...@linux.vnet.ibm.com
---
docs/schemas/nwfilter.rng | 47 +
src/conf/nwfilter_conf.c | 102
++
src/conf/nwfilter_conf.h | 17 +
src/nwfilter/nwfilter_ebiptables_driver.c | 35 ++
4 files changed, 201 insertions(+)
This didn't apply cleanly for me. Am I missing the review of another
pre-requisite series? Or is it just something where you need to rebase
and post a v2 for easier review?
Yes, sorry for the confusion. This builds on top of the following two
series:
https://www.redhat.com/archives/libvir-list/2011-October/msg01227.html
then came this one (already ACKed):
https://www.redhat.com/archives/libvir-list/2011-October/msg01360.html
+static bool
+checkVlanVlanID(enum attrDatatype datatype, union data *value,
+virNWFilterRuleDefPtr nwf ATTRIBUTE_UNUSED,
ATTRIBUTE_UNUSED not necessary here, since...
+nwItemDesc *item ATTRIBUTE_UNUSED)
+{
+int32_t res;
+
+res = value-ui;
+if (res 0 || res 4095) {
+res = -1;
+}
+
+if (res != -1) {
+nwf-p.vlanHdrFilter.dataVlanID.u.u16 = res;
...this uses nwf. Similar comment applies elsewhere in the patch.
Thanks. Fixing it.
Overall, it looks sane, but I didn't compile test it.
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix tip of git
On 11/15/2011 04:41 PM, Eric Blake wrote: On 11/15/2011 12:40 PM, Stefan Berger wrote: I get these type of compilation errors: In file included from util/virnetdevvportprofile.c:25:0: util/virnetdevvportprofile.h:49:13: error: expected specifier-qualifier-list before 'uint8_t' util/virnetdevvportprofile.c: In function 'virNetDevVPortProfileEqual': util/virnetdevvportprofile.c:45:33: error: 'structanonymous' has no member named 'managerID' On which platform (or more likely, with which version of libc headers?) FC 14 with glibc-devel-2.13-2.i686 glibc-devel-2.13-2.x86_64. Stefan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Add support for systemd init service
From: Daniel P. Berrange berra...@redhat.com This patch adds support for a systemd init service for libvirtd and libvirt-guests. The libvirtd.service is *not* written to use socket activation, since we want libvirtd to start on boot so it can do guest auto-start. The libvirt-guests.service is pretty lame, just exec'ing the original init script for now. Ideally we would factor out the functionality, into some shared tool. Instead of ./configure --with-init-script=redhat You can now do ./configure --with-init-script=systemd Or better still: ./configure --with-init-script=systemd+redhat We can also now support install of the upstart init script In v4: - Print chosen init script type in configure.ac summary - Support upstart install - Error from configure on unsupported requests - Remove bogus dep from policykit install to redhat init * configure.ac: Add systemd, and systemd+redhat options to --with-init-script option * daemon/Makefile.am: Install systemd services * daemon/libvirtd.sysconf: Add note about unused env variable with systemd * daemon/libvirtd.service.in: libvirtd systemd service unit * libvirt.spec.in: Add scripts to installing systemd services and migrating from legacy init scripts * tools/Makefile.am: Install systemd services * tools/libvirt-guests.init.sh: Rename to tools/libvirt-guests.init.in * tools/libvirt-guests.service.in: systemd service unit --- configure.ac| 37 +++ daemon/.gitignore |1 + daemon/Makefile.am | 98 +- daemon/libvirtd.service.in | 20 daemon/libvirtd.sysconf |3 + libvirt.spec.in | 93 +++- po/POTFILES.in |2 +- tools/Makefile.am | 61 +++- tools/libvirt-guests.service.in | 13 + 9 files changed, 279 insertions(+), 49 deletions(-) create mode 100644 daemon/libvirtd.service.in create mode 100644 tools/libvirt-guests.service.in diff --git a/configure.ac b/configure.ac index 3b7535e..c663f7b 100644 --- a/configure.ac +++ b/configure.ac @@ -329,16 +329,33 @@ dnl init script flavor dnl AC_MSG_CHECKING([for init script flavor]) AC_ARG_WITH([init-script], -[AC_HELP_STRING([--with-init-script=@:@redhat|auto|none@:@], -[Style of init script to install @:@default=auto@:@])]) -if test x$with_init_script = x || test x$with_init_script = xauto; then -if test $cross_compiling = yes || test ! -f /etc/redhat-release; then -with_init_script=none -else -with_init_script=redhat -fi -fi -AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_RED_HAT], test x$with_init_script = xredhat) +[AC_HELP_STRING([--with-init-script@:@=STYLE@:@], +[Style of init script to install: redhat, systemd, systemd+redhat, + upstart, auto, none @:@default=auto@:@])]) +init_redhat=no +init_systemd=no +case $with_init_script in +systemd+redhat) + init_redhat=yes + init_systemd=yes + ;; +systemd) + init_systemd=yes + ;; +redhat) + init_redhat=yes + ;; +none) + ;; +*) + if test $cross_compiling != yes test -f /etc/redhat-release; then + init_redhat=yes + with_init_script=redhat + fi + ;; +esac +AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_RED_HAT], test $init_redhat = yes) +AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_SYSTEMD], test $init_systemd = yes) AC_MSG_RESULT($with_init_script) dnl RHEL-5 has a peculiar version of Xen, which requires some special casing diff --git a/daemon/.gitignore b/daemon/.gitignore index ab3d093..2873143 100644 --- a/daemon/.gitignore +++ b/daemon/.gitignore @@ -7,6 +7,7 @@ Makefile.in libvirt_qemud libvirtd libvirtd.init +libvirtd.service libvirtd*.logrotate libvirtd.8 libvirtd.8.in diff --git a/daemon/Makefile.am b/daemon/Makefile.am index 59db217..9ccbb5b 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -174,22 +174,25 @@ policyfile = libvirtd.policy-1 endif endif -install-data-local: install-init install-data-sasl install-data-polkit \ - install-logrotate +install-data-local: install-init-redhat install-init-systemd install-init-upstart \ + install-data-sasl install-data-polkit \ + install-logrotate install-sysctl mkdir -p $(DESTDIR)$(localstatedir)/log/libvirt mkdir -p $(DESTDIR)$(localstatedir)/run/libvirt mkdir -p $(DESTDIR)$(localstatedir)/lib/libvirt -uninstall-local:: uninstall-init uninstall-data-sasl uninstall-data-polkit +uninstall-local:: uninstall-init-redhat uninstall-init-systemd uninstall-init-upstart \ + uninstall-data-sasl uninstall-data-polkit \ + uninstall-sysctl rmdir $(DESTDIR)$(localstatedir)/log/libvirt || : rmdir
Re: [libvirt] [libvirt-glib 29/37] Add GVirConfigDeviceInput
On Wed, Nov 16, 2011 at 11:04 AM, Christophe Fergeau cferg...@redhat.com wrote: I dropped the Device from GraphicsSpice because the name was getting really long (not a great reason for doing this). I used the GVirConfigInterface name because there was already such a file in git, so I reused it. Better being explicit and consistent than taking shortcuts. I am afraid if we drop the Device prefix, we may confuse it with host devices http://libvirt.org/formatnetwork.html. The same applies in libvirt-gobject, let's be consistent. -- Marc-André Lureau -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib 2/3] Add some basic information to README
On Tue, Nov 15, 2011 at 08:12:28PM +0200, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- README | 29 + 1 files changed, 29 insertions(+), 0 deletions(-) diff --git a/README b/README index e69de29..866ec53 100644 --- a/README +++ b/README @@ -0,0 +1,29 @@ +libvirt-glib + + +libvirt is a C toolkit to interact with the virtualization capabilities +of recent versions of Linux (and other OSes). It is free software +available under the GNU Lesser General Public License. Virtualization of +the Linux Operating System means the ability to run multiple instances of +Operating Systems concurrently on a single hardware system where the basic +resources are driven by a Linux instance. The library aim at providing +long term stable C API initially for the Xen paravirtualization but +should be able to integrate other virtualization mechanisms if needed. + +libvirt-glib wraps libvirt to provide a high-level object-oriented API better +suited for glib-based applications. + +libvirt-glib is Free Software and licenced under LGPLv2+. + +Dependencies + + +- Required: + - glib-2.0 + - gobject-2.0 + - libxml-2.0 + - libvirt + +- Optional: + - gobject-introspection + - Vala (build-time only) ACK, with Alon's typo fix Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib 3/3] Release 0.0.1
On Tue, Nov 15, 2011 at 08:12:29PM +0200, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org --- NEWS |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index e69de29..015fab8 100644 --- a/NEWS +++ b/NEWS @@ -0,0 +1,5 @@ +0.0.1 += + +First public release. + ACK, but make the heading 0.0.1 - Nov 12, 2011 Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib 29/37] Add GVirConfigDeviceInput
On Wed, Nov 16, 2011 at 01:25:43PM +0100, Marc-André Lureau wrote: I am afraid if we drop the Device prefix, we may confuse it with host devices http://libvirt.org/formatnetwork.html. In this case this would be ConfigInterfaceNetwork vs ConfigNetwork. Christophe pgp7RkzT4BtTv.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt PATCHv5 1/2] add DHCP snooping
On 11/10/2011 03:28 PM, David L Stevens wrote: This patch adds DHCP Snooping support to libvirt. Signed-off-by: David L Stevensdlstev...@us.ibm.com --- docs/formatnwfilter.html.in | 17 + examples/xml/nwfilter/no-ip-spoofing.xml |5 + src/Makefile.am |2 + src/nwfilter/nwfilter_dhcpsnoop.c| 745 ++ src/nwfilter/nwfilter_dhcpsnoop.h| 38 ++ src/nwfilter/nwfilter_driver.c |6 + src/nwfilter/nwfilter_gentech_driver.c | 53 ++- 7 files changed, 853 insertions(+), 13 deletions(-) create mode 100644 src/nwfilter/nwfilter_dhcpsnoop.c create mode 100644 src/nwfilter/nwfilter_dhcpsnoop.h diff --git a/docs/formatnwfilter.html.in b/docs/formatnwfilter.html.in index 8df4a93..8003320 100644 --- a/docs/formatnwfilter.html.in +++ b/docs/formatnwfilter.html.in @@ -1775,6 +1775,23 @@ br/br/ In case a VM is resumed after suspension or migrated, IP address detection will be restarted. +br/br/ + Variableiip_learning/i may be used to specify + the IP address learning method. Valid values areiany/i,idhcp/i, + orinone/i. The default value isiany/i, meaning that libvirt + may use any packet to determine the address in use by a VM. A value of +idhcp/i specifies that libvirt should only honor DHCP server-assigned + addresses with valid leases. Ifiip_learning/i is set toinone/i, + libvirt does not do address learning and referencingiIP/i without + assigning it an explicit value is an error. +br/br/ + Use ofiip_learning=dhcp/i (DHCP snooping) provides additional + anti-spoofing security, especially when combined with a filter allowing + only trusted DHCP servers to assign addresses. If the DHCP lease expires, + the VM will no longer be able to use the IP address until it acquires a + new, valid lease from a DHCP server. If the VM is migrated, it must get + a new valid DHCP lease to use an IP address (e.g., by + bringing the VM interface down and up again). /p Can you add a sentence that it must be used in combination with a filter that allows DHCP traffic to pass? h3a name=nwflimitsmigrVM Migration/a/h3 diff --git a/examples/xml/nwfilter/no-ip-spoofing.xml b/examples/xml/nwfilter/no-ip-spoofing.xml index b8c94c8..7c7fd46 100644 --- a/examples/xml/nwfilter/no-ip-spoofing.xml +++ b/examples/xml/nwfilter/no-ip-spoofing.xml @@ -1,5 +1,10 @@ filter name='no-ip-spoofing' chain='ipv4' +!-- allow DHCP requests -- +rule action='accept' direction='out' +ip match='yes' srcipaddr='0.0.0.0' protocol='udp' srcportstart='68' + srcportend='68' / +/rule !-- drop if srcipaddr is not the IP address of the guest -- rule action='drop' direction='out' ip match='no' srcipaddr='$IP' / diff --git a/src/Makefile.am b/src/Makefile.am index 87d91ed..c948cbf 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -481,6 +481,8 @@ NWFILTER_DRIVER_SOURCES = \ nwfilter/nwfilter_driver.h nwfilter/nwfilter_driver.c \ nwfilter/nwfilter_gentech_driver.c \ nwfilter/nwfilter_gentech_driver.h \ + nwfilter/nwfilter_dhcpsnoop.c \ + nwfilter/nwfilter_dhcpsnoop.h \ nwfilter/nwfilter_ebiptables_driver.c \ nwfilter/nwfilter_ebiptables_driver.h \ nwfilter/nwfilter_learnipaddr.c \ diff --git a/src/nwfilter/nwfilter_dhcpsnoop.c b/src/nwfilter/nwfilter_dhcpsnoop.c new file mode 100644 index 000..8a37a6f --- /dev/null +++ b/src/nwfilter/nwfilter_dhcpsnoop.c @@ -0,0 +1,745 @@ +/* + * nwfilter_dhcpsnoop.c: support for DHCP snooping used by a VM + * on an interface + * + * Copyright (C) 2011 IBM Corp. + * Copyright (C) 2011 David L Stevens + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * Author: David L Stevensdlstev...@us.ibm.com + * Based in part on work by Stefan Bergerstef...@us.ibm.com + */ + +#includeconfig.h + +#ifdef HAVE_LIBPCAP
[libvirt] [PATCH] qemu: Copy console definition from serial
Now, when we support multiple consoles per domain,
the vm-def-console[0] can still remain an alias
for vm-def-serial[0]; However, we need to copy
it's source definition as well otherwise we'll regress
on virDomainOpenConsole.
---
src/conf/domain_conf.c | 72 ++
src/conf/domain_conf.h |2 +
src/libvirt_private.syms |1 +
src/qemu/qemu_process.c | 19 +--
4 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 6b78d97..9b2eb86 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -956,6 +956,78 @@ virDomainChrSourceDefClear(virDomainChrSourceDefPtr def)
}
}
+int
+virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
+ virDomainChrSourceDefPtr src)
+{
+if (!dest || !src)
+return -1;
+
+switch (src-type) {
+case VIR_DOMAIN_CHR_TYPE_PTY:
+case VIR_DOMAIN_CHR_TYPE_DEV:
+case VIR_DOMAIN_CHR_TYPE_FILE:
+case VIR_DOMAIN_CHR_TYPE_PIPE:
+if (src-data.file.path
+!(dest-data.file.path = strdup(src-data.file.path))) {
+virReportOOMError();
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CHR_TYPE_UDP:
+if (src-data.udp.bindHost
+!(dest-data.udp.bindHost = strdup(src-data.udp.bindHost))) {
+virReportOOMError();
+return -1;
+}
+
+if (src-data.udp.bindService
+!(dest-data.udp.bindService = strdup(src-data.udp.bindService)))
{
+virReportOOMError();
+return -1;
+}
+
+if (src-data.udp.connectHost
+!(dest-data.udp.connectHost = strdup(src-data.udp.connectHost)))
{
+virReportOOMError();
+return -1;
+}
+
+
+if (src-data.udp.connectService
+!(dest-data.udp.connectService =
strdup(src-data.udp.connectService))) {
+virReportOOMError();
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CHR_TYPE_TCP:
+if (src-data.tcp.host
+!(dest-data.tcp.host = strdup(src-data.tcp.host))) {
+virReportOOMError();
+return -1;
+}
+
+if (src-data.tcp.service
+!(dest-data.tcp.service = strdup(src-data.tcp.service))) {
+virReportOOMError();
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CHR_TYPE_UNIX:
+if (src-data.nix.path
+!(dest-data.nix.path = strdup(src-data.nix.path))) {
+virReportOOMError();
+return -1;
+}
+break;
+}
+
+return 0;
+}
+
void virDomainChrSourceDefFree(virDomainChrSourceDefPtr def)
{
if (!def)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index c360674..76a8dd7 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1662,6 +1662,8 @@ void virDomainNetDefFree(virDomainNetDefPtr def);
void virDomainSmartcardDefFree(virDomainSmartcardDefPtr def);
void virDomainChrDefFree(virDomainChrDefPtr def);
void virDomainChrSourceDefFree(virDomainChrSourceDefPtr def);
+int virDomainChrSourceDefCopy(virDomainChrSourceDefPtr src,
+ virDomainChrSourceDefPtr dest);
void virDomainSoundDefFree(virDomainSoundDefPtr def);
void virDomainMemballoonDefFree(virDomainMemballoonDefPtr def);
void virDomainWatchdogDefFree(virDomainWatchdogDefPtr def);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index b9d537e..e6ccf9d 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -242,6 +242,7 @@ virDomainChrConsoleTargetTypeToString;
virDomainChrDefForeach;
virDomainChrDefFree;
virDomainChrDefNew;
+virDomainChrSourceDefCopy;
virDomainChrSourceDefFree;
virDomainChrSpicevmcTypeFromString;
virDomainChrSpicevmcTypeToString;
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 2882ef8..e0b1824 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -1163,11 +1163,22 @@ qemuProcessFindCharDevicePTYs(virDomainObjPtr vm,
for (i = 0 ; i vm-def-nconsoles ; i++) {
virDomainChrDefPtr chr = vm-def-consoles[i];
-if (chr-source.type == VIR_DOMAIN_CHR_TYPE_PTY
-chr-targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO) {
-if ((ret = qemuProcessExtractTTYPath(output, offset,
- chr-source.data.file.path))
!= 0)
+/* For historical reasons, console[0] can be just an alias
+ * for serial[0]; That's why we need to update it as well */
+if (i == 0 vm-def-nserials
+chr-deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE
+chr-targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL) {
+if ((ret = virDomainChrSourceDefCopy(chr-source,
+
((vm-def-serials[0])-source))) != 0)
Re: [libvirt] [libvirt PATCHv5 2/2] add leasefile support
On 11/10/2011 03:28 PM, David L Stevens wrote:
This patch adds support for saving DHCP snooping leases to an on-disk
file and restoring saved leases that are still active on restart.
Signed-off-by: David L Stevensdlstev...@us.ibm.com
---
src/nwfilter/nwfilter_dhcpsnoop.c | 270 +
1 files changed, 243 insertions(+), 27 deletions(-)
diff --git a/src/nwfilter/nwfilter_dhcpsnoop.c
b/src/nwfilter/nwfilter_dhcpsnoop.c
index 8a37a6f..918ad7b 100644
--- a/src/nwfilter/nwfilter_dhcpsnoop.c
+++ b/src/nwfilter/nwfilter_dhcpsnoop.c
@@ -55,10 +55,18 @@
#include nwfilter_gentech_driver.h
#include nwfilter_ebiptables_driver.h
#include nwfilter_dhcpsnoop.h
+#include virfile.h
+#include configmake.h
#define VIR_FROM_THIS VIR_FROM_NWFILTER
#ifdef HAVE_LIBPCAP
+
+#define LEASEFILE LOCALSTATEDIR /run/libvirt/network/nwfilter.leases
+#define TMPLEASEFILE LOCALSTATEDIR /run/libvirt/network/nwfilter.ltmp
+static int lease_fd = -1;
+static int nleases = 0; /* number of active leases */
+static int wleases = 0; /* number of written leases */
static virHashTablePtr SnoopReqs;
static pthread_mutex_t SnoopLock;
@@ -76,6 +84,7 @@ struct virNWFilterSnoopReq {
const char *filtername;
virNWFilterHashTablePtr vars;
virNWFilterDriverStatePtr driver;
+bool running;
/* start and end of lease list, ordered by lease time */
struct iplease *start;
struct iplease *end;
@@ -96,7 +105,15 @@ struct iplease {
static struct iplease *ipl_getbyip(struct iplease *start, uint32_t ipaddr);
static void ipl_update(struct iplease *pl, uint32_t timeout);
+
+static struct virNWFilterSnoopReq *newreq(const char *ifname);
+static void lease_open(void);
+static void lease_close(void);
+static void lease_load(void);
+static void lease_save(struct iplease *ipl);
+static void lease_restore(struct virNWFilterSnoopReq *req);
+static void lease_refresh(void);
/*
* ipl_ladd - add an IP lease to a list
@@ -187,7 +204,7 @@ ipl_install(struct iplease *ipl)
* ipl_add - create or update an IP lease
*/
static void
-ipl_add(struct iplease *plnew)
+ipl_add(struct iplease *plnew, bool update_leasefile)
{
struct iplease *pl;
struct virNWFilterSnoopReq *req = plnew-ipl_req;
@@ -195,6 +212,8 @@ ipl_add(struct iplease *plnew)
pl = ipl_getbyip(req-start, plnew-ipl_ipaddr);
if (pl) {
ipl_update(pl, plnew-ipl_timeout);
+if (update_leasefile)
+lease_save(pl);
return;
}
/* support for multiple addresses requires the ability to add filters
@@ -212,11 +231,14 @@ ipl_add(struct iplease *plnew)
}
*pl = *plnew;
-if (ipl_install(pl) 0) {
+if (req-running ipl_install(pl) 0) {
VIR_FREE(pl);
return;
}
ipl_tadd(pl);
+nleases++;
+if (update_leasefile)
+lease_save(pl);
}
/*
@@ -252,7 +274,7 @@ ipl_tdel(struct iplease *ipl)
* ipl_del - delete an IP lease
*/
static void
-ipl_del(struct virNWFilterSnoopReq *req, uint32_t ipaddr)
+ipl_del(struct virNWFilterSnoopReq *req, uint32_t ipaddr, bool
update_leasefile)
{
struct iplease *ipl;
@@ -262,13 +284,18 @@ ipl_del(struct virNWFilterSnoopReq *req, uint32_t ipaddr)
ipl_tdel(ipl);
-/* for multiple address support, this needs to remove those rules
- * referencing IP with ipl's ip value.
- */
-if (req-techdriver-applyDHCPOnlyRules(req-ifname, req-macaddr, NULL)) {
-virNWFilterReportError(VIR_ERR_INTERNAL_ERROR, ipl_ldel failed);
+if (update_leasefile) {
+lease_save(ipl);
+
+/*
+ * for multiple address support, this needs to remove those rules
+ * referencing IP with ipl's ip value.
+ */
+if (req-techdriver-applyDHCPOnlyRules(req-ifname,req-macaddr,NULL))
+virNWFilterReportError(VIR_ERR_INTERNAL_ERROR, ipl_ldel failed);
}
VIR_FREE(ipl);
+nleases--;
}
/*
@@ -308,7 +335,7 @@ ipl_trun(struct virNWFilterSnoopReq *req)
now = time(0);
while (req-start req-start-ipl_timeout= now)
-ipl_del(req, req-start-ipl_ipaddr);
+ipl_del(req, req-start-ipl_ipaddr, 1);
return 0;
}
@@ -467,11 +494,11 @@ dhcpdecode(struct virNWFilterSnoopReq *req, struct eth
*pep, int len)
switch (mtype) {
case DHCPACK:
-ipl_add(ipl);
+ipl_add(ipl, 1);
break;
case DHCPDECLINE:
case DHCPRELEASE:
-ipl_del(req, ipl.ipl_ipaddr);
+ipl_del(req, ipl.ipl_ipaddr, 1);
break;
default:
break;
@@ -521,7 +548,7 @@ snoopReqFree(struct virNWFilterSnoopReq *req)
/* free all leases */
snoop_lock();
for (ipl = req-start; ipl; ipl = req-start)
-ipl_del(req, ipl-ipl_ipaddr);
+ipl_del(req, ipl-ipl_ipaddr, 0);
snoop_unlock();
/* free
[libvirt] ANNOUNCE: libvirt-glib release 0.0.1
I am pleased to announce the first release of the libvirt-glib package, version 0.0.1 is now available from ftp://libvirt.org/libvirt/glib/ The packages are GPG signed with Key ID: 15104FDF Daniel P. Berrange berra...@redhat.com Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF libvirt-glib comprises three distinct libraries: - libvirt-glib- Integrate with the GLib event loop and error handling - libvirt-gconfig - Representation of libvirt XML documents as GObjects - libvirt-gobject - Mapping of libvirt APIs into the GObject type system As of this release only the event loop integration and some basic APIs for managing domains are provided. The representation of XML as GObjects is a major work item that is just beginning. The libvirt-gconfig library can be used without linking to the main libvirt.so library, so it is suitable for consumption by applications which use libvirt indirectly via AMQP, CIM or another API transport which accepts XML documents. All the libraries support GObject introspection to enable immediate usage from any language which can dynamically import objects via introspection. There are also Vala bindings which are automatically generated from the introspection data. NB: While libvirt aims to be API/ABI stable, for the first few releases, we are *NOT* guaranteeing that libvirt-glib libraries are API/ABI stable. ABI stability will only be guaranteed once the bulk of the APIs have been fleshed out and proved in non-trivial application usage. We anticipate this will be within the next 6 months in order to line up with Fedora 17. Follow up comments about libvirt-glib should be directed to the regular libvir-list@redhat.com developmenht list. Thanks to all the people involved in contributing to this release. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v5] Add support for systemd init service
From: Daniel P. Berrange berra...@redhat.com This patch adds support for a systemd init service for libvirtd and libvirt-guests. The libvirtd.service is *not* written to use socket activation, since we want libvirtd to start on boot so it can do guest auto-start. The libvirt-guests.service is pretty lame, just exec'ing the original init script for now. Ideally we would factor out the functionality, into some shared tool. Instead of ./configure --with-init-script=redhat You can now do ./configure --with-init-script=systemd Or better still: ./configure --with-init-script=systemd+redhat We can also now support install of the upstart init script In v5: - Actually include the changes to configure.ac I mentioned in v4. * configure.ac: Add systemd, and systemd+redhat options to --with-init-script option * daemon/Makefile.am: Install systemd services * daemon/libvirtd.sysconf: Add note about unused env variable with systemd * daemon/libvirtd.service.in: libvirtd systemd service unit * libvirt.spec.in: Add scripts to installing systemd services and migrating from legacy init scripts * tools/Makefile.am: Install systemd services * tools/libvirt-guests.init.sh: Rename to tools/libvirt-guests.init.in * tools/libvirt-guests.service.in: systemd service unit --- configure.ac| 46 ++ daemon/.gitignore |1 + daemon/Makefile.am | 98 +- daemon/libvirtd.service.in | 20 daemon/libvirtd.sysconf |3 + libvirt.spec.in | 93 +++- po/POTFILES.in |2 +- tools/Makefile.am | 61 +++- tools/libvirt-guests.service.in | 13 + 9 files changed, 288 insertions(+), 49 deletions(-) create mode 100644 daemon/libvirtd.service.in create mode 100644 tools/libvirt-guests.service.in diff --git a/configure.ac b/configure.ac index 3b7535e..58c2740 100644 --- a/configure.ac +++ b/configure.ac @@ -329,16 +329,41 @@ dnl init script flavor dnl AC_MSG_CHECKING([for init script flavor]) AC_ARG_WITH([init-script], -[AC_HELP_STRING([--with-init-script=@:@redhat|auto|none@:@], -[Style of init script to install @:@default=auto@:@])]) -if test x$with_init_script = x || test x$with_init_script = xauto; then -if test $cross_compiling = yes || test ! -f /etc/redhat-release; then -with_init_script=none -else -with_init_script=redhat -fi -fi -AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_RED_HAT], test x$with_init_script = xredhat) +[AC_HELP_STRING([--with-init-script@:@=STYLE@:@], +[Style of init script to install: redhat, systemd, systemd+redhat, + upstart, auto, none @:@default=auto@:@])],[],[with_init_script=check]) +init_redhat=no +init_systemd=no +init_upstart=no +case $with_init_script in +systemd+redhat) + init_redhat=yes + init_systemd=yes + ;; +systemd) + init_systemd=yes + ;; +upstart) + init_upstart=yes + ;; +redhat) + init_redhat=yes + ;; +none) + ;; +check) + if test $cross_compiling != yes test -f /etc/redhat-release; then + init_redhat=yes + with_init_script=redhat + fi + ;; +*) + AC_MSG_ERROR([Unknown initscript flavour $with_init_script]) +;; +esac +AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_RED_HAT], test $init_redhat = yes) +AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_UPSTART], test $init_upstart = yes) +AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_SYSTEMD], test $init_systemd = yes) AC_MSG_RESULT($with_init_script) dnl RHEL-5 has a peculiar version of Xen, which requires some special casing @@ -2680,6 +2705,7 @@ AC_MSG_NOTICE([ Readline: $lv_use_readline]) AC_MSG_NOTICE([ Python: $with_python]) AC_MSG_NOTICE([ DTrace: $with_dtrace]) AC_MSG_NOTICE([ XML Catalog: $XML_CATALOG_FILE]) +AC_MSG_NOTICE([ Init script: $with_init_script]) AC_MSG_NOTICE([]) AC_MSG_NOTICE([Privileges]) AC_MSG_NOTICE([]) diff --git a/daemon/.gitignore b/daemon/.gitignore index ab3d093..2873143 100644 --- a/daemon/.gitignore +++ b/daemon/.gitignore @@ -7,6 +7,7 @@ Makefile.in libvirt_qemud libvirtd libvirtd.init +libvirtd.service libvirtd*.logrotate libvirtd.8 libvirtd.8.in diff --git a/daemon/Makefile.am b/daemon/Makefile.am index 59db217..9ccbb5b 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -174,22 +174,25 @@ policyfile = libvirtd.policy-1 endif endif -install-data-local: install-init install-data-sasl install-data-polkit \ - install-logrotate +install-data-local: install-init-redhat install-init-systemd install-init-upstart \ + install-data-sasl install-data-polkit \ + install-logrotate install-sysctl mkdir -p $(DESTDIR)$(localstatedir)/log/libvirt
[libvirt] RPM spec file patch
Hi
Please accept the following patch to the rpm spec file.
It allows me to enable specific options (like openvz) at the build
comand line, even if they have been disabled by OS feature selection.
eg for an openvz build on centos 6
rpmbuild -bb \
--define 'rhel 6' \
--without dtrace \
--without sanlock \
--without netcf \
--with openvz \
libvirt.spec
Regards
Chris
(Not subscribed to the mailing list)
diff -uNr libvirt-0.9.7.orig/libvirt.spec.in libvirt-0.9.7/libvirt.spec.in
--- libvirt-0.9.7.orig/libvirt.spec.in 2011-11-08 08:52:03.0 +0200
+++ libvirt-0.9.7/libvirt.spec.in 2011-11-16 08:40:15.0 +0200
@@ -232,6 +232,47 @@
%define with_rhel5 0
%endif
+# Force enable specific features if called on the command line
+%{?_with_audit:%define with_audit 1}
+%{?_with_avahi:%define with_avahi 1}
+%{?_with_capng:%define with_capng 1}
+%{?_with_cgconfig:%define with_cgconfig 1}
+%{?_with_dtrace:%define with_dtrace 1}
+%{?_with_esx:%define with_esx 1}
+%{?_with_hal:%define with_hal 1}
+%{?_with_hyperv:%define with_hyperv 1}
+%{?_with_libnl:%define with_libnl 1}
+%{?_with_libpcap:%define with_libpcap 1}
+%{?_with_libvirtd:%define with_libvirtd 1}
+%{?_with_libxl:%define with_libxl 1}
+%{?_with_lxc:%define with_lxc 1}
+%{?_with_macvtap:%define with_macvtap 1}
+%{?_with_netcf:%define with_netcf 1}
+%{?_with_network:%define with_network 1}
+%{?_with_numactl:%define with_numactl 1}
+%{?_with_nwfilter:%define with_nwfilter 1}
+%{?_with_openvz:%define with_openvz 1}
+%{?_with_phyp:%define with_phyp 1}
+%{?_with_polkit:%define with_polkit 1}
+%{?_with_python:%define with_python 1}
+%{?_with_qemu:%define with_qemu 1}
+%{?_with_rhel5:%define with_rhel5 1}
+%{?_with_sanlock:%define with_sanlock 1}
+%{?_with_sasl:%define with_sasl 1}
+%{?_with_selinux:%define with_selinux 1}
+%{?_with_storage_disk:%define with_storage_disk 1}
+%{?_with_storage_fs:%define with_storage_fs 1}
+%{?_with_storage_iscsi:%define with_storage_iscsi 1}
+%{?_with_storage_lvm:%define with_storage_lvm 1}
+%{?_with_storage_mpath:%define with_storage_mpath 1}
+%{?_with_udev:%define with_udev 1}
+%{?_with_uml:%define with_uml 1}
+%{?_with_vbox:%define with_vbox 1}
+%{?_with_vmware:%define with_vmware 1}
+%{?_with_xen:%define with_xen 1}
+%{?_with_xenapi:%define with_xenapi 1}
+%{?_with_yajl:%define with_yajl 1}
+
Summary: Library providing a simple virtualization API
Name: libvirt
Version: @VERSION@
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Copy console definition from serial
I haven't code reviewed it, but it fixes serial console on my system,
so ack to the functionality.
Dave
On Wed, Nov 16, 2011 at 02:14:52PM +0100, Michal Privoznik wrote:
Now, when we support multiple consoles per domain,
the vm-def-console[0] can still remain an alias
for vm-def-serial[0]; However, we need to copy
it's source definition as well otherwise we'll regress
on virDomainOpenConsole.
---
src/conf/domain_conf.c | 72
++
src/conf/domain_conf.h |2 +
src/libvirt_private.syms |1 +
src/qemu/qemu_process.c | 19 +--
4 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 6b78d97..9b2eb86 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -956,6 +956,78 @@ virDomainChrSourceDefClear(virDomainChrSourceDefPtr def)
}
}
+int
+virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
+ virDomainChrSourceDefPtr src)
+{
+if (!dest || !src)
+return -1;
+
+switch (src-type) {
+case VIR_DOMAIN_CHR_TYPE_PTY:
+case VIR_DOMAIN_CHR_TYPE_DEV:
+case VIR_DOMAIN_CHR_TYPE_FILE:
+case VIR_DOMAIN_CHR_TYPE_PIPE:
+if (src-data.file.path
+!(dest-data.file.path = strdup(src-data.file.path))) {
+virReportOOMError();
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CHR_TYPE_UDP:
+if (src-data.udp.bindHost
+!(dest-data.udp.bindHost = strdup(src-data.udp.bindHost))) {
+virReportOOMError();
+return -1;
+}
+
+if (src-data.udp.bindService
+!(dest-data.udp.bindService =
strdup(src-data.udp.bindService))) {
+virReportOOMError();
+return -1;
+}
+
+if (src-data.udp.connectHost
+!(dest-data.udp.connectHost =
strdup(src-data.udp.connectHost))) {
+virReportOOMError();
+return -1;
+}
+
+
+if (src-data.udp.connectService
+!(dest-data.udp.connectService =
strdup(src-data.udp.connectService))) {
+virReportOOMError();
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CHR_TYPE_TCP:
+if (src-data.tcp.host
+!(dest-data.tcp.host = strdup(src-data.tcp.host))) {
+virReportOOMError();
+return -1;
+}
+
+if (src-data.tcp.service
+!(dest-data.tcp.service = strdup(src-data.tcp.service))) {
+virReportOOMError();
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CHR_TYPE_UNIX:
+if (src-data.nix.path
+!(dest-data.nix.path = strdup(src-data.nix.path))) {
+virReportOOMError();
+return -1;
+}
+break;
+}
+
+return 0;
+}
+
void virDomainChrSourceDefFree(virDomainChrSourceDefPtr def)
{
if (!def)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index c360674..76a8dd7 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1662,6 +1662,8 @@ void virDomainNetDefFree(virDomainNetDefPtr def);
void virDomainSmartcardDefFree(virDomainSmartcardDefPtr def);
void virDomainChrDefFree(virDomainChrDefPtr def);
void virDomainChrSourceDefFree(virDomainChrSourceDefPtr def);
+int virDomainChrSourceDefCopy(virDomainChrSourceDefPtr src,
+ virDomainChrSourceDefPtr dest);
void virDomainSoundDefFree(virDomainSoundDefPtr def);
void virDomainMemballoonDefFree(virDomainMemballoonDefPtr def);
void virDomainWatchdogDefFree(virDomainWatchdogDefPtr def);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index b9d537e..e6ccf9d 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -242,6 +242,7 @@ virDomainChrConsoleTargetTypeToString;
virDomainChrDefForeach;
virDomainChrDefFree;
virDomainChrDefNew;
+virDomainChrSourceDefCopy;
virDomainChrSourceDefFree;
virDomainChrSpicevmcTypeFromString;
virDomainChrSpicevmcTypeToString;
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 2882ef8..e0b1824 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -1163,11 +1163,22 @@ qemuProcessFindCharDevicePTYs(virDomainObjPtr vm,
for (i = 0 ; i vm-def-nconsoles ; i++) {
virDomainChrDefPtr chr = vm-def-consoles[i];
-if (chr-source.type == VIR_DOMAIN_CHR_TYPE_PTY
-chr-targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO) {
-if ((ret = qemuProcessExtractTTYPath(output, offset,
-
chr-source.data.file.path)) != 0)
+/* For historical reasons, console[0] can be just an alias
+ * for serial[0]; That's why we need to update it as well */
+if (i == 0 vm-def-nserials
Re: [libvirt] [PATCH v5 4/4] qemu/rbd: improve rbd device specification
On 11/15/2011 06:37 PM, Josh Durgin wrote: The command line that we pass to qemu gets logged. But what happens if the secret was marked as ephemeral - could we be violating the premise of not exposing passwords to too broad an audience? Or are we already safe in that the log entries created by virCommand can only be exposed to users that already can get at the secret information by other means? The secret can be read from the command line of the running process, which is even less secure than the log. I'm working on passing the secret via the qemu monitor instead of the command line, which will avoid both issues. Maybe this means we should we be adding capabilities into virCommand to prevent the logging of the actual secret (whether base64-encoded or otherwise), and instead log an alternate string? That is, should virCommand be tracking parallel argv arrays; the real array passed to exec() but never logged, and the alternate array (normally matching the real one, but which can differ in this particular case of passing an argument that contains a password)? Given your arguments (that ps can read argv of qemu, even if we hid it from libvirt logs, and that we will be moving to a monitor command as soon as qemu supports one), I see no reason to hack up virCommand to support alternate log output. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] bug: try to take disk snapshot for LVM2 Volume
On 11/15/2011 08:20 PM, Dave Allan wrote: After working on this some more, I think that identifying problematic file systems, like devtmpfs, is too tricky to be portable. But I think we can meet halfway - right now, the libvirt code blindly generates a filename if one was not provided, regardless of the file type of the backing file it will be wrapping. But maybe it would be sufficient to make the command error out if no qcow2 filename is provided and the backing file is not a regular file. As in this patch: Ok, now I understand the situation; thanks to everyone for the explanations. I'm somewhat uncomfortable using file type as a proxy for troublesome filesystem since although they are linked in this case, I'm not sure they're linked in all cases. Maybe I'm wrong about that. If there is no portable way to determine whether a particular filesystem is going to be a problem, I would just clearly document the limitations of letting libvirt choose the filename and the importance of not using that functionality on filesystems that cannot hold a useful snapshot. My patch would not be preventing snapshots of block devices, but merely requiring that the user supply the qcow2 filename that will wrap the block device. The problem with just documenting the issue is that someone will fail to read the documentation, perform a default snapshot that creates a problematic qcow2 file, then be upset that their domain fails to boot and that they lost all the changes made since the snapshot. I'm still in favor of this patch if anyone else thinks it is worthwhile. Subject: [PATCH] snapshot: refuse to generate names for non-regular backing files For whatever reason, the kernel allows you to create a regular file named /dev/sdc.12345; although this file will disappear the next time devtmpfs is remounted. If you let libvirt generate the name of the external snapshot for a disk image originally using the block device /dev/sdc, then the domain will be rendered unbootable once the qcow2 file is lost on the next devtmpfs remount. In this case, the user should have used 'virsh snapshot-create --xmlfile' or 'virsh snapshot-create-as --diskspec' to specify the name for the qcow2 file in a sane location, rather than relying on libvirt generating a name that is most likely to be wrong. We can help avoid naive mistakes by enforcing that the user provide the external name for any backing file that is not a regular file. * src/conf/domain_conf.c (virDomainSnapshotAlignDisks): Only generate names if backing file exists as regular file. Reported by MATSUDA Daiki. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix a bug in remoteSerializeTypedParameters
On 11/16/2011 01:38 AM, Hu Tao wrote:
This is a fatal typo believed to be very likely to happen when using
both i and j at the same time for indexing.
Yep, and thanks for catching it.
---
daemon/remote.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 857835e..97c9538 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -710,7 +710,7 @@ remoteSerializeTypedParameters(virTypedParameterPtr
params,
goto cleanup;
}
val[j].value.type = params[i].type;
-switch (params[j].type) {
+switch (params[i].type) {
ACK and pushed.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix build with polkit0
Daniel P. Berrange wrote: On Tue, Nov 15, 2011 at 03:39:28PM -0700, Jim Fehlig wrote: I missed adding libvirt_driver_remote.la to libvirtd_LDADD in commit b8adfcc6, which didn't cause a problem in 0.9.6 but results in this build error in 0.9.7 libvirtd-remote.o: In function `remoteDispatchAuthPolkit': remote.c:(.text+0x188dd): undefined reference to `virNetServerGetDBusConn' --- daemon/Makefile.am |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index e8c47ae..59db217 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -156,6 +156,10 @@ endif if WITH_NWFILTER libvirtd_LDADD += ../src/libvirt_driver_nwfilter.la endif + +if HAVE_POLKIT0 +libvirtd_LDADD += ../src/libvirt_driver_remote.la +endif NACK this is wrong - it is already linked to libvirt.so, which is linked to libvirtd, so tthis results in 2 copies of the code linked. What is missing here is likely the entry for virNetServerGetDBusConn in libvirt_private.syms Opps, I committed it after Eric's ACK. I'll revert and submit a proper fix - after some meetings :(. Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virsh: add iface-bridge and iface-unbridge commands
One of the top questions by libvirt users is how to create a host bridge device so that guests can be directly on the physical network. There are several example documents that explain how to do this manually, but following them often results in confusion and failure. virt-manager does a good job of creating a bridge based on an existing network device, but not everyone wants to use virt-manager. This patch adds a new command, iface-bridge that makes it just about as simple as possible to create a new bridge device based on an existing ethernet/vlan/bond device (including associating IP configuration with the bridge rather than the now-attached device), and start that new bridge up ready for action, eg: virsh iface-bridge eth0 br0 For symmetry's sake, it also adds a command to remove a device from a bridge, restoring the IP config to the now-unattached device: virsh iface-unbridge br0 (I had a short debate about whether to do iface-unbridge eth0 instead, but that would involve searching through all bridge devices for the one that contained eth0, which seems like a bit too much trouble). NOTE: These two commands require that the netcf library be available on the host. Hopefully this will provide some extra incentive for people using suse, debian, ubuntu, and other similar systems to polish up (and push downstream) the ports to those distros recently pushed to the upstream netcf repo by Dan Berrange. Anyone interested in helping with that effort in any way should join the netcf-devel mailing list (subscription info at https://fedorahosted.org/mailman/listinfo/netcf-devel) During creation of the bridge, it's possible to specify whether or not the STP protocol should be started up on the bridge and, if so, how many seconds the bridge should squelch traffic from newly added devices while learning new topology (defaults are stp='on' and delay='0', which seems to usually work best for bridges used in the context of libvirt guests). There is also an option to not immediately start the bridge (and a similar option to not immediately start the un-attached device after dfestroying the bridge. Default is to start the new device, because in the case of iface-unbridge not starting is strongly discouraged as it will leave the system with no network connectivity on that interface (because it's necessary to destroy/undefine the bridge device before the unattached device can be defined), and it seemed better to make the option for iface-bridge behave consistently. Aside from adding the code for these two functions, and the two entries into the command table, the only other change to virsh.c was to add the option name to vshCommandOptInterfaceBy(), because the iface-unbridge command names its interface option as bridge. After being hounded by Eric to always put documentation in with any new code changes, this patch seems a bit naked without some html bits describing it :-), but it looks like docs/virshcmdref.html.in has been deprecated in favor of the version in the separate repo at http://libvirt.org/git/?p=libvirt-virshcmdref.git. --- tools/virsh.c | 430 - 1 files changed, 425 insertions(+), 5 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index af80e4b..ddfd341 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -330,12 +330,14 @@ static virNWFilterPtr vshCommandOptNWFilterBy(vshControl *ctl, const vshCmd *cmd VSH_BYUUID|VSH_BYNAME) static virInterfacePtr vshCommandOptInterfaceBy(vshControl *ctl, const vshCmd *cmd, +const char *optname, + const char **name, int flag); /* default is lookup by Name and MAC */ #define vshCommandOptInterface(_ctl, _cmd, _name)\ -vshCommandOptInterfaceBy(_ctl, _cmd, _name, \ - VSH_BYMAC|VSH_BYNAME) +vshCommandOptInterfaceBy(_ctl, _cmd, NULL, _name,\ + VSH_BYMAC|VSH_BYNAME) static virStoragePoolPtr vshCommandOptPoolBy(vshControl *ctl, const vshCmd *cmd, const char *optname, const char **name, int flag); @@ -6807,7 +6809,7 @@ cmdInterfaceName(vshControl *ctl, const vshCmd *cmd) if (!vshConnectionUsability(ctl, ctl-conn)) return false; -if (!(iface = vshCommandOptInterfaceBy(ctl, cmd, NULL, +if (!(iface = vshCommandOptInterfaceBy(ctl, cmd, NULL, NULL, VSH_BYMAC))) return false; @@ -6837,7 +6839,7 @@ cmdInterfaceMAC(vshControl *ctl, const vshCmd *cmd) if (!vshConnectionUsability(ctl, ctl-conn)) return false; -if (!(iface = vshCommandOptInterfaceBy(ctl, cmd, NULL, +if (!(iface = vshCommandOptInterfaceBy(ctl, cmd, NULL, NULL, VSH_BYNAME))) return false; @@ -7137,6 +7139,417 @@
[libvirt] [PATCH] Bug Fix: Do not release network actual device in qemuBuildCommandLine on error
From: Roopa Prabhu ropra...@cisco.com For direct attach devices, in qemuBuildCommandLine, we seem to be freeing actual device on error path (with networkReleaseActualDevice). But the actual device is not deleted. qemuProcessStop eventually deletes the direct attach device and releases actual device. But by the time qemuProcessStop is called qemuBuildCommandLine has already freed actual device. Leaving stray macvtap devices behind on error. So the simplest fix is to remove the networkReleaseActualDevice in qemuBuildCommandLine. This patch does just that. Does this look right ?. I have only verified this with direct and bridge mode. The other option is to do both delMacvtap and networkReleaseActualDevice in qemuBuildCommandLine instead of doing only networkReleaseActualDevice. I do have a patch for this too. Signed-off-by: Roopa Prabhu ropra...@cisco.com --- src/qemu/qemu_command.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index bb12016..ba33a4a 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5378,8 +5378,6 @@ qemuBuildCommandLine(virConnectPtr conn, virReportOOMError(); error: /* free up any resources in the network driver */ -for (i = 0 ; i def-nnets ; i++) -networkReleaseActualDevice(def-nets[i]); for (i = 0; i = last_good_net; i++) virDomainConfNWFilterTeardown(def-nets[i]); virCommandFree(cmd); -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] Fix build with polkit0
Commit 0f590c62 was not the proper fix for polkit0 build issue. This series reverts 0f590c62 and adds virNetServerGetDBusConn() to libvirt_private.syms Jim Fehlig (2): Revert commit 0f590c62 Fix build with polkit0 daemon/Makefile.am |4 src/libvirt_private.syms |1 + 2 files changed, 1 insertions(+), 4 deletions(-) -- 1.7.7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] Revert commit 0f590c62
As noted by Daniel Berrange [1], the proper fix for the older PolicyKit build issue is to add virNetServerGetDBusConn to libvirt_private.syms. Revert unnecessary changes to daemon/Makefile.am [1] https://www.redhat.com/archives/libvir-list/2011-November/msg00852.html --- daemon/Makefile.am |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index 59db217..e8c47ae 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -156,10 +156,6 @@ endif if WITH_NWFILTER libvirtd_LDADD += ../src/libvirt_driver_nwfilter.la endif - -if HAVE_POLKIT0 -libvirtd_LDADD += ../src/libvirt_driver_remote.la -endif endif libvirtd_LDADD += ../src/libvirt.la -- 1.7.7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] Fix build with polkit0
I missed adding virNetServerGetDBusConn() to libvirtd_private.syms in commit b8adfcc6, which didn't cause a problem in 0.9.6 but results in this build error in 0.9.7 libvirtd-remote.o: In function `remoteDispatchAuthPolkit': remote.c:(.text+0x188dd): undefined reference to `virNetServerGetDBusConn' --- src/libvirt_private.syms |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index b9d537e..4f0b723 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1261,6 +1261,7 @@ virNetServerAddSignalHandler; virNetServerAutoShutdown; virNetServerClose; virNetServerFree; +virNetServerGetDBusConn; virNetServerIsPrivileged; virNetServerNew; virNetServerQuit; -- 1.7.7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: add iface-bridge and iface-unbridge commands
On 11/16/2011 11:04 AM, Laine Stump wrote:
One of the top questions by libvirt users is how to create a host
bridge device so that guests can be directly on the physical
network. There are several example documents that explain how to do
this manually, but following them often results in confusion and
failure. virt-manager does a good job of creating a bridge based on an
existing network device, but not everyone wants to use virt-manager.
This patch adds a new command, iface-bridge that makes it just about
as simple as possible to create a new bridge device based on an
existing ethernet/vlan/bond device (including associating IP
configuration with the bridge rather than the now-attached device),
and start that new bridge up ready for action, eg:
virsh iface-bridge eth0 br0
For symmetry's sake, it also adds a command to remove a device from a
bridge, restoring the IP config to the now-unattached device:
virsh iface-unbridge br0
I like it!
(I had a short debate about whether to do iface-unbridge eth0
instead, but that would involve searching through all bridge devices
for the one that contained eth0, which seems like a bit too much
trouble).
NOTE: These two commands require that the netcf library be available
on the host. Hopefully this will provide some extra incentive for
people using suse, debian, ubuntu, and other similar systems to polish
up (and push downstream) the ports to those distros recently pushed to
the upstream netcf repo by Dan Berrange. Anyone interested in helping
with that effort in any way should join the netcf-devel mailing list
(subscription info at
https://fedorahosted.org/mailman/listinfo/netcf-devel)
Love the advertising plug. Definitely keep it as part of the commit
message.
During creation of the bridge, it's possible to specify whether or not
the STP protocol should be started up on the bridge and, if so, how
many seconds the bridge should squelch traffic from newly added
devices while learning new topology (defaults are stp='on' and
delay='0', which seems to usually work best for bridges used in the
context of libvirt guests).
There is also an option to not immediately start the bridge (and a
similar option to not immediately start the un-attached device after
dfestroying the bridge. Default is to start the new device, because in
s/dfestroying/destroying/
the case of iface-unbridge not starting is strongly discouraged as it
will leave the system with no network connectivity on that interface
(because it's necessary to destroy/undefine the bridge device before
the unattached device can be defined), and it seemed better to make
the option for iface-bridge behave consistently.
Aside from adding the code for these two functions, and the two
entries into the command table, the only other change to virsh.c was
to add the option name to vshCommandOptInterfaceBy(), because the
iface-unbridge command names its interface option as bridge.
After being hounded by Eric to always put documentation in with any
new code changes, this patch seems a bit naked without some html bits
describing it :-), but it looks like docs/virshcmdref.html.in has been
deprecated in favor of the version in the separate repo at
http://libvirt.org/git/?p=libvirt-virshcmdref.git.
Virsh is typically documented first in tools/virsh.pod. You are correct
that the documentation in libvirt-virshcmdref.git (should) be more
detailed, giving example usage and more commentary, but that depends on
virshcmdref being kept up-to-date (I suppose this is my plea for more
help in this area!). But the incompleteness of libvirt-virshcmdref is
no excuse for not at least listing the new commands in virsh.pod (aka
'man virsh').
+++ b/tools/virsh.c
@@ -330,12 +330,14 @@ static virNWFilterPtr
vshCommandOptNWFilterBy(vshControl *ctl, const vshCmd *cmd
VSH_BYUUID|VSH_BYNAME)
static virInterfacePtr vshCommandOptInterfaceBy(vshControl *ctl, const
vshCmd *cmd,
+const char *optname,
+
const char **name, int flag);
Spurious blank line.
+static bool
+cmdInterfaceBridge(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED)
Drop ATTRIBUTE_UNUSED; it's bad copy-and-paste, since you do use cmd.
+/*
+ * iface-unbridge command
+ */
+static const vshCmdInfo info_interface_unbridge[] = {
+{help, N_(undefine a bridge device after detaching its slave
device)},
+{desc, N_(unbridge a network device)},
+{NULL, NULL}
+};
+
+static const vshCmdOptDef opts_interface_unbridge[] = {
+{bridge, VSH_OT_DATA, VSH_OFLAG_REQ, N_(current bridge device name)},
+{no-start, VSH_OT_BOOL, 0, N_(don't start the un-slaved interface
immediately (not recommended))},
Long line; might be worth a line wrap before the N_(...).
@@ -14199,6 +14612,10 @@ static const vshCmdDef nodedevCmds[] = {
static const vshCmdDef
[libvirt] Libvirt block live migration with OpenStack Diablo
Hi all, I use OpenStack Diablo release 2011.3-0ubuntu6.2 on ubuntu 11.10 with libvirt 0.9.2-4ubuntu15.1 I try to block migrate a VM from one host to another one. OpenStack uses the 'migrateToURI' method from libvirt python library. But this call fails. Libvirt log : - Source host: 18:27:30.475: 24622: error : remoteIO:5985 : unable to set user and group to '107:118' on '/var/lib/nova/instances/instance-00b7/console.fifo.in': No such file or directory - Target host: 27:29.737: 27244: error : virSecurityDACSetOwnership:125 : unable to set user and group to '107:118' on '/var/lib/nova/instances/instance-00b7/console.fifo.in': No such file or directory 18:27:29.917: 27244: error : virSecurityDACRestoreSecurityFileLabel:143 : cannot resolve symlink /var/lib/nova/instances/instance-00b7/console.fifo.out: No such file or directory So the migration fails. VM disks are transfered to the target host but console files aren't. XML file of domain: domain type='kvm' nameinstance-00b7/name memory2097152/memory os typehvm/type boot dev=hd / /os features acpi/ /features vcpu2/vcpu devices disk type='file' driver type='qcow2'/ source file='/var/lib/nova/instances/instance-00b7/disk'/ target dev='vda' bus='virtio'/ /disk disk type='file' driver type='qcow2'/ source file='/var/lib/nova/instances/instance-00b7/disk.local'/ target dev='vdb' bus='virtio'/ /disk interface type='bridge' source bridge='br102'/ mac address='02:16:3e:36:c4:70'/ model type='virtio'/ filterref filter=nova-instance-instance-00b7-02163e36c470 parameter name=IP value=172.16.2.3 / parameter name=DHCPSERVER value=172.16.2.1 / /filterref /interface !-- The order is significant here. File must be defined first -- serial type=pipe source path='/var/lib/nova/instances/instance-00b7/console.fifo'/ target port='1'/ /serial console type='pty' tty='/dev/pts/2' source path='/dev/pts/2'/ target port='0'/ /console serial type='pty' source path='/dev/pts/2'/ target port='0'/ /serial graphics type='vnc' port='-1' autoport='yes' keymap='fr' listen='0.0.0.0'/ /devices /domain Could you help me ? Regards, Doude. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Fix build with polkit0
On 11/16/2011 11:46 AM, Jim Fehlig wrote: Commit 0f590c62 was not the proper fix for polkit0 build issue. This series reverts 0f590c62 and adds virNetServerGetDBusConn() to libvirt_private.syms Jim Fehlig (2): Revert commit 0f590c62 Fix build with polkit0 ACK series, and sorry for my premature ACK earlier. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: add iface-bridge and iface-unbridge commands
On 11/16/2011 01:50 PM, Eric Blake wrote: I'll live up to my well-earned reputation :), and request that you don't push this without first squashing in docs (but to soften the blow, here's my first cut at something you can squash in). ACK with above nits fixed and man page docs added. I squashed in your virsh.pod change (plus a couple additions), fixed the nits, and pushed. Thanks! P.S. to anyone who tries these commands - do us both a favor and run virsh iface-begin beforehand, then run virsh iface-commit only after you're sure it's done the right thing (otherwise run virsh iface-rollback or just reboot (I think I've just realized the just reboot part isn't working on F16 due to the conversion to systemd...) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Fix build with polkit0
Eric Blake wrote: On 11/16/2011 11:46 AM, Jim Fehlig wrote: Commit 0f590c62 was not the proper fix for polkit0 build issue. This series reverts 0f590c62 and adds virNetServerGetDBusConn() to libvirt_private.syms Jim Fehlig (2): Revert commit 0f590c62 Fix build with polkit0 ACK series, and sorry for my premature ACK earlier. Thanks, pushed. Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RPM spec file patch
On 11/15/2011 11:42 PM, Chris Picton wrote:
Hi
Please accept the following patch to the rpm spec file.
It allows me to enable specific options (like openvz) at the build
comand line, even if they have been disabled by OS feature selection.
eg for an openvz build on centos 6
rpmbuild -bb \
--define 'rhel 6' \
--without dtrace \
--without sanlock \
--without netcf \
--with openvz \
libvirt.spec
Regards
Thanks for the report. However, I'm not yet quite convinced that your
proposed patch is the best approach. I'll explain, focusing on just the
nwfilter macros as an example.
First, some background, to make sure I'm analyzing things correctly (and
in part, documenting things I learned so that I can refer to this mail
later :).
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-single/RPM_Guide/index.html#id570231
was handy in seeing how spec file macros are expanded. I temporarily
added this line to libvirt.spec, then ran variations of 'rpmbuild -bp
libvirt.spec' to see what effect things have:
%{error: with %{_with_nwfilter}, without %{_without_nwfilter}}
It was pretty easy to learn that:
rpmbuild --without a --with b
is short-hand for
rpmbuild --define '_without_a --without-a1' --define '_with_b --with-b'
Note that these are macros with a leading underscore, and that the
definition chosen happens to be one that can be reused as a typical
./configure argument. But we later want to make decisions on
dependencies based on which commands were enabled via rpmbuild or
earlier %define, and checking both _without_nwfilter and _with_nwfilter
at every decision point is tedious, so we create a new macro,
with_nwfilter, whose contents are guaranteed to be a numeric string that
is usable as an %if expression (the value of the string is important
only as 0 vs. non-zero).
Now, notice that the existing spec file starts with:
%define with_nwfilter 0%{!?_without_nwfilter:0}
which guarantees with_nwfilter will be defined, either to 0 (if
_without_nwfilter is defined) or 00 (if _without_nwfilter was not
defined). At first glance, that seems a bit fishy - shouldn't we be
defining it to 0 or 1, instead of 0 or 0? But reading the comment makes
it clearer (this is setting a default to off, which is enabled later
based on other conditions); and indeed, the next use is:
%if %{with_qemu}
%define with_nwfilter 0%{!?_without_nwfilter:%{server_drivers}}
%endif
Aha. If %{with_qemu} is set, then we redefine with_nwfilter; this time
to the value 0 if _without_nwfilter is set, or to 0%{server_drivers}
(which in turn is 00 or 01) if _without_nwfilter is missing. If
%{with_qemu} is clear, then we leave with_nwfilter at 0.
After that point, your patch would then add:
%{?_with_nwfilter:%define with_nwfilter 1}
which says that if _with_nwfilter is defined, then redefine
with_nwfilter once more, this time to 1.
Still, that's a lot of logic to go through three %defines before we get
to the final value. Also, it looks like our spec file does not make it
easy to override client_only, which controls several of the defaults (of
course, it is okay to hardcode client_only to 1 on the architectures
where we do not support libvirtd, but allowing the user to override it
to 0 on platforms where we normally build the server would be handy).
Perhaps it would be simpler to do something like this, which 1) fixes
client_only to allow user override on appropriate platforms, and 2) sets
default values based on inspecting _both_ with and without variants.
This is not a complete patch, so much as a request for further
discussion. The idea is to demonstrate how defining the defaults for
with_libvirtd and with_polkit should consider the _with_ variant in
addition to the _without_ variant; again with the end result being 0 to
disable, nonzero (whether 010, 011, or 001) to enable.
Thoughts?
diff --git i/libvirt.spec.in w/libvirt.spec.in
index 89f710c..d085feb 100644
--- i/libvirt.spec.in
+++ w/libvirt.spec.in
@@ -11,7 +11,7 @@
# A client only build will create a libvirt.so only containing
# the generic RPC driver, and test driver and no libvirtd
# Default to a full server + client build
-%define client_only0
+%{!?client_only:%define client_only0}
# Now turn off server build in certain cases
@@ -34,7 +34,7 @@
# of any particular OS
# First the daemon itself
-%define with_libvirtd 0%{!?_without_libvirtd:%{server_drivers}}
+%define with_libvirtd
0%{!?_without_libvirtd:%{server_drivers}%{?_with_libvirtd:1}}
%define with_avahi 0%{!?_without_avahi:%{server_drivers}}
# Then the hypervisor drivers that run on local host
@@ -64,7 +64,7 @@
%define with_selinux 0%{!?_without_selinux:%{server_drivers}}
# A few optional bits off by default, we enable later
-%define with_polkit0%{!?_without_polkit:0}
+%define with_polkit0%{!?_without_polkit:0}%{?_with_polkit:1}
%define with_capng 0%{!?_without_capng:0}
%define with_netcf
Re: [libvirt] [PATCH] Add support for systemd init service
On 11/16/2011 05:01 AM, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com This patch adds support for a systemd init service for libvirtd and libvirt-guests. The libvirtd.service is *not* written to use socket activation, since we want libvirtd to start on boot so it can do guest auto-start. The libvirt-guests.service is pretty lame, just exec'ing the original init script for now. Ideally we would factor out the functionality, into some shared tool. Instead of ./configure --with-init-script=redhat You can now do ./configure --with-init-script=systemd Or better still: ./configure --with-init-script=systemd+redhat We can also now support install of the upstart init script In v4: - Print chosen init script type in configure.ac summary - Support upstart install - Error from configure on unsupported requests - Remove bogus dep from policykit install to redhat init -AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_RED_HAT], test x$with_init_script = xredhat) +[AC_HELP_STRING([--with-init-script@:@=STYLE@:@], +[Style of init script to install: redhat, systemd, systemd+redhat, + upstart, auto, none @:@default=auto@:@])]) +init_redhat=no +init_systemd=no +case $with_init_script in +systemd+redhat) + init_redhat=yes + init_systemd=yes + ;; +systemd) + init_systemd=yes + ;; +redhat) + init_redhat=yes + ;; +none) + ;; +*) + if test $cross_compiling != yes test -f /etc/redhat-release; then + init_redhat=yes + with_init_script=redhat Umm, this still has the same problem as v3; with_init_script of upstart is converted to redhat. Did you forget to commit your changes? + fi + ;; +esac +AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_RED_HAT], test $init_redhat = yes) +AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_SYSTEMD], test $init_systemd = yes) AC_MSG_RESULT($with_init_script) Also, there's a missing AM_CONDITIONAL([LIBVIRT_INIT_SCRIPT_UPSTART],...) + +if LIBVIRT_INIT_SCRIPT_UPSTART although this expects it to exist. Everything else looks good, so I'm assuming that the problems in configure.ac were due to forgetting 'git add' before 'git commit --amend'. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v5] Add support for systemd init service
On 11/16/2011 07:20 AM, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com This patch adds support for a systemd init service for libvirtd and libvirt-guests. The libvirtd.service is *not* written to use socket activation, since we want libvirtd to start on boot so it can do guest auto-start. The libvirt-guests.service is pretty lame, just exec'ing the original init script for now. Ideally we would factor out the functionality, into some shared tool. Instead of ./configure --with-init-script=redhat You can now do ./configure --with-init-script=systemd Or better still: ./configure --with-init-script=systemd+redhat We can also now support install of the upstart init script In v5: - Actually include the changes to configure.ac I mentioned in v4. Oops - serves me right for reading my inbox in order :) ACK. (Phew!) -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Copy console definition from serial
On 11/16/2011 06:14 AM, Michal Privoznik wrote:
Now, when we support multiple consoles per domain,
the vm-def-console[0] can still remain an alias
for vm-def-serial[0]; However, we need to copy
it's source definition as well otherwise we'll regress
on virDomainOpenConsole.
---
src/conf/domain_conf.c | 72
++
src/conf/domain_conf.h |2 +
src/libvirt_private.syms |1 +
src/qemu/qemu_process.c | 19 +--
4 files changed, 90 insertions(+), 4 deletions(-)
I do agree that we need the deep copy - when we first connect to qemu,
we do a lookup to see what ptys got allocated, and modify vm-def
accordingly. If vm-def-serials[0] is modified by the pty lookup, and
vm-def-consoles[0] is an alias to serials[0], then the allocations
that were done to modify the serials lookup have to be cloned to
vm-def-consoles[0].
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 6b78d97..9b2eb86 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -956,6 +956,78 @@ virDomainChrSourceDefClear(virDomainChrSourceDefPtr def)
}
}
+int
+virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
+ virDomainChrSourceDefPtr src)
+{
+if (!dest || !src)
+return -1;
+
+switch (src-type) {
+case VIR_DOMAIN_CHR_TYPE_PTY:
+case VIR_DOMAIN_CHR_TYPE_DEV:
+case VIR_DOMAIN_CHR_TYPE_FILE:
+case VIR_DOMAIN_CHR_TYPE_PIPE:
+if (src-data.file.path
+!(dest-data.file.path = strdup(src-data.file.path))) {
+virReportOOMError();
+return -1;
+}
+break;
+
+case VIR_DOMAIN_CHR_TYPE_UDP:
+if (src-data.udp.bindHost
+!(dest-data.udp.bindHost = strdup(src-data.udp.bindHost))) {
+virReportOOMError();
+return -1;
+}
Hmm. If this strdup() succeeds,
+
+if (src-data.udp.bindService
+!(dest-data.udp.bindService =
strdup(src-data.udp.bindService))) {
+virReportOOMError();
+return -1;
+}
but this fails, then the burden is on the caller to free up dest on
error in order to avoid a memory leak. But...
+++ b/src/qemu/qemu_process.c
@@ -1163,11 +1163,22 @@ qemuProcessFindCharDevicePTYs(virDomainObjPtr vm,
for (i = 0 ; i vm-def-nconsoles ; i++) {
virDomainChrDefPtr chr = vm-def-consoles[i];
-if (chr-source.type == VIR_DOMAIN_CHR_TYPE_PTY
-chr-targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO) {
-if ((ret = qemuProcessExtractTTYPath(output, offset,
-
chr-source.data.file.path)) != 0)
+/* For historical reasons, console[0] can be just an alias
+ * for serial[0]; That's why we need to update it as well */
+if (i == 0 vm-def-nserials
+chr-deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE
+chr-targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL) {
+if ((ret = virDomainChrSourceDefCopy(chr-source,
+
((vm-def-serials[0])-source))) != 0)
return ret;
at first glance, the lone caller doesn't directly free dest. On the
other hand, the lone caller passed in dest of vm-def-consoles[0],
which eventually gets cleaned up when vm-def is freed, so you've
escaped the original leak that I was worried might exist. However, if
qemuProcessFindCharDevicePTYs ever gets called multiple times on the
same vm-def, then the second call overwrites the pointer from the first
call, and you have a memory leak in that aspect; and since it is
cross-file between allocation and error path, it's hard to chase down.
ACK if you squash this in to avoid the memory leak (you may want to wait
for Dave to confirm that squashing this in still works in his testing):
diff --git i/src/conf/domain_conf.c w/src/conf/domain_conf.c
index 9b2eb86..e6f97b8 100644
--- i/src/conf/domain_conf.c
+++ w/src/conf/domain_conf.c
@@ -956,6 +956,8 @@ virDomainChrSourceDefClear(virDomainChrSourceDefPtr def)
}
}
+/* Deep copies the contents of src into dest. Return -1 and report
+ * error on failure. */
int
virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
virDomainChrSourceDefPtr src)
@@ -963,6 +965,8 @@ virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest,
if (!dest || !src)
return -1;
+virDomainChrSourceDefClear(dest);
+
switch (src-type) {
case VIR_DOMAIN_CHR_TYPE_PTY:
case VIR_DOMAIN_CHR_TYPE_DEV:
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v5] Add support for systemd init service
On 11/16/2011 09:20 AM, Daniel P. Berrange wrote: From: Daniel P. Berrangeberra...@redhat.com This patch adds support for a systemd init service for libvirtd and libvirt-guests. The libvirtd.service is *not* written to use socket activation, since we want libvirtd to start on boot so it can do guest auto-start. Dang! I guess I have to do this for the transaction rollback initscript in netcf. Any advice / pointers to docs other than read my patch and do what I did?? :-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V4 01/10] Extend virHashTable with function to get hash tables keys
On 10/26/2011 05:36 AM, Stefan Berger wrote:
Add a function to the virHashTable for getting an array of the hash table's
keys and have the keys (optionally) sorted.
Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
src/libvirt_private.syms |3 +
src/util/hash.c | 98
+++
src/util/hash.h | 14 ++
3 files changed, 115 insertions(+)
Reordering for review purposes:
Index: libvirt-acl/src/util/hash.h
===
--- libvirt-acl.orig/src/util/hash.h
+++ libvirt-acl/src/util/hash.h
@@ -130,6 +130,20 @@ void *virHashLookup(virHashTablePtr tabl
*/
void *virHashSteal(virHashTablePtr table, const void *name);
+/*
+ * Get the set of keys and have them optionally sorted.
+ */
+typedef struct _virHashKeyValuePair virHashKeyValuePair;
+typedef virHashKeyValuePair *virHashKeyValuePairPtr;
+struct _virHashKeyValuePair {
+void *key;
Why isn't this 'const void *key'?
+const void *value;
+};
+typedef int (*virHashKeyComparator)(const virHashKeyValuePairPtr ,
+const virHashKeyValuePairPtr );
+void **virHashGetKeys(virHashTablePtr table, virHashKeyComparator
compar);
So the caller only knows how large the returned array is by calling
virHashSize? I take it passing NULL for compar is what gets the keys in
an unsorted order.
Should this return 'const void **', that is, an array that can be
modified, but whose elements are const void * pointers into the hash
table, where the keys are not modifiable through this array view?
+void virHashFreeKeys(virHashTablePtr table, void **);
I'm not sure we need this. It seems like the array returned by
virHashGetKeys should be able to just pass directly to VIR_FREE, without
reference to which table it was copied from, since all the elements of
the array are just pointers into the hash table. I guess I could see
using this if you are cloning keys in the process of creating the array,
but I'm not sure that cloning keys is worth it.
* Iterators
Index: libvirt-acl/src/libvirt_private.syms
===
--- libvirt-acl.orig/src/libvirt_private.syms
+++ libvirt-acl/src/libvirt_private.syms
@@ -559,6 +559,8 @@ virHashAddEntry;
virHashCreate;
virHashForEach;
virHashFree;
+virHashFreeKeys;
This line might not be needed, per my above questioning.
+virHashGetKeys;
virHashLookup;
virHashRemoveEntry;
virHashRemoveSet;
@@ -566,6 +568,7 @@ virHashSearch;
virHashSize;
virHashSteal;
virHashTableSize;
+virHashUpdateEntry;
Did we really have this one missing?
+++ libvirt-acl/src/util/hash.c
@@ -618,3 +618,101 @@ void *virHashSearch(virHashTablePtr tabl
return NULL;
}
+
+
+struct getKeysIter
+{
+virHashTablePtr table;
+void **array;
+virHashKeyValuePair *sortArray;
+unsigned arrayIdx;
+bool error;
If you go with my idea of VIR_FREE() to clean up the returned array,
then you don't need bool error.
+};
+
+static void virHashGetKeysIterator(void *payload,
+ const void *name, void *data)
+{
+struct getKeysIter *iter = data;
+void *key;
+
+if (iter-error)
+return;
+
+key = iter-table-keyCopy(name);
+
+if (key == NULL) {
+virReportOOMError();
+iter-error = true;
+return;
+}
These statements disappear, replaced by:
key = name;
(const-correcness may require that you use const void * in more places).
+
+if (iter-sortArray) {
+iter-sortArray[iter-arrayIdx].key = key;
+iter-sortArray[iter-arrayIdx].value = payload;
+} else {
+iter-array[iter-arrayIdx] = iter-table-keyCopy(name);
and this becomes iter-array[iter-arrayIdx] = key;
+}
+iter-arrayIdx++;
+}
+
+void virHashFreeKeys(virHashTablePtr table, void **keys)
+{
+unsigned i = 0;
+
+if (keys == NULL)
+return;
+
+while (keys[i])
+table-keyFree(keys[i++]);
+
+VIR_FREE(keys);
+}
then this function disappears.
+
+typedef int (*qsort_comp)(const void *, const void *);
+
+void **virHashGetKeys(virHashTablePtr table,
+ virHashKeyComparator compar)
This function needs better documentation; compare to virHashForEach to
see an example. Mention that the returned array must be passed to VIR_FREE
+{
+int i, numElems = virHashSize(table);
+struct getKeysIter iter = {
+.table = table,
+.arrayIdx = 0,
+.error = false,
You need to explicitly initialize .sortArray to NULL, otherwise,
virHashGetKeysIterator will see it as uninitialized garbage, and may
attempt to store into .sortArray instead of the intended .array.
+};
+
+if (numElems 0) {
+return NULL;
+}
+
+if (VIR_ALLOC_N(iter.array, numElems + 1)) {
+
Re: [libvirt] [PATCH V4 02/10] Introduce an internal priority for chains
On 10/26/2011 05:36 AM, Stefan Berger wrote: For better handling of the sorting of chains introduce an internally used priority. Use a lookup table to store the priorities. For now their actual values do not matter just that the values cause the chains to be properly sorted through changes in the following patches. However, the values are chosen as negative so that once they are sorted along with filtering rules (whose priority may only be positive for now) they will always be instantiated before them (lower values cause instantiation before higher values). This is done to maintain backwards compatibility. v3: - increased filter priorities to have more room before them Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com --- src/conf/nwfilter_conf.c | 14 ++ src/conf/nwfilter_conf.h | 12 src/nwfilter/nwfilter_ebiptables_driver.c |4 src/nwfilter/nwfilter_ebiptables_driver.h |1 + 4 files changed, 31 insertions(+) ACK. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V4 03/10] Make filter creation in root table more flexible
On 10/26/2011 05:36 AM, Stefan Berger wrote:
Use the previously introduced chain priorities to sort the chains for access
from an interface's 'root' table and have them created in the proper order.
This gets rid of a lot of code that was previously creating the chains in a
more hardcoded way.
To determine what protocol a filter is used for evaluation do prefix-
matching, i.e., the filter 'arp' is used to filter for the 'arp' protocol,
'ipv4' for the 'ipv4' protocol and 'arp-xyz' will also be used to filter
for the 'arp' protocol following the prefix 'arp' in its name.
Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com
---
src/nwfilter/nwfilter_ebiptables_driver.c | 130
++
1 file changed, 98 insertions(+), 32 deletions(-)
+static int
+ebiptablesFilterOrderSort(const virHashKeyValuePairPtr a,
+ const virHashKeyValuePairPtr b)
+{
+return *(virNWFilterChainPriority *)a-value -
+ *(virNWFilterChainPriority *)b-value;
+}
I tend to worry about someone passing INT_MAX and INT_MIN to a qsort
algorithm, then getting the wrong comparison sense because of integer
overflow when it uses straight subtraction; so I like to add a comment
explaining why I know that the valid input was capped and overflow is
impossible.
static void
iptablesCheckBridgeNFCallEnabled(bool isIPv6)
@@ -3327,6 +3336,56 @@ iptablesCheckBridgeNFCallEnabled(bool is
}
}
+/*
+ * Given a filtername determine the protocol it is used for evaluating
+ * We do prefix-matching to determine the protocol.
+ */
+static enum l3_proto_idx
+ebtablesGetProtoIdxByFiltername(const char *filtername)
+{
+enum l3_proto_idx idx;
+
+for (idx = 0; idx L3_PROTO_LAST_IDX; idx++) {
+if (STRPREFIX(filtername, l3_protocols[idx].val)) {
+return idx;
+}
+}
This works as long as none of the entries in l3_protocols are a prefix
of any other entry; is it worth a comment at the declaration of
l3_protocols warning about this assumption for when new protocol names
are added to the table?
+
+return -1;
+}
+
+static int
+ebtablesCreateTmpRootAndSubChains(virBufferPtr buf,
+ const char *ifname,
+ virHashTablePtr chains, int direction)
+{
+int rc = 0, i;
+
+if (virHashSize(chains) != 0) {
+char **filter_names;
+
+ebtablesCreateTmpRootChain(buf, direction, ifname, 1);
+filter_names = (char **)virHashGetKeys(chains,
+ ebiptablesFilterOrderSort);
This area of code will be impacted by my comments on 1/10.
+if (filter_names == NULL) {
+virReportOOMError();
Your implementation of virHashGetKeys already reported OOM error for all
error paths except for numElems 0; but that means that this call to
virReportOOMError() is either redundant (a second report), or misleading
(if numElems 0, you are not OOM, but have a programming bug on hand
for passing in an invalid hash table in the first place).
+rc = 1;
Can we get this updated to use -1 for failures, so that there's less to
clean up later when we fix this file to match libvirt conventions?
+goto err_exit;
+}
+for (i = 0; filter_names[i]; i++) {
+enum l3_proto_idx idx = ebtablesGetProtoIdxByFiltername(
+ filter_names[i]);
+if ((int)idx 0)
+continue;
+ebtablesCreateTmpSubChain(buf, direction, ifname, idx,
+ filter_names[i], 1);
+}
+virHashFreeKeys(chains, (void **)filter_names);
Oh, this reminds me of some additional feedback I meant to give on 1/10
- as part of the documentation you add, be sure to mention that the
returned array is only valid as long as the underlying hash table is not
modified (especially if you alter things to return in-hash pointers
rather than cloning keys) - adding or removing elements, or deleting the
hash table, will invalidate the returned key array.
@@ -3337,24 +3396,43 @@ ebiptablesApplyNewRules(virConnectPtr co
int i;
int cli_status;
ebiptablesRuleInstPtr *inst = (ebiptablesRuleInstPtr *)_inst;
-int chains_in = 0, chains_out = 0;
virBuffer buf = VIR_BUFFER_INITIALIZER;
+virHashTablePtr chains_in_set = virHashCreate(10, NULL),
+chains_out_set = virHashCreate(10, NULL);
Style-wise, I would list this as two declarations separated by ';',
rather than one declaration of two variables separated by ','. That is,
I find it slightly hard to read stacked declarations that involve
multi-argument function calls as the initializers.
If patch 1/10 were used as-is, then this patch looks good except for a
few easy-to-fix nits. But more likely, this will also need a v5 due to
rebasing on top of changes to how
Re: [libvirt] [PATCH V4 01/10] Extend virHashTable with function to get hash tables keys
On 11/16/2011 07:32 PM, Eric Blake wrote:
On 10/26/2011 05:36 AM, Stefan Berger wrote:
Add a function to the virHashTable for getting an array of the hash table's
keys and have the keys (optionally) sorted.
Signed-off-by: Stefan Bergerstef...@linux.vnet.ibm.com
---
src/libvirt_private.syms |3 +
src/util/hash.c | 98
+++
src/util/hash.h | 14 ++
3 files changed, 115 insertions(+)
Reordering for review purposes:
Index: libvirt-acl/src/util/hash.h
===
--- libvirt-acl.orig/src/util/hash.h
+++ libvirt-acl/src/util/hash.h
@@ -130,6 +130,20 @@ void *virHashLookup(virHashTablePtr tabl
*/
void *virHashSteal(virHashTablePtr table, const void *name);
+/*
+ * Get the set of keys and have them optionally sorted.
+ */
+typedef struct _virHashKeyValuePair virHashKeyValuePair;
+typedef virHashKeyValuePair *virHashKeyValuePairPtr;
+struct _virHashKeyValuePair {
+void *key;
Why isn't this 'const void *key'?
My bad.
I converted everything. It now looks like this.
*
* Get the set of keys and have them optionally sorted.
*/
typedef struct _virHashKeyValuePair virHashKeyValuePair;
typedef virHashKeyValuePair *virHashKeyValuePairPtr;
struct _virHashKeyValuePair {
const void *key;
const void *value;
};
typedef int (*virHashKeyComparator)(const virHashKeyValuePairPtr ,
const virHashKeyValuePairPtr );
virHashKeyValuePairPtr virHashGetItems(virHashTablePtr table,
virHashKeyComparator compar);
I hope this addresses your concerns. I do need the sorting and left it
in there without
wanting to either wrap it or offload it into the caller - if that's ok.
Stefan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RPM spec file patch
On Wed, 2011-11-16 at 15:31 -0700, Eric Blake wrote:
On 11/15/2011 11:42 PM, Chris Picton wrote:
Hi
Please accept the following patch to the rpm spec file.
Thanks for the report. However, I'm not yet quite convinced that your
proposed patch is the best approach. I'll explain, focusing on just the
nwfilter macros as an example.
[snip]
Perhaps it would be simpler to do something like this, which 1) fixes
client_only to allow user override on appropriate platforms, and 2) sets
default values based on inspecting _both_ with and without variants.
This is not a complete patch, so much as a request for further
discussion. The idea is to demonstrate how defining the defaults for
with_libvirtd and with_polkit should consider the _with_ variant in
addition to the _without_ variant; again with the end result being 0 to
disable, nonzero (whether 010, 011, or 001) to enable.
In my case, I was trying to override the behaviour of the spec file
which is to (in the case of with_openvz)
1) set sane defaults for variables near the top
%define with_openvz0%{!?_without_openvz:%{server_drivers}}
2) override these with platform specific values later on
%if 0%{?rhel}
%define with_openvz 0
...
%endif
3) use the overridden values. ignoring the user-supplied options
In your patch, it still does not change the above behaviour, as the
defaults are set near the top, but still force overridden further down
The following may be a better way of expressing the dependencies
1) set sane defaults for variables near the top
%define with_openvz0%{!?_without_openvz:%{server_drivers}}
2) override these with platform specific values later on (but taking
cognisance of the user supplied options
%if 0%{?rhel}
%define with_openvz 0%{?_with_openvz:1}
...
%endif
This is already used in some cases where certain features are turned on
on specific platforms:
%if 0%{?fedora} = 13 || 0%{?rhel} = 6
%define with_dtrace 0%{!?_without_dtrace:1}
%endif
So the bulk of the changes would be updating the spec file to replace
%define with_xxx 0
with
%define with_xxx 0{?_with_xxx:1}
And then also updating for the client_only settings as shown below as
well
Regards
Chris
diff --git i/libvirt.spec.in w/libvirt.spec.in
index 89f710c..d085feb 100644
--- i/libvirt.spec.in
+++ w/libvirt.spec.in
@@ -11,7 +11,7 @@
# A client only build will create a libvirt.so only containing
# the generic RPC driver, and test driver and no libvirtd
# Default to a full server + client build
-%define client_only0
+%{!?client_only:%define client_only0}
# Now turn off server build in certain cases
@@ -34,7 +34,7 @@
# of any particular OS
# First the daemon itself
-%define with_libvirtd 0%{!?_without_libvirtd:%{server_drivers}}
+%define with_libvirtd
0%{!?_without_libvirtd:%{server_drivers}%{?_with_libvirtd:1}}
%define with_avahi 0%{!?_without_avahi:%{server_drivers}}
# Then the hypervisor drivers that run on local host
@@ -64,7 +64,7 @@
%define with_selinux 0%{!?_without_selinux:%{server_drivers}}
# A few optional bits off by default, we enable later
-%define with_polkit0%{!?_without_polkit:0}
+%define with_polkit0%{!?_without_polkit:0}%{?_with_polkit:1}
%define with_capng 0%{!?_without_capng:0}
%define with_netcf 0%{!?_without_netcf:0}
%define with_udev 0%{!?_without_udev:0}
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] New feature for libvirt
Hi, I wanted to suggest a new feature development in libvirt network filter. Currently in libvirt network filter there is no support for ip aliasing, but we want to add this feature so that libvirt learns multiple ip address for a virtual machine. With this feature we will be able to get no-ip-spoofing filter works on machine with ip aliasing. Currently if we apply no-ip-spoofing filter on a virtual machine with ip aliasing then only one ip address is earned by libvirt ,due to this other aliased ip address packets are not allowed to route out of the machine. With this new feature libvirt network filter will work on machine with multiple ip addresses on a interface(ip aliasing) Regards Amit Tewari DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . - libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
