[libvirt] : [Bug 993411] Compilation fails on lxc/lxc_monitor_protocol.c 31: undefined reference to xdr_uinit64_t
by Gerald Palmer
suggested patch for compilation issue.
--- lxc_monitor_protocol.h 2013-08-05 20:22:23.963000000 +0000
+++ libvirt-1.1.1/src/lxc/lxc_monitor_protocol.h 2013-08-05 20:22:46.226000000 +0000
@@ -5,6 +5,8 @@
#ifndef _LXC_MONITOR_PROTOCOL_H_RPCGEN
#define _LXC_MONITOR_PROTOCOL_H_RPCGEN
+# define xdr_uint64_t xdr_u_int64_t
+
#include <rpc/rpc.h>
-----Original Message-----
From: bugzilla(a)redhat.com [mailto:bugzilla@redhat.com]
Sent: Monday, August 05, 2013 4:15 PM
To: Gerald Palmer
Subject: [Bug 993411] Compilation fails on lxc/lxc_monitor_protocol.c 31: undefined reference to xdr_uinit64_t
https://bugzilla.redhat.com/show_bug.cgi?id=993411
Eric Blake <eblake(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eblake(a)redhat.com,
| |gpalmer(a)lganet.com
Flags| |needinfo?(gpalmer(a)lganet.co
| |m)
--- Comment #1 from Eric Blake <eblake(a)redhat.com> --- Can you please post this patch upstream at libvir-list(a)redhat.com for discussion?
--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.
11 years, 3 months
[libvirt] [PATCH] qemu_migration: Don't error on tunelled migration with --copy-storage
by Michal Privoznik
https://bugzilla.redhat.com/show_bug.cgi?id=979477
Since 1.0.3 we are using the new way to copy non shared storage during
migration (the NBD way). However, whether the new or old way is used is
not controllable by user but unconditionally turned on if both sides of
migration support it. Moreover, the implementation is not complete: the
combination for VIR_MIGRATE_TUNNELLED flag is missing (as we need to
open new port on the destination) in which case we just error out. This
is deadly combination: not letting users choose their destiny and
erroring out. We should not do that but VIR_WARN and turn the NBD off
instead.
---
Probably worth backporting to v1.0.3+ maint branches too.
src/qemu/qemu_migration.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 3dedfe8..b905459 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1994,16 +1994,15 @@ static char
if (flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC) &&
virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_NBD_SERVER)) {
/* TODO support NBD for TUNNELLED migration */
if (flags & VIR_MIGRATE_TUNNELLED) {
- virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
- _("NBD in tunnelled migration is currently not supported"));
- goto cleanup;
+ VIR_WARN("NBD in tunnelled migration is currently not supported");
+ } else {
+ cookieFlags |= QEMU_MIGRATION_COOKIE_NBD;
+ priv->nbdPort = 0;
}
- cookieFlags |= QEMU_MIGRATION_COOKIE_NBD;
- priv->nbdPort = 0;
}
if (!(mig = qemuMigrationEatCookie(driver, vm, NULL, 0, 0)))
goto cleanup;
--
1.8.1.5
11 years, 3 months
[libvirt] virsh [attach-detach]-device question
by Scott Sullivan
I have noticed a behavior I am hoping someone can help me understand.
Consider the following scenario:
1.) Start a test dummy qemu-kvm instance with no OS via virsh named "no_os".
2.) Attach a device to it;
[root@host ~]# virsh attach-device no_os /root/hotplug_device_b.xml
Device attached successfully
[root@host ~]#
3.) Now detach the same device;
[root@host ~]# virsh detach-device no_os /root/hotplug_device_b.xml
Device detached successfully
[root@host ~]#
4.) Now re-attach the same device;
[root@host ~]# virsh attach-device no_os /root/hotplug_device_b.xml
error: Failed to attach device from /root/hotplug_device_b.xml
error: internal error unable to execute QEMU command 'device_add':
Duplicate ID 'virtio-disk1' for device
[root@host ~]#
Is this expected behavior? If so, why does my detach-device call in step
3 appear to not free the device, leading to the duplicate ID error in
step 4?
Libvirt XML's used:
/root/hotplug_device_b.xml:
<disk type='block' device='disk'>
<driver name='qemu' cache='none'/>
<source dev="/dev/syseng/hotplug_test_b"/>
<target dev="vdb" bus="virtio"/>
</disk>
I started the "no_os" instance with this:
<domain type="kvm">
<name>no_os</name>
<uuid>E605BE96-6BC9-11E2-976C-EDA8DB8AEF42</uuid>
<memory>524288</memory>
<currentMemory>524288</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch="x86_64" machine="pc-1.1">hvm</type>
<boot dev="hd"/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset="utc"/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/opt/kvm-stack-1/libexec/qemu-kvm-wrapper</emulator>
<disk type="block" device="disk">
<driver name="qemu" cache="none"/>
<source dev="/dev/LVM/no_os"/>
<target dev="vda" bus="virtio"/>
</disk>
<disk type="file" device="cdrom">
<target dev="hdc" bus="ide"/>
<readonly/>
</disk>
<serial type="pty">
<target port="0"/>
</serial>
<console type="pty">
<target port="0"/>
</console>
<input type="mouse" bus="ps2"/>
<graphics type="vnc" port="-1" autoport="yes" keymap="en-us"/>
<interface type="bridge">
<mac address="52:54:00:87:14:3d"/>
<source bridge="virbr0"/>
<target dev="no_os_0"/>
<model type="virtio"/>
</interface></devices>
</domain>
11 years, 3 months
[libvirt] [PATCH] build: fix missing max_queued_clients in augeas test file for libvirtd.conf
by Laine Stump
Broken in commit 1199edb1d4e3ebbc691bd32d3519a3b662225420
---
Pushed under build-breaker rule.
daemon/test_libvirtd.aug.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/daemon/test_libvirtd.aug.in b/daemon/test_libvirtd.aug.in
index 4e3b878..a7e8515 100644
--- a/daemon/test_libvirtd.aug.in
+++ b/daemon/test_libvirtd.aug.in
@@ -35,6 +35,7 @@ module Test_libvirtd =
{ "2" = "fred(a)EXAMPLE.COM" }
}
{ "max_clients" = "20" }
+ { "max_queued_clients" = "1000" }
{ "min_workers" = "5" }
{ "max_workers" = "20" }
{ "prio_workers" = "5" }
--
1.7.11.7
11 years, 3 months
[libvirt] [PATCHv2 0/7] Q35 support part 2 - RESEND with a few small changes
by Laine Stump
This obsoletes patches 3/7-10/7 of the previous posting of Q35 part
2. The first 3 patches had been ACKed so I pushed those, so patch 1/7
of this series was 3/7 of the v1.
Most of the changes to patches 1-4 are small nits that I neglected to
keep track of (e.g. fixing make check when run as each patch is
applied, and changing the commandline args slightly as I figured out
issues once I could actually start up and run a domain.
The issue with pci.0 vs. pcie.0 has been fixed in this new series. As
indicated in my latest response to the previous series, with the 3 new
additional patches everything seems to work.
A default USB controller is still not added for Q35 machines
domains. domains that are created now will continue to be compatible
once we decide what type of default USB controller to add though (if
we do decide to do that).
At this point I am declaring the Q35 support in libvirt
"usable". Until some tweaks are made to virt-manager, it won't be
possible to create a new q35 domain with virt-manager though.
Laine Stump (7):
qemu: enable auto-allocate of all PCI addresses
qemu: add pcie-root controller
qemu: add dmi-to-pci-bridge controller
qemu: fix handling of default/implicit devices for q35
qemu: properly set/use device alias for pci controllers
qemu: use standard pci-bridge in place of i82801b11-bridge
qemu: enable using implicit sata controller in q35 machines
docs/formatdomain.html.in | 43 +-
docs/schemas/domaincommon.rng | 2 +
src/conf/domain_conf.c | 11 +-
src/conf/domain_conf.h | 2 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 517 +++++++++++++++++----
src/qemu/qemu_command.h | 32 +-
src/qemu/qemu_domain.c | 36 +-
src/qemu/qemu_hotplug.c | 6 +-
tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args | 5 +
tests/qemuxml2argvdata/qemuxml2argv-pcie-root.xml | 20 +
tests/qemuxml2argvdata/qemuxml2argv-q35.args | 8 +
tests/qemuxml2argvdata/qemuxml2argv-q35.xml | 30 ++
tests/qemuxml2argvtest.c | 10 +
.../qemuxml2xmlout-pcie-root.xml | 23 +
tests/qemuxml2xmloutdata/qemuxml2xmlout-q35.xml | 31 ++
tests/qemuxml2xmltest.c | 2 +
18 files changed, 675 insertions(+), 106 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-root.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35.xml
--
1.7.11.7
11 years, 3 months
[libvirt] [PATCH 0/7] Q35 support part 2
by Laine Stump
This series adds everything needed to create and start a Q35 machine
from libvirt, with a couple of small exceptions:
1) Although the implicit pcie-root controller on q35 machinetypes is
referred to as "pcie.0" by qemu, the code as it stands now still puts
"pci.0" on the commandline, which means it's still unusable. I'm
working on a patch to fix that right now.
2) The q35 machinetype doesn't create a default usb controller as the
other machinetypes do. The reason for that is explained in Patch
7/7. I think we probably *should* have a default usb controller added
for q35 (just to make creating a new machine config easier), but it
probably should be a usb2 "trifecta" of controllers, rather than an
old-fashioned usb1 piix3 controller.
With (1) fixed, this should be enough functionality that people can
start testing q35 guests via libvirt.
Laine Stump (7):
conf: add default USB controller in qemu post-parse callback
qemu: rename some functions in qemu_command.c
qemu: eliminate almost-duplicate code in qemu_command.c
qemu: enable auto-allocate of all PCI addresses
qemu: add pcie-root controller
qemu: add dmi-to-pci-bridge controller
qemu: fix handling of default/implicit devices for q35
docs/formatdomain.html.in | 43 +-
docs/schemas/domaincommon.rng | 2 +
src/conf/domain_conf.c | 17 +-
src/conf/domain_conf.h | 2 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 619 +++++++++++++++------
src/qemu/qemu_command.h | 14 +-
src/qemu/qemu_domain.c | 48 +-
tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args | 5 +
tests/qemuxml2argvdata/qemuxml2argv-pcie-root.xml | 20 +
tests/qemuxml2argvdata/qemuxml2argv-q35.args | 6 +
tests/qemuxml2argvdata/qemuxml2argv-q35.xml | 25 +
tests/qemuxml2argvtest.c | 10 +
.../qemuxml2xmlout-pcie-root.xml | 23 +
tests/qemuxml2xmloutdata/qemuxml2xmlout-q35.xml | 26 +
tests/qemuxml2xmltest.c | 2 +
17 files changed, 673 insertions(+), 192 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-root.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35.xml
--
1.7.11.7
11 years, 3 months
Re: [libvirt] [Qemu-devel] default slot used for vga device on q35 machines
by Laine Stump
On 08/02/2013 02:49 AM, Gerd Hoffmann wrote:
> Hi,
>
>> qemu-kvm -M q35 -nodefaults -nodefconfig -qmp unix:/tmp/qemu,server
>> -vnc :15 -vga std -usb
>>
>> Then ran "query-pci" in the qmp monitor and found that the vga device is
>> put at slot 1 instead of slot 2.
>>
>> My questions:
>>
>> 1) Is this difference intentional, or a bug?
> The vga simply goes into the first free slot. That happens to be #2
> with i440fx and #1 with q35.
It sounds like it's a safe bet to assume that -vga will put the device
on slot 2 for pc machinetypes and slot 1 for q35, no matter what other
devices there are, since -vga is always initialized first. Correct? Do
you see any chance that might change in the future? (e.g. due to some
other new device that needs to be initialized even before vga)
>
>> 2) If it's intentional, will the device always be at slot 1 (and trigger
>> an error if something else is also placed at slot 1), or is it just
>> picking the first unused slot? (that would *not* be good, because we
>> must be able to predict what device is in which slot and prevent them
>> from changing from run to run).
> The vga is the very first (pci) device being created (when selecting via
> -vga), so it gets the slots mentioned above no matter what, even though
> simply picking the first unused slot.
>
>> 3) Does the qxl multihead support really require that the device be at
>> slot 2 (as stated in the above bugzilla commend)? Or is that just a
>> misunderstanding/overstatement?
> It's not required at all. The problem is that on older qemu versions
> (pre-memory-api basically) it was impossible to create functional vga
> devices via -device due to an initialization order issue. Which implies
> you have to use -vga instead, which in turn implies the vga ends up in
> slot #2. On i440fx, but q35 didn't exist yet back then ;)
Are you saying that it's still required to use -vga instead of -device
qxl-vga for pc machinetype? Or that it was needed at one time, but that
is no longer the case? If the latter, is there a reliable way to make
the decision whether or not we need to use -vga?
11 years, 3 months
Re: [libvirt] [libvirt-users] Please remove pm-utils dep from libvirt-clients
by Daniel P. Berrange
On Sat, Aug 03, 2013 at 03:41:35PM +0100, Richard Hughes wrote:
> Hi,
>
> I'm going to be retiring pm-utils from Fedora soon; it's completely
> dead upstream and it not needed anymore by upower or anything else.
> Nothing other than libvirt-clients depends on it, so when I tried to
> remove this from rawhide I noticed this commit:
>
> commit 7069f75cb8dad58715f723fd542e4ff69dbff51b
> Author: Daniel Veillard <veillard(a)redhat.com>
> Date: Thu Dec 8 17:03:16 2011 +0800
>
> update to libvirt-0.9.8
>
> added:
>
> +# Needed for probing the power management features of the host.
> +Requires: pm-utils
>
> Is this true? You really don't want to be parsing pm-is-supported, it
> often doesn't work and isn't used by anything else any more. Would it
> be possible to port away from pm-is-supported if you're actually using
> it, and drop the dep for F20 please? Any questions please CC me as I'm
> not subscribed.
What is the replacement ? We need to be able to query whether
each of suspend, hibernate, or suspend-hybrid are supported on
a host, and then report that upto the mgmt app using libvirt.
Daniel
11 years, 3 months
[libvirt] [PATCH] Fix build w/o cgroups
by Roman Bogorodskiy
Build without cgroups support started to fail again recently. Do the
following to fix it:
- Add missing 'partition' arg that was added to the
virCgroupValidateMachineGroup() but forgotten for the stub
of the same function
- Add stubs for virCgroupMakeGroup() and virCgroupNew()
---
src/util/vircgroup.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c
index cfb4b3f..4cc7687 100644
--- a/src/util/vircgroup.c
+++ b/src/util/vircgroup.c
@@ -174,6 +174,7 @@ static bool
virCgroupValidateMachineGroup(virCgroupPtr group ATTRIBUTE_UNUSED,
const char *name ATTRIBUTE_UNUSED,
const char *drivername ATTRIBUTE_UNUSED,
+ const char *partition ATTRIBUTE_UNUSED,
bool stripEmulatorSuffix ATTRIBUTE_UNUSED)
{
return true;
@@ -993,6 +994,23 @@ error:
return -1;
}
+#else
+static int virCgroupMakeGroup(virCgroupPtr parent ATTRIBUTE_UNUSED,
+ virCgroupPtr group ATTRIBUTE_UNUSED,
+ bool create ATTRIBUTE_UNUSED,
+ unsigned int flags ATTRIBUTE_UNUSED)
+{
+ return -1;
+}
+
+static int virCgroupNew(pid_t pid ATTRIBUTE_UNUSED,
+ const char *path ATTRIBUTE_UNUSED,
+ virCgroupPtr parent ATTRIBUTE_UNUSED,
+ int controllers ATTRIBUTE_UNUSED,
+ virCgroupPtr *group ATTRIBUTE_UNUSED)
+{
+ return -1;
+}
#endif
#if defined _DIRENT_HAVE_D_TYPE
--
1.7.11.5
11 years, 3 months
[libvirt] [PATCH 0/9] qemu: Support qemu-system-arm vexpress-a9
by Cole Robinson
This series adds the bits needed to kick of a qemu-system-arm -machine
vexpress-a9 guest.
Patches 1 and 8 are isolated bug fixes
Patches 2-5 and 7 are mostly about fixing CLI generation. Unfortunately
qemu ARM boards don't quite work like x86 where we can mix and match
devices, so -device is out of the picture, and the boards depend on
old CLI infrastrucure like -net nic and -serial.
Patch 6 adds disk bus=sd, which is often the only way to specify storage
for ARM boards.
Patch 9 adds virtio-mmio address support, which enables virtio
for vexpress-a9.
Cole Robinson (9):
qemu_command: Drop incorrect ATTRIBUTE_UNUSED annotation
domain_conf: Set QEMU ARM default USB model to 'none'
domain_conf: Don't add default memballoon device on ARM
qemu: Fix adding specifying char devs for ARM
qemu: Don't try to allocate PCI addresses for ARM
domain_conf: Add disk bus=sd, wire it up for qemu
qemu: Fix networking for ARM guests
qemu: Only setup vhost if virtType == "kvm"
qemu: Support virtio-mmio transport for virtio on ARM
docs/formatdomain.html.in | 3 +-
docs/schemas/domaincommon.rng | 20 ++++
src/conf/domain_conf.c | 72 +++++++++---
src/conf/domain_conf.h | 2 +
src/qemu/qemu_capabilities.c | 22 ++++
src/qemu/qemu_capabilities.h | 5 +
src/qemu/qemu_command.c | 126 +++++++++++++++++----
src/qemu/qemu_domain.c | 20 +++-
src/qemu/qemu_process.c | 37 +++---
.../qemuxml2argv-arm-vexpressa9-basic.args | 1 +
.../qemuxml2argv-arm-vexpressa9-basic.xml | 34 ++++++
.../qemuxml2argv-arm-vexpressa9-nodevs.args | 1 +
.../qemuxml2argv-arm-vexpressa9-nodevs.xml | 26 +++++
.../qemuxml2argv-arm-vexpressa9-virtio.args | 1 +
.../qemuxml2argv-arm-vexpressa9-virtio.xml | 45 ++++++++
tests/qemuxml2argvtest.c | 10 ++
tests/testutilsqemu.c | 32 ++++++
17 files changed, 397 insertions(+), 60 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-arm-vexpressa9-basic.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-arm-vexpressa9-basic.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-arm-vexpressa9-nodevs.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-arm-vexpressa9-nodevs.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-arm-vexpressa9-virtio.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-arm-vexpressa9-virtio.xml
--
1.8.3.1
11 years, 3 months