Re: [libvirt] [virt-tools-list] [Spice-devel] More on virt-viewer for windows
by Eric Blake
[adding libvir-list, for some cross-compiling development hints]
On 09/17/2013 11:57 AM, Fernando Lozano wrote:
> Yes, the libvirt comes grom 0.10.2. I'm running the latest windows
> binaries provided by spice-space.org:
>
> C:\Program Files\VirtViewer\bin>virsh -V
> Virsh command line tool of libvirt 0.10.2
Can someone from the Spice community chime in? Why is spice-space.org
shipping a Fedora 18 build of libvirt (0.10.2.x) rather than Fedora 19
(1.0.5.x)? Who does the builds, and how often are they updated?
>> Process Monitor is only useful if you make system calls; but libvirt is
>> choking even before attempting the system calls because mingw is just
>> such a hostile programming environment to programs that assume POSIX.
>
> That's precisely mingw advantage over cigwin: mingw binaries are native
> windows binaries, using native windows semantics, not unix emulation.
> They provide a better experience for windows users. Welcome to the
> wonderful world of cross-platform developent! ;-)
Actually, on my personal to-do list is to get a build of virsh working
and available from cygwin.com, rather than requiring people to
self-build it for cygwin. And since cygwin supports cross-compilation
to mingw, just as Fedora does, but with the added advantage of also
being able to run mingw binaries without having to worry about bugs in
the wine emulation layer, it's actually a bit nicer for getting the best
of both worlds when doing cross-compiling (posix development, native
testing). If I can ever find the free time...
>
>
>> Gnulib has helped a lot, and often times, it is just a matter of someone
>> running under gdb to see where an assumption went wrong to make a quick
>> patch to fix an issue. Where it gets tricky is that it is hard to find
>> developers willing to do volunteer work on issues for a platform where
>> you typically have to pay money before you can even use it. Also, the
>> fact that you are using a pre-built version of a relatively old libvirt,
>> instead of building your own from the latest sources, makes it hard to
>> know what OTHER issues may have been fixed in the meantime (when given a
>> choice, developers prefer to debug issues in the latest source, rather
>> than trying to figure out which patches to backport to older branches).
> I understand that, but I'm trying to be useful as a (windows) tester. If
> I could I'd try to help as a developer. cross-compiling is not for the
> faint of heart, and learning the first steps require a significant
> investment in time. :-(
>
> Is there a how-to I can follow to generate binaries from the latest
> sources? I do have Linux expertize, I use fedora on my personal
> computer, but as C developer I can only run "configure; make; sudo make
> install".
All I've done so far is test cross-compilation from Fedora to mingw (I
haven't tested the resulting binaries, only that the build completes
without error). I suppose I could try to host the just-built binaries
on a site for you to download; let me see what I can figure out.
Meanwhile, I used './autobuild.sh' as my guide; which means I more or
less did:
$ sudo yum install \
mingw64-binutils \
mingw64-cpp \
mingw64-crt \
mingw64-curl \
mingw64-dbus \
mingw64-filesystem \
mingw64-gcc \
mingw64-gcc-c++ \
mingw64-gettext \
mingw64-gmp \
mingw64-gnutls \
mingw64-headers \
mingw64-libgcrypt \
mingw64-libgpg-error \
mingw64-libidn \
mingw64-libssh2 \
mingw64-libtasn1 \
mingw64-libxml2 \
mingw64-nettle \
mingw64-openssl \
mingw64-p11-kit \
mingw64-pkg-config \
mingw64-portablexdr \
mingw64-termcap \
mingw64-wine-gecko \
mingw64-win-iconv \
mingw64-zlib
$ git clone git://libvirt.org/libvirt.git
$ cd libvirt
$ ./autogen.sh --help # see note [1]
$ mkdir build-mingw
$ cd build-mingw
$ ../configure \
PKG_CONFIG_LIBDIR="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig"
\
PKG_CONFIG_PATH="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig"
\
CC="x86_64-w64-mingw32-gcc" \
--build=$(uname -m)-w64-linux \
--host=x86_64-w64-mingw32 \
--prefix="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw" \
--without-libvirtd \
--without-python
$ make
[1] Yeah, we probably ought to have a more convenient way to bootstrap
libvirt.git for VPATH builds without having to rely on the hack that
options unrecognized by ./autogen.sh are passed on to ./configure, and
that ./configure --help is the easiest way to do avoid polluting the
top-level tree in a way that would interfere with VPATH builds. I use a
VPATH build for my mingw cross-compilation in part so I can test both
32-bit and 64-bit binaries in parallel directories.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
11 years, 2 months
[libvirt] [v0.9.12-maint 0/5] building 0.9.12 on newer systems
by Eric Blake
I'm pushing these backports under the build-breaker rule; they
were all necessary for me to complete 'make check' on this old
branch from within Fedora 19. It will set the stage for the
CVE patches in another series.
Daniel P. Berrange (1):
Fix TLS tests with gnutls 3
Eric Blake (3):
build: allow building with newer glibc-headers and -O0
build: more workarounds for if_bridge.h
build: avoid confusing make with raw name 'undefine'
Jiri Denemark (1):
virsh: Fix POD syntax
configure.ac | 20 +++++++++++++++++---
m4/virt-compile-warnings.m4 | 8 ++++++--
src/util/virnetdevbridge.c | 18 ++++++++++++++++++
tests/Makefile.am | 10 ++++++----
tests/virnettlscontexttest.c | 25 +++++++++++++++----------
tests/{undefine => virsh-undefine} | 0
tools/virsh.pod | 4 ++--
7 files changed, 64 insertions(+), 21 deletions(-)
rename tests/{undefine => virsh-undefine} (100%)
--
1.8.3.1
11 years, 2 months
[libvirt] Remove more hardcoded paths from libvirtd --help
by Christophe Fergeau
In my previous 2 patches, I used constants defined in remote_driver.h to
build privileged libvirtd --help output. However, there are a few more
constants in this header that we can use to build the --help output,
this series addresses that.
Christophe
11 years, 2 months
[libvirt] [PATCH] docs: fix virEventAddHandle return details
by Jonathan Lebon
In commit 6d41cb8, the interface for virEventAddHandleFunc was changed.
This patch updates the documentation for virEventAddHandle to reflect
the new significance of the return value. Also, both functions now
mention -1 for failure.
---
include/libvirt/libvirt.h.in | 4 ++--
src/util/virevent.c | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index a47e33c..7944dfb 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -3643,8 +3643,8 @@ typedef void (*virEventHandleCallback)(int watch, int fd, int events, void *opaq
* If 'ff' callbacks are invoked directly from the virEventRemoveHandleFunc
* they will likely deadlock in libvirt.
*
- * Returns a handle watch number to be used for updating
- * and unregistering for events
+ * Returns -1 if the file handle cannot be registered, otherwise a handle
+ * watch number to be used for updating and unregistering for events
*/
typedef int (*virEventAddHandleFunc)(int fd, int event,
virEventHandleCallback cb,
diff --git a/src/util/virevent.c b/src/util/virevent.c
index 886cb6d..fde29a2 100644
--- a/src/util/virevent.c
+++ b/src/util/virevent.c
@@ -48,7 +48,8 @@ static virEventRemoveTimeoutFunc removeTimeoutImpl = NULL;
*
* Register a callback for monitoring file handle events.
*
- * Returns -1 if the file handle cannot be registered, 0 upon success
+ * Returns -1 if the file handle cannot be registered, otherwise a handle
+ * watch number to be used for updating and unregistering for events
*/
int
virEventAddHandle(int fd,
--
1.8.3.1
11 years, 2 months
[libvirt] [PATCH] Fix crash in remoteDispatchDomainMemoryStats (CVE-2013-4296)
by Eric Blake
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The 'stats' variable was not initialized to NULL, so if some
early validation of the RPC call fails, it is possible to jump
to the 'cleanup' label and VIR_FREE an uninitialized pointer.
This is a security flaw, since the API can be called from a
readonly connection which can trigger the validation checks.
This was introduced in release v0.9.1 onwards by
commit 158ba8730e44b7dd07a21ab90499996c5dec080a
Author: Daniel P. Berrange <berrange(a)redhat.com>
Date: Wed Apr 13 16:21:35 2011 +0100
Merge all returns paths from dispatcher into single path
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
Approved on the security list, and pushing on Daniel's behalf.
I'm now working on backporting this to the various v*-maint branches.
daemon/remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 6b082cf..3ac528c 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -1146,7 +1146,7 @@ remoteDispatchDomainMemoryStats(virNetServerPtr server ATTRIBUTE_UNUSED,
remote_domain_memory_stats_ret *ret)
{
virDomainPtr dom = NULL;
- struct _virDomainMemoryStat *stats;
+ struct _virDomainMemoryStat *stats = NULL;
int nr_stats;
size_t i;
int rv = -1;
--
1.8.3.1
11 years, 2 months
[libvirt] [PATCH 0/8] Normalization API
by Michal Privoznik
A while ago I've invented this vshCompleteXMLFromDomain() function to increase
device-detach intelligence. Basically, it took user's XML and tried to find
matching device in domain's XML. However, it was kind of buggy - finding the
matching device uses string comparison. This works on text values. It doesn't
on integer ones (who would expect that). So prior the lookup process, we need
to normalize the integer values (and whole XML). However, this can't be done on
the client side, since he has no knowledge which values are integer and which
are not. Therefore we need a new API.
Michal Privoznik (8):
domain_conf: Introduce virDomainDeviceDefFormat
Introduce new virDomainNormalizeXML API
remote_driver: Implement virDomainNormalizeXML
virsh: Expose virDomainNormalizeXML
qemu: Implement vimDomainNormalizeXML
domain_conf: Move MAC generation to post parse callback
virDomainDeviceDefParse: Make PostParse callback call optional
virsh: Resurrect vshCompleteXMLFromDomain
daemon/remote.c | 50 ++++++++
include/libvirt/libvirt.h.in | 5 +
python/generator.py | 1 +
python/libvirt-override-api.xml | 7 ++
python/libvirt-override.c | 30 +++++
src/conf/domain_conf.c | 180 ++++++++++++++++-------------
src/conf/domain_conf.h | 7 +-
src/driver.h | 7 ++
src/libvirt.c | 51 ++++++++
src/libvirt_private.syms | 1 +
src/libvirt_public.syms | 5 +
src/libxl/libxl_driver.c | 12 +-
src/lxc/lxc_driver.c | 6 +-
src/openvz/openvz_conf.c | 1 +
src/openvz/openvz_driver.c | 12 +-
src/phyp/phyp_driver.c | 2 +-
src/qemu/qemu_command.c | 7 +-
src/qemu/qemu_driver.c | 51 +++++++-
src/remote/remote_driver.c | 40 +++++++
src/remote/remote_protocol.x | 20 +++-
src/uml/uml_driver.c | 4 +-
src/vbox/vbox_tmpl.c | 5 +-
src/vmx/vmx.c | 2 +
src/xen/xend_internal.c | 6 +-
src/xen/xm_internal.c | 8 +-
src/xenapi/xenapi_driver.c | 1 +
src/xenxs/xen_sxpr.c | 1 +
src/xenxs/xen_xm.c | 1 +
tests/openvzutilstest.c | 1 -
tests/qemuhotplugtest.c | 3 +-
tools/virsh-domain.c | 249 +++++++++++++++++++++++++++++++++++++++-
tools/virsh.pod | 8 ++
32 files changed, 666 insertions(+), 118 deletions(-)
--
1.8.1.5
11 years, 2 months
[libvirt] [PATCH] doc: fix XML for the RNG device example
by Giuseppe Scrivano
Add a missing '/' to close the "source" element.
Signed-off-by: Giuseppe Scrivano <gscrivan(a)redhat.com>
---
A minor detail that I have noticed while I copy-pasting the example.
docs/formatdomain.html.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index a927643..3689399 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -4903,8 +4903,8 @@ qemu-kvm -net nic,model=? /dev/null
<backend model='random'>/dev/random</backend>
<!-- OR -->
<backend model='egd' type='udp'>
- <source mode='bind' service='1234'>
- <source mode='connect' host='1.2.3.4' service='1234'>
+ <source mode='bind' service='1234'/>
+ <source mode='connect' host='1.2.3.4' service='1234'/>
</backend>
</rng>
</devices>
--
1.8.3.1
11 years, 2 months
[libvirt] Integrating LiSA into libvirt
by Andreea Hodea
My name is Andreea and I am a member of LiSA team. LiSA stands for Linux Switching Appliance and offers a software switch that switches
packets at Layer 2 and Layer 3. It is an open source project under development, you can find more about it from lisa.mindbit.ro or from https://github.com/lisa-project/.
One of the development directions of LiSA is to integrate it into libvirt. First I'll state the motivation for such an integration and then I will describe a use case.
The main reasons for extending libvirt network component with LiSA are related to the fact that different hypervisors offer different switching engines with different capabilities. By integrating LiSA into libvirt, the virtual machines would connect to LiSA switch ports as they were linked through a physical switch. Hence, with LiSA, the switching engine would offer the same switching capabilities independent of hypervisor.
Moreover, if I understand correctly, in libvirt switching configurations are possible either through a set of commands in virsh or directly within a XML file. One of LiSA components is swcli that is a CLI for configuring and retrieving configurations of the software switch. Through swcli, the switching configurations (including VLANs, trunk or access mode interfaces etc.) are made through a CISCO-IOS like set of commands. I think this is a nice-to-have because it would separate complex network configurations from NIC configuration. That is, through libvirt the machines would just connect to the switch and other switching configurations, simple or complex, would be made from swcli. In other words, the XML file would remain simple and readable while the user would still be able to make switching specific configurations. In conclusion, LiSA and libvirt would make a great
team for building a complex networking model, without complicating the setup of a virtual network.
Scenario of where LiSA fits into libvirt
===========================
I thought at the following scenario: two virtual machines linked together through a LiSA switch, i.e. the LiSA switch being the physical machine running LiSA. We, LiSA team, started by studying the virt-manager interface and figured out that an entry in the "Source device" drop down list when configuring a domain NIC should suffice our goal for the moment. When applying these changes, the XML configuration file should contain an interface tag of type "lisa-switch" or something similar. Therefore, a patch to libvirt for integrating LiSA would contain:
- the implementation of two functions
- virNetDevLisaAddPort
- virNetDevLisaRemovePort
- and a new interface type (XML level) for network configuration.
I would like to have your feedback on the ideas above.
Thanks,
Andreea
11 years, 2 months
[libvirt] [PATCH 1/2] daemon: Fix 'caert.pem' typo in privileged help output
by Christophe Fergeau
The help message indicates that the CA certificate is
$sysconfdir/pki/CA/caert.pem while the actual path is
$sysconfdir/pki/CA/cacert.pem
This commit also fixes all translations files (through sed -i) to
avoid trivial fuzzy translations.
Signed-off-by: Christophe Fergeau <cfergeau(a)redhat.com>
---
daemon/libvirtd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index c9cd1a1..87d42b2 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -1063,7 +1063,7 @@ daemonUsage(const char *argv0, bool privileged)
" %s/run/libvirt/libvirt-sock-ro\n"
"\n"
" TLS:\n"
- " CA certificate: %s/pki/CA/caert.pem\n"
+ " CA certificate: %s/pki/CA/cacert.pem\n"
" Server certificate: %s/pki/libvirt/servercert.pem\n"
" Server private key: %s/pki/libvirt/private/serverkey.pem\n"
"\n"
--
1.8.3.1
11 years, 2 months
[libvirt] Operation not permitted when start vm
by yue
hi,all
please look at the error.
env:
libvirt-0.10.2-18.el6_4.5.x86_64
2.6.32-358.6.2.el6.x86_64
centos6.4
Thread-6291::ERROR::2013-09-18 12:44:21,205::vm::683::vm.Vm::(_startUnderlyingVm) vmId=`24f7e975-9aa5-4a14-b0f0-590add14c8b5`::The vm start process failed
Traceback (most recent call last):
File "/us r/share/vdsm/vm.py", line 645, in _startUnderlyingVm
self._run()
File "/usr/share/vdsm/libvirtvm.py", line 1529, in _run
self._connection.createXML(domxml, flags),
File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 83, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2645, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/4
qemu-kvm: -drive file=/rhev/data-center/7828f2ae-955e-4e4b-a4bb-43807629dc52/d028d521-d4a9-4dd7-a0fe-3e9b60e7c4e4/images/ac025dc1-4e25-4b71-8c56-88dcb61b9f09/cae1bb2d-0529-4287-95a3-13dcb14f082f,if=none,id=drive-ide0-0-0,format=qcow2,serial=ac025dc1-4e25-4b71-8c56-88dcb61b9f09,cache=none,werror=stop,rerror=stop,aio=n ative: could not open disk image /rhev/data-center/7828f2ae-955e-4e4b-a4bb-43807629dc52/d028d521-d4a9-4dd7-a0fe-3e9b60e7c4e4/images/ac025dc1-4e25-4b71-8c56-88dcb61b9f09/cae1bb2d-0529-4287-95a3-13dcb14f082f: Operation not permitted
11 years, 2 months
