[libvirt] adding bandwidth control support
by Max Zhen
My last post failed, resend...
Max Zhen at 2008-12-24 18:39 wrote:
> Hi,
>
> I'm working on adding bandwidth control support in
> virt-install/virsh/libvirt on Xen.
> This support can allow setting bandwidth control in dom0 (I'm working on
> Solaris dom0 now) for virtual nic devices used in a domU.
> I've attached my design in this email.
> Basically, this design is about how to represent bandwidth limit
> information in command line for virsh/virt-install and how to represent
> it in current XML configuration file for a domU.
>
> Your comments will be highly appreciated :).
>
> Thanks,
> Max
>
>
There are a few things to do to achieve this goal:
1. extend current command line syntax of 'virsh attach-interface'
2. extend current command line syntax of 'virt-install'
3. define bandwidth representation in XML format
For 1.
I will change the current command line syntax to:
virsh attach-interface <domain> <type> <source> [--target <target>]
[--mac <mac>] [--script <script>] [--rate <rate-string>]
So that we are able to specify bandwidth as "--rate 100M" in command line, like:
#virsh attach-interface domu bridge bge0 --rate 100M
In this case, bandwidth is specified as an integer with one of the scale
suffixes K, M, or G for Kbps, Mbps, or Gbps.
For 2.
I will add one more option "--rate=rate-string" to current option set of
virt-install command. Users can repeatedly add more than one 'rate' options
to set bandwidth for multiple nic devices respectively, if needed.
For example, with below command line, we start installing a domain with two
nic devices whose bandwidth are set to 100Mb/s and 200Mb/s respectively:
#virt-install -n snv105 -r 2048 -p --file=/root/snv105
--location=/solarisdvd.iso -b bge0 --rate=100M -b bge1 --rate=200M
In this case, bandwidth is specified as an integer with one of the scale
suffixes K, M, or G for Kbps, Mbps, or Gbps.
For 3.
All user specified bandwidth will be represented as part of interface
element currently defined in XML configuration file.
The new format looks like:
<interface type='bridge'>
<source bridge='e1000g1'/>
<flowcontrol>
<rate unit='megabit' period='second' value='100'/>
</flowcontrol>
</interface>
So, I create a new element, "flowcontrol", inside "interface" element. Inside
"flowcontrol", I provide bandwidth by setting "rate" element with three
attributes, "unit", "period" and "value" to express the bandwidth limit.
The supported unit can be 'gigabit', 'megabit' and 'kilobit'.
The supported period can be 'second', 'millisecond' and 'microsecond'.
And value is an integer to express the amount of data in unit allowed to be
transfered in period of time.
More elements can be added inside "flowcontrol" element, if we want to add more
flow control policies in the future.
15 years, 2 months
[libvirt] Adding VirtualBox support to libvirt
by Pritesh Kothari
Hi,
I am in the process of adding support for virtualbox in libvirt.
Basically Virtualbox exports its API through XPCOM. Now to simplify
things I was thinking of using C++ and already existing xpcom component
in virtualbox but since libvirt exports C API i am not sure if i should
use C++ or stick to plain C.
I would like to request the libvirt community for its comment
on this.
Regards,
Pritesh
15 years, 2 months
[libvirt] [PATCH ] (type ioem) adding qemu nic configuration option in to libvirt (XEN)
by Gihan Munasinghe
Guys
I have added a new attribute with with in <interface > tag called "qemu"
which can be either true or false..
Indicating if the user wants XEN to create qeum net device or not.. This
will fix the problem with PV net drivers with XEN..
Check the following examples
e.g 1) Interface tag with qemu attribute set to false
<interface type='bridge' qemu='false'>
<mac address='00:16:3e:00:a5:01'/>
<source bridge='eth0'/>
<target dev='vif1.0'/>
</interface>
qemu-dm output
---------------------
/usr/lib64/xen/bin/qemu-dm -d 60 -domain-name benchmark1 -k en-gb -vnc
0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net none -M xenfv
XEND has configured the hvm guest not to have network card via qemu
e.g 2) Interface tag with qemu attribute set to true with qemu supported
nic model
<interface type='bridge' qemu='true'>
<mac address='00:16:3e:00:a5:01'/>
<source bridge='eth0'/>
<target dev='vif1.0'/>
<model type='e1000'/>
</interface>
qemu-dm output
---------------------
/usr/lib64/xen/bin/qemu-dm -d 61 -domain-name benchmark1 -k en-gb -vnc
0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net
nic,vlan=1,macaddr=00:16:3e:00:a5:01,model=e1000 -net
tap,vlan=1,ifname=tap61.0,bridge=eth0 -M xenfv
Now XEND have configured the hvm guest to have emulated nic of the model
"e1000"
Therefore now, via libvirt configuration I have the ability ask xen to
either to configure qemu network card or not (when I have pv divers
installed with in my VM )
I have attached the patch files, Let me know what you guys think.
Thanks
Gihan
--
Gihan Munasinghe
R&D Team Leader
XCalibre Communications Ltd.
www.flexiscale.com
--- domain_conf.h.back 2008-12-04 15:31:38.000000000 +0000
+++ domain_conf.h 2008-12-04 20:28:16.000000000 +0000
@@ -127,9 +127,17 @@
VIR_DOMAIN_NET_TYPE_NETWORK,
VIR_DOMAIN_NET_TYPE_BRIDGE,
- VIR_DOMAIN_NET_TYPE_LAST,
+ VIR_DOMAIN_NET_TYPE_LAST
};
+/*Holds the values that can be passed as qemu attribute in <inteface >*/
+enum virDomainNetQemuAllocateType{
+ VIR_DOMAIN_NET_QEMU_ALLOC_TRUE,
+ VIR_DOMAIN_NET_QEMU_ALLOC_FALSE,
+
+ VIR_DOMAIN_NET_QEMU_ALLOC_LAST
+
+};
/* Stores the virtual network interface configuration */
typedef struct _virDomainNetDef virDomainNetDef;
@@ -156,6 +164,8 @@
} bridge;
} data;
char *ifname;
+ int qemu_allocate;/* This is set so that the users can ask xen not give vm's a network card
+ maily to with the (type none)/(type ieoum) tags wchi will be send to xend*/
};
enum virDomainChrSrcType {
@@ -608,5 +618,5 @@
VIR_ENUM_DECL(virDomainInput)
VIR_ENUM_DECL(virDomainInputBus)
VIR_ENUM_DECL(virDomainGraphics)
-
+VIR_ENUM_DECL(virDomainNetQemuAllocate)
#endif /* __DOMAIN_CONF_H */
--- domain_conf.c.back 2008-12-04 15:31:40.000000000 +0000
+++ domain_conf.c 2008-12-04 20:30:31.000000000 +0000
@@ -142,6 +142,10 @@
"usb",
"pci")
+VIR_ENUM_IMPL(virDomainNetQemuAllocate, VIR_DOMAIN_NET_QEMU_ALLOC_LAST,
+ "true",
+ "false")
+
#define virDomainReportError(conn, code, fmt...) \
virReportErrorHelper(conn, VIR_FROM_DOMAIN, code, __FILE__, \
__FUNCTION__, __LINE__, fmt)
@@ -787,6 +791,7 @@
char *address = NULL;
char *port = NULL;
char *model = NULL;
+ char *qemu_alloc = NULL;
if (VIR_ALLOC(def) < 0) {
virDomainReportError(conn, VIR_ERR_NO_MEMORY, NULL);
@@ -800,6 +805,17 @@
_("unknown interface type '%s'"), type);
goto error;
}
+ qemu_alloc = virXMLPropString(node, "qemu");
+ if( qemu_alloc!=NULL){
+ if ((def->qemu_allocate = virDomainNetQemuAllocateTypeFromString(qemu_alloc)) < 0) {
+ virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _("unknown qemu alloc '%s'"), qemu_alloc);
+ goto error;
+ }
+
+ }else{
+ def->qemu_allocate = VIR_DOMAIN_NET_QEMU_ALLOC_TRUE; // by default the aloocation will be true
+ }
} else {
def->type = VIR_DOMAIN_NET_TYPE_USER;
}
@@ -818,6 +834,7 @@
(def->type == VIR_DOMAIN_NET_TYPE_BRIDGE) &&
(xmlStrEqual(cur->name, BAD_CAST "source"))) {
bridge = virXMLPropString(cur, "bridge");
+
} else if ((dev == NULL) &&
(def->type == VIR_DOMAIN_NET_TYPE_ETHERNET) &&
xmlStrEqual(cur->name, BAD_CAST "source")) {
--- xend_internal.c.back 2008-12-04 15:31:38.000000000 +0000
+++ xend_internal.c 2008-12-04 21:05:49.000000000 +0000
@@ -1773,10 +1773,9 @@
if (VIR_ALLOC(net) < 0)
goto no_memory;
- if ((tmp2 && strstr(tmp2, "bridge")) || tmp) {
- net->type = VIR_DOMAIN_NET_TYPE_BRIDGE;
- /* XXX virtual network reverse resolve */
-
+ if ((tmp2 && (strstr(tmp2, "bridge") )) || tmp) {
+ net->type = VIR_DOMAIN_NET_TYPE_BRIDGE;
+ /* XXX virtual network reverse resolve */
if (tmp &&
!(net->data.bridge.brname = strdup(tmp)))
goto no_memory;
@@ -5153,10 +5152,15 @@
/*
* apparently (type ioemu) breaks paravirt drivers on HVM so skip this
- * from Xen 3.1.0
+ * from Xen 3.1.0 This happence as XEN try to allocate a network card via qemu
*/
- if ((hvm) && (xendConfigVersion < 4))
- virBufferAddLit(buf, "(type ioemu)");
+// if ((hvm) && (xendConfigVersion < 4) )
+ if ((hvm) && (def->qemu_allocate==VIR_DOMAIN_NET_QEMU_ALLOC_FALSE)){ /* If we have asked the qemu not to allocte a net work for hvm guest.
+ This way you would not have a problem with PV drivers on HVM guests*/
+ virBufferAddLit(buf, "(type none)");
+ }else {
+ virBufferAddLit(buf, "(type ioemu)");
+ }
if (!isAttach)
virBufferAddLit(buf, ")");
15 years, 3 months
[libvirt] [PATCH 0/7 RFC] RHEL-5 support, and a few preparatory fixes
by Markus Armbruster
This patch series attempts to make libvirt just work on RHEL-5. Right
now it doesn't, mostly because libvirt relies on version number checks
in a couple of places, and RHEL-5's version numbers aren't the whole
truth due to various backports of later stuff.
The first two patches are plain bug fixes:
[PATCH 1/7] Fix network device inconsistency between xm and sxpr
[PATCH 2/7] Fix graphics configuration inconsistency between xm and sxpr
The next three add a few special cases for RHEL-5:
[PATCH 3/7] New configure option --with-rhel5-api
[PATCH 4/7] Fix HVM network device configuration for RHEL-5
[PATCH 5/7] Fix PVFB device configuration for RHEL-5
[PATCH 6/7] Enable NUMA support for RHEL-5
The last one drops a counter-productive error check:
[PATCH 7/7] Don't treat missing topology information as error
See the patches for more detailed descriptions.
I'm not proposing this for immediate commit, as I'm still testing.
But I'd appreciate review: is this the right way to do it?
Thanks,
Markus
15 years, 3 months
[libvirt] kvm: save / restore
by Matthias Pfafferodt
Hallo,
I use kvm-81 and libvirt 0.5.1. I can save a kvm donain but if I want to
restore it I get the following error in the log file:
unknown migration protocol: stdio
I tried it using only kvm and got the same error.
How can I save / restore a VM to / from a file?
Kind regards
Matthias Pfafferodt
--
Matthias Pfafferodt - http://www.mapfa.de
Matthias.Pfafferodt <at> mapfa.de
15 years, 3 months
[libvirt] [PATCH] Improve compiler flag checking
by john.levon＠sun.com
# HG changeset patch
# User john.levon(a)sun.com
# Date 1229789393 28800
# Node ID a158bbc6df6fb8b15af875d08e73cfd3ca75f907
# Parent 34706075e6c801cd9532490c11b20b64dfcf464b
Improve compiler flag checking
Some compilers (including GCC) don't set the return value consistently
if an erroneous option is passed on the command line. Account for that.
Signed-off-by: John Levon <john.levon(a)sun.com>
diff --git a/acinclude.m4 b/acinclude.m4
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -45,21 +45,9 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[
;;
esac
- compiler_flags=
+ COMPILER_FLAGS=
for option in $try_compiler_flags; do
- SAVE_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS $option"
- AC_MSG_CHECKING([whether gcc understands $option])
- AC_TRY_LINK([], [],
- has_option=yes,
- has_option=no,)
- CFLAGS="$SAVE_CFLAGS"
- AC_MSG_RESULT($has_option)
- if test $has_option = yes; then
- compiler_flags="$compiler_flags $option"
- fi
- unset has_option
- unset SAVE_CFLAGS
+ gl_COMPILER_FLAGS($option)
done
unset option
unset try_compiler_flags
@@ -85,7 +73,7 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[
fi
AC_MSG_RESULT($complCFLAGS)
- WARN_CFLAGS="$compiler_flags $complCFLAGS"
+ WARN_CFLAGS="$COMPILER_FLAGS $complCFLAGS"
AC_SUBST(WARN_CFLAGS)
dnl Needed to keep compile quiet on python 2.4
diff --git a/m4/compiler-flags.m4 b/m4/compiler-flags.m4
--- a/m4/compiler-flags.m4
+++ b/m4/compiler-flags.m4
@@ -25,10 +25,16 @@ AC_DEFUN([gl_COMPILER_FLAGS],
AC_SUBST(COMPILER_FLAGS)
ac_save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS $1"
- AC_TRY_COMPILE(,
- [int x;],
- COMPILER_FLAGS="$COMPILER_FLAGS $1"
- AC_MSG_RESULT(yes),
- AC_MSG_RESULT(no))
- CFLAGS="$ac_save_CFLAGS"
+ AC_TRY_LINK([], [], has_option=yes, has_option=no,)
+ echo 'int x;' >conftest.c
+ $CC $CFLAGS -c conftest.c 2>conftest.err
+ ret=$?
+ if test $ret != 0 -o -s conftest.err -o $has_option = "no"; then
+ AC_MSG_RESULT(no)
+ else
+ AC_MSG_RESULT(yes)
+ COMPILER_FLAGS="$COMPILER_FLAGS $1"
+ fi
+ CFLAGS="$ac_save_CFLAGS"
+ rm -f conftest*
])
15 years, 3 months
[libvirt] proposal: allow use of "bool": HACKING: discuss C types
by Jim Meyering
Hello,
I don't want to make waves, but I do care about certain aspects
of code quality, so...
I propose to allow (encourage, even) the use of the standard C99 type,
bool, in libvirt, but not in public interfaces[1]. There are already
uses in cgroup.c and xmlrpc.c, as well as those in the gnulib "c-ctype.h"
header which is included from many of libvirt's .c files.
The motivation is to make the code as readable as possible.
When you see the declaration of an "int" variable, member, or function,
that type gives you no clue whether it is used as a boolean. If you
see a few uses that treat it as boolean, that's still no guarantee,
and it may be non-trivial to ensure that there isn't some non-boolean
value with a special meaning.
However, if you see a "bool" variable, you do have that guarantee.
This is one reason to using the tighter, more descriptive type.
In addition, if ever you need to go back to using "int", it's trivial
to automate the substitution, e.g., -Dint=bool or sed s/int/bool/.
On the other hand, it is very hard to automatically identify "int"
variables that may safely be converted to "bool".
Portability is no problem whatsoever, thanks to gnulib's stdbool module,
which ensures that there is a working <stdbool.h> header in the compiler's
include path. libvirt even includes/runs a test to ensure that the
<stdbool.h> in use (from gnulib or from the system) works properly.
Of course, if you agree on principle, we should update HACKING to reflect
the policy, so I've taken a shot at that. But if we start talking about
using the right type for boolean variables, we can't avoid the more general
question of scalars, signedness, etc. And once you mention scalars,
you have to mention pointers and const-correctness, so it got longer still.
Patch below.
Jim
[1]: We can use "bool" reliably in libvirt-internal code, due to
the fact that it is guaranteed to be compiled with a usable
<stdbool.h> header. We cannot make such a guarantee for
all applications that compile code including libvirt's
public headers, <libvirt.h> and <virterror.h>.
P.S. I confess I have a vested interested. I wrote a patch
recently that declares a local to be of type "bool", and would
like to ensure that policy permits doing that.
>From 3c6a9bc0fd043ce9f84e5aaba3cfbc1db0359eb7 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Fri, 12 Dec 2008 09:45:31 +0100
Subject: [PATCH] HACKING: use the right type
---
HACKING | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/HACKING b/HACKING
index 3945833..511c8cc 100644
--- a/HACKING
+++ b/HACKING
@@ -91,6 +91,52 @@ Usually they're in macro definitions or strings, and should be converted
anyhow.
+C types
+=======
+Use the right type.
+
+Scalars
+-------
+If you're using "int" or "long", odds are good that there's a better type.
+If a variable is counting something, be sure to declare it with an
+unsigned type.
+If it's memory-size-related, use size_t (use ssize_t only if required).
+If it's file-size related, use uintmax_t, or maybe off_t.
+If it's file-offset related (i.e., signed), use off_t.
+If it's just counting small numbers use "unsigned int";
+(on all but oddball embedded systems, you can assume that that
+type is at least four bytes wide).
+If a variable has boolean semantics, give it the "bool" type
+and use the corresponding "true" and "false" macros. It's ok
+to include <stdbool.h>, since libvirt's use of gnulib ensures
+that it exists and is usable.
+In the unusual event that you require a specific width, use a
+standard type like int32_t, uint32_t, uint64_t, etc.
+
+Of course, take all of the above with a grain of salt. If you're about
+to use some system interface that requires a type like int or ssize_t,
+use types for your own variables that match.
+
+Also, if you try to use e.g., "unsigned int" as a type, and that
+conflicts with the signedness of a related variable, sometimes
+it's best just to use the *wrong* type, if "pulling the thread"
+and fixing all related variables would be too invasive.
+
+Finally, while using descriptive types is important, be careful not to
+go overboard. If whatever you're doing causes warnings, or requires
+casts, then reconsider or ask for help.
+
+Pointers
+--------
+Ensure that all of your pointers are "const-correct".
+Unless a pointer is used to modify the pointed-to storage,
+give it the "const" attribute. That way, the reader knows
+up-front that this is a read-only pointer. Perhaps more
+importantly, if we're diligent about this, when you see a non-const
+pointer, you're guaranteed that it is used to modify the storage
+it points to, or it is aliased to another pointer that is.
+
+
Low level memory management
===========================
--
1.6.1.rc2.299.gead4c.dirty
15 years, 3 months
[libvirt] [PATCH] Fix remote_protocol header for Solaris
by john.levon＠sun.com
# HG changeset patch
# User john.levon(a)sun.com
# Date 1229367889 28800
# Node ID 46a487775d4b35c32455a5ca8eb3009d10a02c5b
# Parent a1f24e9f8a1fbf191c71172ae986110b7e98fc32
Fix remote_protocol header for Solaris
quad_t is not a portable type, but rather than force rpcgen
every build, we just patch in the fixes needed.
Signed-off-by: John Levon <john.levon(a)sun.com>
diff --git a/qemud/Makefile.am b/qemud/Makefile.am
--- a/qemud/Makefile.am
+++ b/qemud/Makefile.am
@@ -47,6 +47,7 @@ if GLIBC_RPCGEN
chmod 444 $@-t
mv $@-t $@
endif
+ patch < rpcgen-solaris.diff
endif
remote_protocol.c: remote_protocol.h
diff --git a/qemud/rpcgen-solaris.diff b/qemud/rpcgen-solaris.diff
new file mode 100644
--- /dev/null
+++ b/qemud/rpcgen-solaris.diff
@@ -0,0 +1,19 @@
+diff ./remote_protocol.h ./remote_protocol.h
+--- ./remote_protocol.h
++++ ./remote_protocol.h
+@@ -11,6 +11,15 @@
+
+ #ifdef __cplusplus
+ extern "C" {
++#endif
++
++#if defined(__sun)
++#include <rpc/xdr.h>
++#define u_quad_t uint64_t
++#define quad_t int64_t
++#define xdr_u_quad_t xdr_uint64_t
++#define xdr_quad_t xdr_int64_t
++#define IXDR_GET_LONG IXDR_GET_INT32
+ #endif
+
+ #include <config.h>
15 years, 3 months
[libvirt] [PATCH] Avoid GCC extensions
by john.levon＠sun.com
# HG changeset patch
# User john.levon(a)sun.com
# Date 1229367890 28800
# Node ID 6a8e82d7d2e166880fed8d7ad860a3e2e93d62be
# Parent c324c231c6a50be9f970f0f6c6d1629a7c09ab3b
Avoid GCC extensions
Anonymous unions are not portable, nor are zero-sizes structures.
Signed-off-by: John Levon <john.levon(a)sun.com>
diff --git a/src/domain_conf.c b/src/domain_conf.c
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -1437,7 +1437,7 @@ virDomainHostdevSubsysUsbDefParseXML(vir
if (vendor) {
if (virStrToLong_ui(vendor, NULL, 0,
- &def->source.subsys.usb.vendor) < 0) {
+ &def->source.subsys.u.usb.vendor) < 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_("cannot parse vendor id %s"), vendor);
VIR_FREE(vendor);
@@ -1454,7 +1454,7 @@ virDomainHostdevSubsysUsbDefParseXML(vir
if (product) {
if (virStrToLong_ui(product, NULL, 0,
- &def->source.subsys.usb.product) < 0) {
+ &def->source.subsys.u.usb.product) < 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_("cannot parse product %s"), product);
VIR_FREE(product);
@@ -1472,7 +1472,7 @@ virDomainHostdevSubsysUsbDefParseXML(vir
bus = virXMLPropString(cur, "bus");
if (bus) {
if (virStrToLong_ui(bus, NULL, 0,
- &def->source.subsys.usb.bus) < 0) {
+ &def->source.subsys.u.usb.bus) < 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_("cannot parse bus %s"), bus);
VIR_FREE(bus);
@@ -1488,7 +1488,7 @@ virDomainHostdevSubsysUsbDefParseXML(vir
device = virXMLPropString(cur, "device");
if (device) {
if (virStrToLong_ui(device, NULL, 0,
- &def->source.subsys.usb.device) < 0) {
+ &def->source.subsys.u.usb.device) < 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_("cannot parse device %s"),
device);
@@ -1510,14 +1510,14 @@ virDomainHostdevSubsysUsbDefParseXML(vir
cur = cur->next;
}
- if (def->source.subsys.usb.vendor == 0 &&
- def->source.subsys.usb.product != 0) {
+ if (def->source.subsys.u.usb.vendor == 0 &&
+ def->source.subsys.u.usb.product != 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
"%s", _("missing vendor"));
goto out;
}
- if (def->source.subsys.usb.vendor != 0 &&
- def->source.subsys.usb.product == 0) {
+ if (def->source.subsys.u.usb.vendor != 0 &&
+ def->source.subsys.u.usb.product == 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
"%s", _("missing product"));
goto out;
@@ -2951,15 +2951,15 @@ virDomainHostdevDefFormat(virConnectPtr
virBufferVSprintf(buf, " <hostdev mode='%s' type='%s'>\n", mode, type);
virBufferAddLit(buf, " <source>\n");
- if (def->source.subsys.usb.vendor) {
+ if (def->source.subsys.u.usb.vendor) {
virBufferVSprintf(buf, " <vendor id='0x%.4x'/>\n",
- def->source.subsys.usb.vendor);
+ def->source.subsys.u.usb.vendor);
virBufferVSprintf(buf, " <product id='0x%.4x'/>\n",
- def->source.subsys.usb.product);
+ def->source.subsys.u.usb.product);
} else {
virBufferVSprintf(buf, " <address bus='%d' device='%d'/>\n",
- def->source.subsys.usb.bus,
- def->source.subsys.usb.device);
+ def->source.subsys.u.usb.bus,
+ def->source.subsys.u.usb.device);
}
virBufferAddLit(buf, " </source>\n");
diff --git a/src/domain_conf.h b/src/domain_conf.h
--- a/src/domain_conf.h
+++ b/src/domain_conf.h
@@ -307,12 +307,13 @@ struct _virDomainHostdevDef {
unsigned slot;
unsigned function;
} pci;
- };
+ } u;
} subsys;
struct {
/* TBD: struct capabilities see:
* https://www.redhat.com/archives/libvir-list/2008-July/msg00429.html
*/
+ int dummy;
} caps;
} source;
char* target;
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -1264,15 +1264,15 @@ int qemudBuildCommandLine(virConnectPtr
if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB) {
- if(hostdev->source.subsys.usb.vendor) {
+ if(hostdev->source.subsys.u.usb.vendor) {
ret = asprintf(&usbdev, "host:%.4x:%.4x",
- hostdev->source.subsys.usb.vendor,
- hostdev->source.subsys.usb.product);
+ hostdev->source.subsys.u.usb.vendor,
+ hostdev->source.subsys.u.usb.product);
} else {
ret = asprintf(&usbdev, "host:%.3d.%.3d",
- hostdev->source.subsys.usb.bus,
- hostdev->source.subsys.usb.device);
+ hostdev->source.subsys.u.usb.bus,
+ hostdev->source.subsys.u.usb.device);
}
if (ret < 0) {
usbdev = NULL;
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2790,14 +2790,14 @@ static int qemudDomainAttachHostDevice(v
return -1;
}
- if (dev->data.hostdev->source.subsys.usb.vendor) {
+ if (dev->data.hostdev->source.subsys.u.usb.vendor) {
ret = asprintf(&cmd, "usb_add host:%.4x:%.4x",
- dev->data.hostdev->source.subsys.usb.vendor,
- dev->data.hostdev->source.subsys.usb.product);
+ dev->data.hostdev->source.subsys.u.usb.vendor,
+ dev->data.hostdev->source.subsys.u.usb.product);
} else {
ret = asprintf(&cmd, "usb_add host:%.3d.%.3d",
- dev->data.hostdev->source.subsys.usb.bus,
- dev->data.hostdev->source.subsys.usb.device);
+ dev->data.hostdev->source.subsys.u.usb.bus,
+ dev->data.hostdev->source.subsys.u.usb.device);
}
if (ret == -1) {
qemudReportError(dom->conn, NULL, NULL, VIR_ERR_NO_MEMORY, NULL);
diff --git a/src/remote_internal.c b/src/remote_internal.c
--- a/src/remote_internal.c
+++ b/src/remote_internal.c
@@ -649,7 +649,7 @@ doRemoteOpen (virConnectPtr conn,
if (username) nr_args += 2; /* For -l username */
if (no_tty) nr_args += 5; /* For -T -o BatchMode=yes -e none */
- command = command ? : strdup ("ssh");
+ command = command ? command : strdup ("ssh");
if (command == NULL)
goto out_of_memory;
15 years, 3 months
