August 2013 - Devel - libvirt List Archives

[libvirt] [PATCH] xen: Use internal interfaces in xenDomainUsedCpus
by Stefan Bader 07 Aug '13

07 Aug '13

Based on Daniel's feedback I did a split for public/private functions for those that cause the lockup when getting XML. Maybe not complete but at least seems to allow basic usage again (through virt-manager). -Stefan --- >From f406c6891fb92a45dc5d5a4d794c5d667965d096 Mon Sep 17 00:00:00 2001 From: Stefan Bader <stefan.bader(a)canonical.com> Date: Mon, 15 Jul 2013 16:03:58 +0200 Subject: [PATCH] xen: Use internal interfaces in xenDomainUsedCpus Since commit 95e18efd most public interfaces (xenUnified...) obtain a virDomainDefPtr via xenGetDomainDefFor...() which take the unified lock. This is already taken before calling xenDomainUsedCpus(), so we get a deadlock for active guests. Avoid this by splitting up xenUnifiedDomainGetVcpusFlags() and xenUnifiedDomainGetVcpus() into public and private function calls (which get the virDomainDefPtr passed) and use those in xenDomainUsedCpus(). xenDomainUsedCpus ... nb_vcpu = xenUnifiedDomainGetMaxVcpus(dom); return xenUnifiedDomainGetVcpusFlags(...) ... if (!(def = xenGetDomainDefForDom(dom))) return xenGetDomainDefForUUID(dom->conn, dom->uuid); ... ret = xenHypervisorLookupDomainByUUID(conn, uuid); ... xenUnifiedLock(priv); name = xenStoreDomainGetName(conn, id); xenUnifiedUnlock(priv); ... if ((ncpus = xenUnifiedDomainGetVcpus(dom, cpuinfo, nb_vcpu, ... if (!(def = xenGetDomainDefForDom(dom))) [again like above] Signed-off-by: Stefan Bader <stefan.bader(a)canonical.com> --- src/xen/xen_driver.c | 94 +++++++++++++++++++++++++++++++++----------------- src/xen/xen_driver.h | 2 +- 2 files changed, 64 insertions(+), 32 deletions(-) diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c index 39334b7..9ae728e 100644 --- a/src/xen/xen_driver.c +++ b/src/xen/xen_driver.c @@ -73,12 +73,14 @@ static int xenUnifiedNodeGetInfo(virConnectPtr conn, virNodeInfoPtr info); + static int -xenUnifiedDomainGetMaxVcpus(virDomainPtr dom); +__xenUnifiedDomainGetVcpusFlags(virDomainPtr dom, virDomainDefPtr def, + unsigned int flags); static int -xenUnifiedDomainGetVcpus(virDomainPtr dom, - virVcpuInfoPtr info, int maxinfo, - unsigned char *cpumaps, int maplen); +__xenUnifiedDomainGetVcpus(virDomainPtr dom, virDomainDefPtr def, + virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen); static bool is_privileged = false; @@ -173,6 +175,7 @@ xenNumaInit(virConnectPtr conn) { /** * xenDomainUsedCpus: * @dom: the domain + * @def: the domain definition * * Analyze which set of CPUs are used by the domain and * return a string providing the ranges. @@ -181,7 +184,7 @@ xenNumaInit(virConnectPtr conn) { * NULL if the domain uses all CPU or in case of error. */ char * -xenDomainUsedCpus(virDomainPtr dom) +xenDomainUsedCpus(virDomainPtr dom, virDomainDefPtr def) { char *res = NULL; int ncpus; @@ -202,9 +205,14 @@ xenDomainUsedCpus(virDomainPtr dom) if (priv->nbNodeCpus <= 0) return NULL; - nb_vcpu = xenUnifiedDomainGetMaxVcpus(dom); + nb_vcpu = __xenUnifiedDomainGetVcpusFlags(dom, def, + (VIR_DOMAIN_VCPU_LIVE | + VIR_DOMAIN_VCPU_MAXIMUM)); if (nb_vcpu <= 0) return NULL; + /* FIXME: To be consistent this should map to an internal interface, too. + * Currently it actually does map straight to xenDaemonNodeGetInfo(). + */ if (xenUnifiedNodeGetInfo(dom->conn, &nodeinfo) < 0) return NULL; @@ -217,8 +225,8 @@ xenDomainUsedCpus(virDomainPtr dom) VIR_ALLOC_N(cpumap, nb_vcpu * cpumaplen) < 0) goto done; - if ((ncpus = xenUnifiedDomainGetVcpus(dom, cpuinfo, nb_vcpu, - cpumap, cpumaplen)) >= 0) { + if ((ncpus = __xenUnifiedDomainGetVcpus(dom, def, cpuinfo, nb_vcpu, + cpumap, cpumaplen)) >= 0) { for (n = 0; n < ncpus; n++) { for (m = 0; m < priv->nbNodeCpus; m++) { bool used; @@ -1410,54 +1418,57 @@ cleanup: } static int -xenUnifiedDomainGetVcpus(virDomainPtr dom, - virVcpuInfoPtr info, int maxinfo, - unsigned char *cpumaps, int maplen) +__xenUnifiedDomainGetVcpus(virDomainPtr dom, virDomainDefPtr def, + virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) { xenUnifiedPrivatePtr priv = dom->conn->privateData; - virDomainDefPtr def = NULL; int ret = -1; - if (!(def = xenGetDomainDefForDom(dom))) - goto cleanup; - - if (virDomainGetVcpusEnsureACL(dom->conn, def) < 0) - goto cleanup; - if (dom->id < 0) { if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Cannot get VCPUs of inactive domain")); - goto cleanup; } else { - ret = xenDaemonDomainGetVcpus(dom->conn, def, info, maxinfo, cpumaps, maplen); + ret = xenDaemonDomainGetVcpus(dom->conn, def, info, maxinfo, + cpumaps, maplen); } } else { - ret = xenHypervisorGetVcpus(dom->conn, def, info, maxinfo, cpumaps, maplen); + ret = xenHypervisorGetVcpus(dom->conn, def, info, maxinfo, cpumaps, + maplen); } -cleanup: - virDomainDefFree(def); return ret; } static int -xenUnifiedDomainGetVcpusFlags(virDomainPtr dom, unsigned int flags) +xenUnifiedDomainGetVcpus(virDomainPtr dom, + virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) { - xenUnifiedPrivatePtr priv = dom->conn->privateData; virDomainDefPtr def = NULL; int ret = -1; - virCheckFlags(VIR_DOMAIN_VCPU_LIVE | - VIR_DOMAIN_VCPU_CONFIG | - VIR_DOMAIN_VCPU_MAXIMUM, -1); - if (!(def = xenGetDomainDefForDom(dom))) goto cleanup; - if (virDomainGetVcpusFlagsEnsureACL(dom->conn, def) < 0) + if (virDomainGetVcpusEnsureACL(dom->conn, def) < 0) goto cleanup; + ret = __xenUnifiedDomainGetVcpus(dom, def, info, maxinfo, cpumaps, maplen); + +cleanup: + virDomainDefFree(def); + return ret; +} + +static int +__xenUnifiedDomainGetVcpusFlags(virDomainPtr dom, virDomainDefPtr def, + unsigned int flags) +{ + xenUnifiedPrivatePtr priv = dom->conn->privateData; + int ret = -1; + if (dom->id < 0) { if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) ret = xenXMDomainGetVcpusFlags(dom->conn, def, flags); @@ -1470,6 +1481,27 @@ xenUnifiedDomainGetVcpusFlags(virDomainPtr dom, unsigned int flags) ret = xenDaemonDomainGetVcpusFlags(dom->conn, def, flags); } + return ret; +} + +static int +xenUnifiedDomainGetVcpusFlags(virDomainPtr dom, unsigned int flags) +{ + virDomainDefPtr def = NULL; + int ret = -1; + + virCheckFlags(VIR_DOMAIN_VCPU_LIVE | + VIR_DOMAIN_VCPU_CONFIG | + VIR_DOMAIN_VCPU_MAXIMUM, -1); + + if (!(def = xenGetDomainDefForDom(dom))) + goto cleanup; + + if (virDomainGetVcpusFlagsEnsureACL(dom->conn, def) < 0) + goto cleanup; + + ret = __xenUnifiedDomainGetVcpusFlags(dom, def, flags); + cleanup: virDomainDefFree(def); return ret; @@ -1501,7 +1533,7 @@ xenUnifiedDomainGetXMLDesc(virDomainPtr dom, unsigned int flags) } else { char *cpus; xenUnifiedLock(priv); - cpus = xenDomainUsedCpus(dom); + cpus = xenDomainUsedCpus(dom, def); xenUnifiedUnlock(priv); def = xenDaemonDomainGetXMLDesc(dom->conn, minidef, cpus); VIR_FREE(cpus); diff --git a/src/xen/xen_driver.h b/src/xen/xen_driver.h index 3c7a8cd..a363161 100644 --- a/src/xen/xen_driver.h +++ b/src/xen/xen_driver.h @@ -187,7 +187,7 @@ struct _xenUnifiedPrivate { typedef struct _xenUnifiedPrivate *xenUnifiedPrivatePtr; -char *xenDomainUsedCpus(virDomainPtr dom); +char *xenDomainUsedCpus(virDomainPtr dom, virDomainDefPtr def); virDomainXMLOptionPtr xenDomainXMLConfInit(void); -- 1.7.9.5

2 4

[libvirt] [TCK][PATCH] nwfilter: convert ctstate to state
by Stefan Berger 07 Aug '13

07 Aug '13

iptables version 1.4.16 and later automatically convert -m state --state ... to -m conntrack --ctstate ... In the test cases we will then only see 'ctstate' and convert that back to the older 'state' before comparing actual against expected output. Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- scripts/nwfilter/nwfilter2vmtest.sh | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) Index: libvirt-tck/scripts/nwfilter/nwfilter2vmtest.sh =================================================================== --- libvirt-tck.orig/scripts/nwfilter/nwfilter2vmtest.sh +++ libvirt-tck/scripts/nwfilter/nwfilter2vmtest.sh @@ -32,6 +32,9 @@ FLAG_FORCE_CLEAN="$((1<<5))" # netfilter at some point. We probe for it. IPTABLES_CTRDIR_CORRECTED=0 +# starting with iptables v1.4.16 -m state becomes -m ctstate +IPTABLES_USE_CTSTATE=0 + failctr=0 passctr=0 attachfailctr=0 @@ -114,6 +117,16 @@ probeIptablesCtdir() { fi } +probeIptablesCtstate() { + rev=$(iptables --version | \ + sed -n 's/.*v$[[:digit:]].$/\1/p' | + gawk -F. '{print $1 * 1000000 + $2 * 1000 + $3 }') + # 1.4.16 or later uses ctstate + if [ $rev -ge 1004016 ]; then + IPTABLES_USE_CTSTATE=1 + fi +} + checkExpectedOutput() { xmlfile="$1" fwallfile="$2" @@ -181,6 +194,11 @@ checkExpectedOutput() { sed -i "s/ctdir _REPLY/ctdir REPLY/" ${tmpfile} fi + if [ $IPTABLES_USE_CTSTATE -ne 0 ]; then + #change ctstate tback o state + sed -i "s/ctstate/state/" ${tmpfile} + fi + diff -w ${tmpfile} ${tmpfile2} >/dev/null if [ $? -ne 0 ]; then @@ -574,6 +592,7 @@ main() { exit 1; else probeIptablesCtdir + probeIptablesCtstate fi if [ $(($flags & $FLAG_TAP_TEST)) -ne 0 ]; then

2 2

[libvirt] : [Bug 993411] Compilation fails on lxc/lxc_monitor_protocol.c 31: undefined reference to xdr_uinit64_t
by Gerald Palmer 06 Aug '13

06 Aug '13

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.

3 3

[libvirt] [PATCH] qemu_migration: Don't error on tunelled migration with --copy-storage
by Michal Privoznik 06 Aug '13

06 Aug '13

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

3 2

[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