Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by Ben Hutchings
On Wed, 2013-01-16 at 12:04 -0500, Mike Frysinger wrote:
> On Wednesday 16 January 2013 10:47:12 Ben Hutchings wrote:
> > On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
> > > Cong Wang wrote:
> > > > (Cc'ing some glibc developers...)
> > > >
> > > > Hello,
> > > >
> > > > In glibc source file inet/netinet/in.h and kernel source file
> > > > include/uapi/linux/in6.h, both define struct in6_addr, and both are
> > > > visible to user applications. Thomas reported a conflict below.
> > > >
> > > > So, how can we handle this? /me is wondering why we didn't see this
> > > > before.
> >
> > [...]
> >
> > > This is not a new issue. In addition to this,
> > > netinet/in.h also conflits with linux/in.h.
> > >
> > > We might have
> > >
> > > #if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
> > >
> > > #endif
> > >
> > > around those conflicting definitions in uapi/linux/in{,6}.h.
> >
> > This only solves half the problem, as <netinet/in.h> might be included
> > after <linux/in.h>. Also, not all Linux userland uses glibc.
>
> certainly true, but the current expectation is that you don't mix your ABIs.
Whose expectation? Which ABIs are being mixed?
> if you're programming with the C library API, then use the C library headers.
> if you're banging directly on the kernel, then use the kernel headers. not
> saying it's a perfect solution, but it works for the vast majority of use
> cases.
In practice most C programs for Linux will use a mixture of thinly
wrapped system calls and higher-level APIs from the C library, and never
really call the kernel directly (as that requires inline assembler).
Userland programmers will work around this historical mess by tweaking
the #include order or splitting source files. But they shouldn't have
to.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
12 years, 3 months
[libvirt] [PATCH] qemu: fix QEMU_CAPS_NO_ACPI detection
by Ján Tomko
In commit c4bbaaf8, caps->arch was checked uninitialized, rendering the
whole check useless.
This patch moves the conditional setting of QEMU_CAPS_NO_ACPI to
qemuCapsInitQMP, and removes the no longer needed exception for S390.
It also clears the flag for all non-x86 archs instead of just S390 in
qemuCapsInitHelp.
---
src/qemu/qemu_capabilities.c | 29 ++++++++---------------------
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 167cdb2..e0d0c2a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2175,13 +2175,11 @@ qemuCapsInitHelp(qemuCapsPtr caps, uid_t runUid, gid_t runGid)
if (caps->arch == VIR_ARCH_X86_64 ||
caps->arch == VIR_ARCH_I686) {
qemuCapsSet(caps, QEMU_CAPS_PCI_MULTIBUS);
- }
-
- /* S390 and probably other archs do not support no-acpi -
- maybe the qemu option parsing should be re-thought. */
- if (caps->arch == VIR_ARCH_S390 ||
- caps->arch == VIR_ARCH_S390X)
+ } else {
+ /* -no-acpi is not supported on other archs
+ * even if qemu reports it in -help */
qemuCapsClear(caps, QEMU_CAPS_NO_ACPI);
+ }
/* qemuCapsExtractDeviceStr will only set additional caps if qemu
* understands the 0.13.0+ notion of "-device driver,". */
@@ -2260,13 +2258,6 @@ qemuCapsInitQMPBasic(qemuCapsPtr caps)
qemuCapsSet(caps, QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC);
qemuCapsSet(caps, QEMU_CAPS_NO_SHUTDOWN);
qemuCapsSet(caps, QEMU_CAPS_DRIVE_CACHE_UNSAFE);
-
- /* ACPI is only supported on x86, PPC or
- * other platforms don't support it*/
- if (caps->arch == VIR_ARCH_I686 ||
- caps->arch == VIR_ARCH_X86_64)
- qemuCapsSet(caps, QEMU_CAPS_NO_ACPI);
-
qemuCapsSet(caps, QEMU_CAPS_FSDEV_READONLY);
qemuCapsSet(caps, QEMU_CAPS_VIRTIO_BLK_SG_IO);
qemuCapsSet(caps, QEMU_CAPS_DRIVE_COPY_ON_READ);
@@ -2402,16 +2393,12 @@ qemuCapsInitQMP(qemuCapsPtr caps,
}
VIR_FREE(archstr);
- /* Currently only x86_64 and i686 support PCI-multibus. */
+ /* Currently only x86_64 and i686 support PCI-multibus and -no-acpi. */
if (caps->arch == VIR_ARCH_X86_64 ||
- caps->arch == VIR_ARCH_I686)
+ caps->arch == VIR_ARCH_I686) {
qemuCapsSet(caps, QEMU_CAPS_PCI_MULTIBUS);
-
- /* S390 and probably other archs do not support no-acpi -
- maybe the qemu option parsing should be re-thought. */
- if (caps->arch == VIR_ARCH_S390 ||
- caps->arch == VIR_ARCH_S390X)
- qemuCapsClear(caps, QEMU_CAPS_NO_ACPI);
+ qemuCapsSet(caps, QEMU_CAPS_NO_ACPI);
+ }
if (qemuCapsProbeQMPCommands(caps, mon) < 0)
goto cleanup;
--
1.7.8.6
12 years, 3 months
[libvirt] [PATCH 00/14] Resolve some RESOURCE_LEAK errors found by Coverity
by John Ferlan
This patch addresses some "Error: RESOURCE_LEAK (CWE-404)" errors found by
Coverity. There are 100+ remaining; however, many seem to be false positives
which will be addressed in a separate patch.
The esx_driver.c and hyperv_driver.c changes could be tagged as false
positives; however, the changes made will avoid the Coverity error since
the freeing of the resource marked isn't based soley on the result.
The phyp_driver.c changes in openSSHSession() and its callers were the most
involved since the code with now use connection_data->sock in order to track
the socket so as to allow it to be closed once done with it. Of interest in
this change is that phypExec() used connection_data->sock even though it
had never been initialized.
John Ferlan (14):
phyp: Resolve some file descriptor leaks
esx: Address resource leak found by Coverity
storage: Resolve resource leak using 'vol' buffer
util: Resolve resource leak for 'res' in virSetInherit error path.
locking: Resolve resource leak with 'dir' on non error path
rpc: Avoid resource leak of 'socks' if any object append fails
uml: Avoid resource leak of event in umlInofityEvent
test: Resource resource leak with 'tmp_vols'
storage: Resource resource leak using 'tmp_vols'
interface: Resolve resource leak wth 'tmp_iface_objs'
xen: Resource resource leak with 'cpuset'
parallels: Resolve some resource leaks
storage: Need to also VIR_FREE(reg)
hyperv: Address resource leak found by Coverityo
src/esx/esx_driver.c | 8 ++++----
src/hyperv/hyperv_driver.c | 10 +++++-----
src/interface/interface_backend_netcf.c | 1 +
src/locking/lock_driver_sanlock.c | 1 +
src/parallels/parallels_driver.c | 30 +++++++++++++++++++-----------
src/phyp/phyp_driver.c | 19 ++++++++++++++-----
src/rpc/virnetserverservice.c | 6 +++---
src/storage/storage_backend_logical.c | 1 +
src/storage/storage_backend_rbd.c | 13 ++++++++++---
src/storage/storage_driver.c | 1 +
src/test/test_driver.c | 1 +
src/uml/uml_driver.c | 6 ++++--
src/util/virlockspace.c | 1 +
src/xen/xend_internal.c | 12 ++++++------
14 files changed, 71 insertions(+), 39 deletions(-)
--
1.7.11.7
12 years, 3 months
[libvirt] [PATCH] Add RESUME event listener to qemu monitor.
by Andres Lagar-Cavilla
Perform all the appropriate plumbing.
When qemu/KVM VMs are paused manually through a monitor not-owned by libvirt,
libvirt will think of them as "paused" event after they are resumed and
effectively running. With this patch the discrepancy goes away.
This is meant to address bug 892791.
Signed-off-by: Andres Lagar-Cavilla <andres(a)lagarcavilla.org>
---
src/qemu/qemu_monitor.c | 10 ++++++++
src/qemu/qemu_monitor.h | 3 +++
src/qemu/qemu_monitor_json.c | 7 ++++++
src/qemu/qemu_process.c | 56 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 76 insertions(+)
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 99642b6..cb5a3e2 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -1022,6 +1022,16 @@ int qemuMonitorEmitStop(qemuMonitorPtr mon)
}
+int qemuMonitorEmitResume(qemuMonitorPtr mon)
+{
+ int ret = -1;
+ VIR_DEBUG("mon=%p", mon);
+
+ QEMU_MONITOR_CALLBACK(mon, ret, domainResume, mon->vm);
+ return ret;
+}
+
+
int qemuMonitorEmitRTCChange(qemuMonitorPtr mon, long long offset)
{
int ret = -1;
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index d7faa90..00ce813 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -97,6 +97,8 @@ struct _qemuMonitorCallbacks {
virDomainObjPtr vm);
int (*domainStop)(qemuMonitorPtr mon,
virDomainObjPtr vm);
+ int (*domainResume)(qemuMonitorPtr mon,
+ virDomainObjPtr vm);
int (*domainRTCChange)(qemuMonitorPtr mon,
virDomainObjPtr vm,
long long offset);
@@ -187,6 +189,7 @@ int qemuMonitorEmitShutdown(qemuMonitorPtr mon);
int qemuMonitorEmitReset(qemuMonitorPtr mon);
int qemuMonitorEmitPowerdown(qemuMonitorPtr mon);
int qemuMonitorEmitStop(qemuMonitorPtr mon);
+int qemuMonitorEmitResume(qemuMonitorPtr mon);
int qemuMonitorEmitRTCChange(qemuMonitorPtr mon, long long offset);
int qemuMonitorEmitWatchdog(qemuMonitorPtr mon, int action);
int qemuMonitorEmitIOError(qemuMonitorPtr mon,
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 2d2d254..de5f115 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -55,6 +55,7 @@ static void qemuMonitorJSONHandleShutdown(qemuMonitorPtr mon, virJSONValuePtr da
static void qemuMonitorJSONHandleReset(qemuMonitorPtr mon, virJSONValuePtr data);
static void qemuMonitorJSONHandlePowerdown(qemuMonitorPtr mon, virJSONValuePtr data);
static void qemuMonitorJSONHandleStop(qemuMonitorPtr mon, virJSONValuePtr data);
+static void qemuMonitorJSONHandleResume(qemuMonitorPtr mon, virJSONValuePtr data);
static void qemuMonitorJSONHandleRTCChange(qemuMonitorPtr mon, virJSONValuePtr data);
static void qemuMonitorJSONHandleWatchdog(qemuMonitorPtr mon, virJSONValuePtr data);
static void qemuMonitorJSONHandleIOError(qemuMonitorPtr mon, virJSONValuePtr data);
@@ -87,6 +88,7 @@ static qemuEventHandler eventHandlers[] = {
{ "DEVICE_TRAY_MOVED", qemuMonitorJSONHandleTrayChange, },
{ "POWERDOWN", qemuMonitorJSONHandlePowerdown, },
{ "RESET", qemuMonitorJSONHandleReset, },
+ { "RESUME", qemuMonitorJSONHandleResume, },
{ "RTC_CHANGE", qemuMonitorJSONHandleRTCChange, },
{ "SHUTDOWN", qemuMonitorJSONHandleShutdown, },
{ "SPICE_CONNECTED", qemuMonitorJSONHandleSPICEConnect, },
@@ -589,6 +591,11 @@ static void qemuMonitorJSONHandleStop(qemuMonitorPtr mon, virJSONValuePtr data A
qemuMonitorEmitStop(mon);
}
+static void qemuMonitorJSONHandleResume(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED)
+{
+ qemuMonitorEmitResume(mon);
+}
+
static void qemuMonitorJSONHandleRTCChange(qemuMonitorPtr mon, virJSONValuePtr data)
{
long long offset = 0;
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index f5fc1b3..938c17e 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -736,6 +736,61 @@ unlock:
static int
+qemuProcessHandleResume(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
+ virDomainObjPtr vm)
+{
+ virQEMUDriverPtr driver = qemu_driver;
+ virDomainEventPtr event = NULL;
+
+ virDomainObjLock(vm);
+ if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_PAUSED) {
+ qemuDomainObjPrivatePtr priv = vm->privateData;
+
+ if (priv->gotShutdown) {
+ VIR_DEBUG("Ignoring RESUME event after SHUTDOWN");
+ goto unlock;
+ }
+
+ VIR_DEBUG("Transitioned guest %s out of paused into resumed state",
+ vm->def->name);
+
+ virDomainObjSetState(vm, VIR_DOMAIN_RUNNING,
+ VIR_DOMAIN_RUNNING_UNPAUSED);
+ event = virDomainEventNewFromObj(vm,
+ VIR_DOMAIN_EVENT_RESUMED,
+ VIR_DOMAIN_EVENT_RESUMED_UNPAUSED);
+
+ VIR_DEBUG("Using lock state '%s' on resume event", NULLSTR(priv->lockState));
+ if (virDomainLockProcessResume(driver->lockManager, driver->uri,
+ vm, priv->lockState) < 0) {
+ /* Don't free priv->lockState on error, because we need
+ * to make sure we have state still present if the user
+ * tries to resume again
+ */
+ goto unlock;
+ }
+ VIR_FREE(priv->lockState);
+
+ if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0) {
+ VIR_WARN("Unable to save status on vm %s after state change",
+ vm->def->name);
+ }
+ }
+
+unlock:
+ virDomainObjUnlock(vm);
+
+ if (event) {
+ qemuDriverLock(driver);
+ qemuDomainEventQueue(driver, event);
+ qemuDriverUnlock(driver);
+ }
+
+ return 0;
+}
+
+
+static int
qemuProcessHandleRTCChange(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
virDomainObjPtr vm,
long long offset)
@@ -1250,6 +1305,7 @@ static qemuMonitorCallbacks monitorCallbacks = {
.diskSecretLookup = qemuProcessFindVolumeQcowPassphrase,
.domainShutdown = qemuProcessHandleShutdown,
.domainStop = qemuProcessHandleStop,
+ .domainResume = qemuProcessHandleResume,
.domainReset = qemuProcessHandleReset,
.domainRTCChange = qemuProcessHandleRTCChange,
.domainWatchdog = qemuProcessHandleWatchdog,
--
1.7.9.5
12 years, 4 months
[libvirt] [PATCH 00/13] More refactoring of QEMU driver objects & locking
by Daniel P. Berrange
This series does more general refactoring to help in the goal of killing
the big QEMU driver lock. There are 3 key changes in this series
- Isolating all QEMU configuration parameters in one struct.
- Making virDomainObjList self-locking
- Add dedicated locking to PCI/USB device lists
There are all the really hard bits of the QEMU locking. As can be seen
from the last patch there is still more work to be done before the QEMU
driver lock can be said to be truely dead, but this is less critical.
12 years, 4 months
[libvirt] Libvirt daemon not getting started
by Varun Bhatnagar
Hi,
Earlier I was having libvirt-0.7.5 but now I have installed 0.9.8 version
of libvirt now.
I am trying to start libvirt daemon using the command below but daemon it
is not getting started and the PID file is not getting created. Tried
/usr/loval/sbin/libvirtd -d option too. In that case I am not getting any
error but PID file is not getting created in this case too.
/usr/local/sbin/libvirtd
2013-01-16 16:43:53.399+0000: 4070: info : libvirt version: 0.9.8
2013-01-16 16:43:53.399+0000: 4070: error : virCommandWait:2192 : internal
error Child process (/usr/sbin/iptables --table mangle --delete
POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68
--jump CHECKSUM --checksum-fill) status unexpected: exit status 2
2013-01-16 16:43:53.406+0000: 4070: error : virCommandWait:2192 : internal
error Child process (/usr/sbin/iptables --table mangle --insert
POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68
--jump CHECKSUM --checksum-fill) status unexpected: exit status 2
2013-01-16 16:43:53.406+0000: 4070: warning :
networkAddGeneralIptablesRules:1259 : Could not add rule to fixup DHCP
response checksums on network 'default'.
2013-01-16 16:43:53.406+0000: 4070: warning :
networkAddGeneralIptablesRules:1260 : May need to update iptables package
& kernel to support CHECKSUM rule.
2013-01-16 16:43:54.704+0000: 4070: error : umlStartup:471 : cannot
initialize inotify
2013-01-16 16:43:54.704+0000: 4070: error : virStateInitialize:854 :
Initialization of UML state driver failed
2013-01-16 16:43:54.704+0000: 4070: error : daemonRunStateInit:1157 :
Driver state initialization failed
and I am also trying to connect to VMPlayer with the following URL but it
is giving the following error message:
virsh # connect vmplayer:///session
error: Failed to connect to the hypervisor
error: Failed to connect socket to
'/usr/local/var/run/libvirt/libvirt-sock': No such file or directory
Is this because of the daemon, as it is not getting started or because of
some other reason?
Can anybody suggest any solution for this. I am stuck from past few days
and not able to find solution. Any help will be appreciated.
Thanks in advance.
Regards,
Varun
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
12 years, 4 months
[libvirt] [PATCH 0/7] Share the VNC port allocation tracking code
by Daniel P. Berrange
Both QEMU and libxl have the same code for tracking auto-allocated
VNC ports. Move this code out into src/util/virportallocator.[c,h].
While doing this turn it into a virObjectLockable so that it becomes
a ref-counted object with self-contained locking. This means it no
longer needs to be protected by the QEMU/libxl global driver locks.
As part of this series the virObject APIs are enhanced to allow
arbitrarily deep inheritance (instead of fixed 1 level), and a
new virObjectLockable base class is introduced which extends
virObject to provide a mutex. This is a very common need so many
existing classes are updated to use it.
12 years, 4 months
[libvirt] [PATCH 0/6] add qemu usb-scsi controller support
by Guannan Ren
This patchset tries to add usb-scsi model for SCSI controller.
http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg03382.html
"usb-uas is a pure UAS (usb attached scsi) emulation.
The emulation works like any other scsi hba emulation (eps, lsi, virtio,
megasas, ...). It provides just the HBA where you can attach scsi
devices as you like using '-device'. A single scsi target with up to
256 luns is supported. For now only usb 2.0 transport is supported."
libvirt XML snip
<devices>
<controller type='usb' index='2' model='ehci'>
</controller>
<controller type='scsi' index='0' model='usb-scsi'>
<address type='usb' bus='2' port='1'/>
</controller>
</devices>
qemu commandline:
qemu ${other_vm_args} \
-device usb-ehci,id=usb2,bus=pci.0,addr=0x8 \
-device usb-uas,id=scsi0,bus=usb2.0,port=1
When a scsi disk is attached to usb-scsi controller, the target
id must 0(usb-scsi only provide one scsi target). The unit value
must in range of 0~255 for its lun number.
As for the guest, the kernel with CONFIG_USB_UAS=y is necessary to have it show up
scsi disk attached to UAS. Fedora has the kernel driver disabled by default though.
(thanks to Gerd Hoffmann's suggestion)
I grabbed linux-3.7.1 version from kernel website. It works after compiling.
Guannan Ren(6)
[PATCH 1/6] conf: declare usb spec and port number enum for usb
[PATCH 2/6] conf: store usb spec and nports info when parsing usb
[PATCH 3/6] qemu: add usb-uas caps flag
[PATCH 4/6] qemu: add usb scsi controller support
[PATCH 5/6] qemu: add usb-scsi controller checking when building
[PATCH 6/6] test: add qemuxml2argv disk-scsi-uas testcase
docs/formatdomain.html.in | 25 +++++-
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 213 ++++++++++++++++++++++++++++++++++++++------
src/conf/domain_conf.h | 25 +++++-
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 41 +++++++--
src/vmx/vmx.c | 3 +-
tests/qemuhelptest.c | 6 +-
tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-uas.args | 10 +++
tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-uas.xml | 34 +++++++
tests/qemuxml2argvtest.c | 3 +
12 files changed, 326 insertions(+), 38 deletions(-)
12 years, 4 months
[libvirt] libvirt boolean type
by Claudio Bley
Hi.
The following patch's intend is to get a discussion started first.
Rationale:
Many functions in libvirt return "1 for <TRUE>, 0 for <FALSE> and -1
on <ERROR>".
When calling a function you need to read the documentation, skipping
to the "Returns:" text in order to determine what return values to
expect from the function and how to interpret them.
This is cumbersome and takes an extra step which could be avoided.
Advantages:
+ enum is binary compatible with int, so no ABI changes
+ without reading the documentation, you see what return values to expect
at a glance
+ code generators in higher level languages could use it to generate proper
wrappings to "boolean" automatically
+ compilers can probably warn when returning a value not part of the enum
Claudio Bley (1):
Implement a virBool type
include/libvirt/libvirt.h.in | 25 +++++++++++++++++++++----
python/generator.py | 16 ++++++++++++++++
src/libvirt.c | 8 ++++----
3 files changed, 41 insertions(+), 8 deletions(-)
--
1.7.9.5
12 years, 4 months
