- Devel - libvirt List Archives

[libvirt] virsh [attach-detach]-device question
by Scott Sullivan 06 Aug '13

06 Aug '13

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>

1 1

[libvirt] [PATCH] build: fix missing max_queued_clients in augeas test file for libvirtd.conf
by Laine Stump 06 Aug '13

06 Aug '13

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

1 0

[libvirt] [PATCHv2 0/7] Q35 support part 2 - RESEND with a few small changes
by Laine Stump 06 Aug '13

06 Aug '13

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

3 22

[libvirt] [PATCH 0/7] Q35 support part 2
by Laine Stump 06 Aug '13

06 Aug '13

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

4 35

Re: [libvirt] [Qemu-devel] default slot used for vga device on q35 machines
by Laine Stump 06 Aug '13

06 Aug '13

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?

3 2

Re: [libvirt] [libvirt-users] Please remove pm-utils dep from libvirt-clients
by Daniel P. Berrange 05 Aug '13

05 Aug '13

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

3 8

[libvirt] [PATCH] Fix build w/o cgroups
by Roman Bogorodskiy 04 Aug '13

04 Aug '13

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

2 3

[libvirt] [PATCH 0/9] qemu: Support qemu-system-arm vexpress-a9
by Cole Robinson 04 Aug '13

04 Aug '13

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

4 22

[libvirt] infinite loop while restarting libvirt after LXC creation
by Michael R. Hines 03 Aug '13

03 Aug '13

Hi, I'm using OpenStack grizzly on Ubuntu 12.04 to create LXC containers. After successful container creation and a subsequent reboot of the hypervisor, libvirt gets stuck in an infinite loop, spinning at 100% Here's the backtrace: (gdb) thread 12 [Switching to thread 12 (Thread 0x7fffee46f700 (LWP 7052))] #0 0x00007ffff7617de1 in virDomainDefMaybeAddController (def=0x7fffe8033b30, type=2, idx=73405, model=-1) at conf/domain_conf.c:10570 warning: Source file is more recent than executable. 10570 for (i = 0; i < def->ncontrollers; i++) { (gdb) bt #0 0x00007ffff7617de1 in virDomainDefMaybeAddController (def=0x7fffe8033b30, type=2, idx=73405, model=-1) at conf/domain_conf.c:10570 #1 0x00007ffff76180ab in virDomainDefAddDiskControllersForType (def=0x7fffe8033b30, controllerType=2, diskBus=<optimized out>) at conf/domain_conf.c:13653 #2 0x00007ffff761a11d in virDomainDefAddImplicitControllers (def=0x7fffe8033b30) at conf/domain_conf.c:13747 #3 0x00007ffff7623a29 in virDomainDefParseXML (xml=0x7fffe8034500, root=0x7fffe802fc60, ctxt=<optimized out>, caps=0x7fffe8030f20, xmlopt=0x7fffe8031a60, expectedVirtTypes=<optimized out>, flags=2) at conf/domain_conf.c:12375 #4 0x00007ffff76299a0 in virDomainDefParseNode (xml=0x7fffe8034500, root=0x7fffe802fc60, caps=0x7fffe8030f20, xmlopt=0x7fffe8031a60, expectedVirtTypes=16, flags=2) at conf/domain_conf.c:12562 #5 0x00007ffff7629b19 in virDomainDefParse (xmlStr=<optimized out>, filename=<optimized out>, caps=0x7fffe8030f20, xmlopt=0x7fffe8031a60, expectedVirtTypes=16, flags=2) at conf/domain_conf.c:12504 #6 0x00007ffff762a489 in virDomainObjListLoadConfig (opaque=0x0, notify=0, expectedVirtTypes=16, name=0x7fffe80fb543 "instance-00000017", autostartDir=0x7fffe8033280 "/etc/libvirt/lxc/autostart", configDir=0x7fffe8033b10 "/etc/libvirt/lxc", xmlopt=0x7fffe8031a60, caps=0x7fffe8030f20, doms=0x7fffe80fac40) at conf/domain_conf.c:17027 #7 virDomainObjListLoadAllConfigs (doms=0x7fffe80fac40, configDir=<optimized out>, autostartDir=0x7fffe8033280 "/etc/libvirt/lxc/autostart", liveStatus=<optimized out>, caps=0x7fffe8030f20, xmlopt=0x7fffe8031a60, expectedVirtTypes=16, notify=0, opaque=0x0) at conf/domain_conf.c:17155 #8 0x00007fffef1def58 in lxcStateInitialize (privileged=<optimized out>, callback=<optimized out>, opaque=<optimized out>) at lxc/lxc_driver.c:1449 #9 lxcStateInitialize (privileged=<optimized out>, callback=<optimized out>, opaque=<optimized out>) at lxc/lxc_driver.c:1361 #10 0x00007ffff766df12 in virStateInitialize (privileged=true, callback=0x555555568110 <daemonInhibitCallback>, opaque=0x5555557cc8e0) at libvirt.c:832 #11 0x00005555555681c0 in daemonRunStateInit (opaque=<optimized out>) at libvirtd.c:902 #12 0x00007ffff75f0ae6 in virThreadHelper (data=<optimized out>) at util/virthreadpthread.c:161 #13 0x00007ffff733ee9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #14 0x00007ffff706bccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) next

1 1

[libvirt] Patch set to add virt-sandbox -s inherit and fixes for man pages.
by Daniel J Walsh 03 Aug '13

03 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 for some reason my git-sendmail keeps failing. [sandbox PATCH 1/3] Add virt-sandbox -s inherit, to execute the [sandbox PATCH 2/3] Add comment about LIBVIRT_DEFAULT_URI to [sandbox PATCH 3/3] virt-sandbox-service.pod did not mention upgrade -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH7zjAACgkQrlYvE4MpobPBIQCgvOYtY0ccFTUNBNA4tWWQs02t tYwAn15nXX9WhTyG0Piw4QVYwide9/RZ =g+dS -----END PGP SIGNATURE-----

2 2