- Devel - libvirt List Archives

[libvirt] [PATCH] qemuDomainAttachNetDevice: Support attach of type="user"
by Michal Privoznik 28 Feb '17

28 Feb '17

https://bugzilla.redhat.com/show_bug.cgi?id=1420668 This has worked in previous releases. My commit c266b60440 broke it. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_hotplug.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 97fb272f6..0c0885695 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1104,6 +1104,9 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver, break; case VIR_DOMAIN_NET_TYPE_USER: + /* No preparation needed. */ + break; + case VIR_DOMAIN_NET_TYPE_SERVER: case VIR_DOMAIN_NET_TYPE_CLIENT: case VIR_DOMAIN_NET_TYPE_MCAST: -- 2.11.0

2 1

[libvirt] A question for external snapshots with flag“VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE”
by WangJie (Captain) 28 Feb '17

28 Feb '17

Hello, I got a question here. When we create consistent active external snapshots with flag “VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE” , the qemuDomainSnapshotFSFreeze will be called firstly to freeze all filesystems in vm, and then create snapshots. For windows vm, freezing filesystems used by vss service. If IO pressure in vm is too big or internal error happened in vss , freezing filesytems will failed , and qemuDomainSnapshotFSFreeze returns 0 which meaning that no filesystems are frozen. In the function qemuDomainSnapshotCreateActiveExternal, libvirt creates external snapshots all the same in such a situation that qemuDomainSnapshotFSFreeze returns 0, but the created snapshots are not consistent snapshots in such a situation . So shouldn't we abandon creating snapshots and goto cleanup in the situation that qemuDomainSnapshotFSFreeze returns 0? The code below: static int qemuDomainSnapshotCreateActiveExternal(virConnectPtr conn, virQEMUDriverPtr driver, virDomainObjPtr vm, virDomainSnapshotObjPtr snap, unsigned int flags) { virObjectEventPtr event; bool resume = false; int ret = -1; qemuDomainObjPrivatePtr priv = vm->privateData; char *xml = NULL; bool memory = snap->def->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL; bool memory_unlink = false; bool atomic = !!(flags & VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC); bool transaction = virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_TRANSACTION); int thaw = 0; /* 1 if freeze succeeded, -1 if freeze failed */ bool pmsuspended = false; virQEMUDriverConfigPtr cfg = NULL; int compressed; char *compressedpath = NULL; /* If quiesce was requested, then issue a freeze command, and a * counterpart thaw command when it is actually sent to agent. * The command will fail if the guest is paused or the guest agent * is not running, or is already quiesced. */ if (flags & VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE) { int freeze = qemuDomainSnapshotFSFreeze(driver, vm, NULL, 0); if (freeze < 0) { /* the helper reported the error */ if (freeze == -2) thaw = -1; /* the command is sent but agent failed */ goto cleanup; } thaw = 1; } ...... ......

2 2

[libvirt] [PATCH 0/4] Cache systemd presence
by Ján Tomko 28 Feb '17

28 Feb '17

Reduce the number of DBus calls required, and possibly the number of timeouts. Ján Tomko (4): Unify checking for machine1 systemd service Use macros for testing virSystemd APIs Cache the presence of machine1 service Test virSystemd APIs twice to check the cache effects src/libvirt_private.syms | 1 + src/util/virsystemd.c | 55 +++++++++++++++++++++++++++++++++++------------ src/util/virsystemdpriv.h | 33 ++++++++++++++++++++++++++++ tests/virsystemdtest.c | 40 ++++++++++++++++++---------------- 4 files changed, 96 insertions(+), 33 deletions(-) create mode 100644 src/util/virsystemdpriv.h -- 2.10.2

3 6

[libvirt] [PATCH 0/8] Converge Storage Pool vHBA logic with Node Device
by John Ferlan 28 Feb '17

28 Feb '17

Similar to the recent node device focused vHBA patches, but these focus more on adjustments to the Storage Pool vHBA logic and finally the mechanism to define a vHBA for a domain. The first patch fixes a leak found by coverity that showed up because node_device_conf had enough changes so that coverity looked harder... The second patch creates a mechanism to mock creation of the vHBA in order to test the ability for the storage pool to create a vHBA. As much as I dislike forward refs for testNodeDeviceMockCreateVport, it was better than moving all the code.... The third patch extracts out storage device mgmt into it's own set of src/util API's - similar to the existing virstoragefile, but for devices. The fourth patch was uncovered while moving code from storage_backend_scsi into node_device_conf (the fifth patch)... The fifth patch moves the createVport/deleteVport guts into the node_device_conf (although they could have moved to virvhba)... The sixth patch alters the logic to use the node_device API's as the "preferred" mechanism to create/delete the vport... The seventh patch tests the storage pool vHBA creation algorithms. The eigth patch is the reason for all this stirring of the pot. Alter the domain <controller> XML in order to allow definition of a vHBA which more or less sits between a "scsi_hostX" host device and a controller. This is in preparation for https://bugzilla.redhat.com/show_bug.cgi?id=1404962 which can take that created vHBA and automagically add the LUNs from the vHBA to the domain although that requires a bit more magic for which there are already onlist patches to let qemu driver know when a node device has been added/removed. Once all that's in place - the next step will be to converge the two sets of patches. It's a chicken/egg type problem - one has to exist before the other can truly work. John Ferlan (8): conf: Fix leak in virNodeDeviceDefParseXML tests: Add createVHBAByStoragePool-by-parent to fchosttest util: Convert virStoragePoolSourceAdapter to virStorageAdapter util: Rename virFileWaitForDevices storage: Move/rename createVport and deleteVport util: Alter virNodeDevice{Create|Delete}Vport to use nodedev APIs tests: Add more storage pool vHBA tests conf: Add vHBA controller definition to domain docs/schemas/basictypes.rng | 66 ++-- docs/schemas/domaincommon.rng | 12 +- po/POTFILES.in | 1 + src/Makefile.am | 1 + src/conf/domain_audit.c | 32 ++ src/conf/domain_conf.c | 180 ++++++++++- src/conf/domain_conf.h | 2 + src/conf/node_device_conf.c | 342 ++++++++++++++++++++- src/conf/node_device_conf.h | 9 + src/conf/storage_conf.c | 338 +++++--------------- src/conf/storage_conf.h | 35 +-- src/libvirt_private.syms | 20 +- src/libxl/libxl_conf.c | 1 + src/node_device/node_device_driver.c | 2 +- src/phyp/phyp_driver.c | 3 +- src/qemu/qemu_alias.c | 5 + src/qemu/qemu_command.c | 4 + src/qemu/qemu_hotplug.c | 16 + src/storage/storage_backend_disk.c | 6 +- src/storage/storage_backend_iscsi.c | 2 +- src/storage/storage_backend_logical.c | 4 +- src/storage/storage_backend_mpath.c | 2 +- src/storage/storage_backend_scsi.c | 267 +++------------- src/storage/storage_util.c | 2 +- src/test/test_driver.c | 101 +++++- src/util/virfile.h | 2 - src/util/virscsihost.c | 28 +- src/util/virscsihost.h | 8 +- src/util/virstoragedevice.c | 292 ++++++++++++++++++ src/util/virstoragedevice.h | 89 ++++++ src/util/virutil.c | 4 +- src/util/virutil.h | 2 + tests/fchosttest.c | 111 +++++++ .../qemuxml2argv-vhba-no-parent.xml | 38 +++ .../qemuxml2argv-vhba-parent-fabric.xml | 38 +++ .../qemuxml2argv-vhba-parent-name.xml | 38 +++ .../qemuxml2argv-vhba-parent-wwns.xml | 38 +++ .../qemuxml2xmlout-vhba-no-parent.xml | 47 +++ .../qemuxml2xmlout-vhba-parent-fabric.xml | 47 +++ .../qemuxml2xmlout-vhba-parent-name.xml | 47 +++ .../qemuxml2xmlout-vhba-parent-wwns.xml | 47 +++ tests/qemuxml2xmltest.c | 9 + 42 files changed, 1727 insertions(+), 611 deletions(-) create mode 100644 src/util/virstoragedevice.c create mode 100644 src/util/virstoragedevice.h create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vhba-no-parent.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vhba-parent-fabric.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vhba-parent-name.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vhba-parent-wwns.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vhba-no-parent.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vhba-parent-fabric.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vhba-parent-name.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vhba-parent-wwns.xml -- 2.9.3

3 24

[libvirt] [PATCH go v2] domain.go: wrong calculation of bitmask in PinVcpuFlags()
by Leonid Podolny 28 Feb '17

28 Feb '17

--- domain.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/domain.go b/domain.go index 2bd9852..7276ef8 100644 --- a/domain.go +++ b/domain.go @@ -1768,7 +1768,7 @@ func (d *Domain) PinVcpuFlags(vcpu uint, cpuMap []bool, flags DomainModification ccpumap := make([]C.uchar, maplen) for i := 0; i < len(cpuMap); i++ { if cpuMap[i] { - byte := (i + 7) / 8 + byte := i / 8 bit := i % 8 ccpumap[byte] |= (1 << uint(bit)) } -- 2.11.1

2 1

Re: [libvirt] [Qemu-devel] Question regarding Snapshots
by Stefan Hajnoczi 27 Feb '17

27 Feb '17

On Wed, Feb 22, 2017 at 03:06:41PM -0600, Tim Cusack wrote: > I have a scenario that perhaps not many have attempted, but I still hope > that it is possible. > > Scenario: > > I would like to have a Base Windows 7 VM in KVM/QEMU. > > I would follow the following process (confirmed it works) > > 1. Shutdown running domain > - virsh shutdown <Domain> > 2. Remove existing disk from Domain XML: > - virt-xml BASE --remove-device --disk target=hda > 3. Add Correct Disk image for Snapshot to Domain XML: > - virt-xml BASE --add-device --disk > /var/lib/libvirt/images/BASE.qcow2,format=qcow2,target=hda,bus=ide > 4. Create the snapshot with description > - virsh snapshot-create-as BASE <Model>.qcow2 "OEM, Model" --disk-only > --atomic > 5. Start Snapshot > - virsh start FA2BASE This process uses libvirt instead of QEMU commands. Adding libvirt mailing list. > > All that works, but my question and issue is this: > > Can you make a snapshot, then go back to the base and ignore that snapshot > like a closed branch, make another snapshot, and then go back and forth > from each to each? > > My reasons for needing this are that I have tools and software that doesnt > play nice together, and would like to keep them separated on different > snapshots, but never really need to have more than one up at a time. > > This would allow me to have only 1 windows license per computer, and the > ability to just change from tool to tool with simple front end to virsh to > remove the disk from the .xml and add the other one. > > So like this: > Tool A is on snapshot A > Tool B is on snapshot B > go through steps 1-5 above to go back and forth. > > I know that I can not merge things back into the base, but I really don't > need to do that, in fact, I can throw away the tool snapshots when new > tools come out, by making new snapshots from the base when new tools come > out. > > We have done this already, but we had an issue where the ability to write > to the snapshots seemed to stop. > > Reason unknown, everything worked one day and next could not write to any > snapshot, but could still load the base and work on it fine. > > This might be the wrong mailing list to post to, if so, could anyone point > out a more appropriate one? > > Tim

3 3

[libvirt] [PULL 10/11] i386: Implement query-cpu-model-expansion QMP command
by Eduardo Habkost 27 Feb '17

27 Feb '17

Implement query-cpu-model-expansion for target-i386. This should meet all the requirements while being simple. In the case of static expansion, it will use the new "base" CPU model, and in the case of full expansion, it will keep the original CPU model name+props, and append extra properties. A future follow-up should improve the implementation of type=full, so that it returns more detailed data, including every writable QOM property in the CPU object. Cc: libvir-list(a)redhat.com Cc: Jiri Denemark <jdenemar(a)redhat.com> Message-Id: <20170222190029.17243-3-ehabkost(a)redhat.com> Tested-by: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> --- monitor.c | 4 +- target/i386/cpu.c | 191 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 193 insertions(+), 2 deletions(-) diff --git a/monitor.c b/monitor.c index f8f4a07cfb..b68944d93c 100644 --- a/monitor.c +++ b/monitor.c @@ -984,8 +984,10 @@ static void qmp_unregister_commands_hack(void) #ifndef TARGET_ARM qmp_unregister_command("query-gic-capabilities"); #endif -#if !defined(TARGET_S390X) +#if !defined(TARGET_S390X) && !defined(TARGET_I386) qmp_unregister_command("query-cpu-model-expansion"); +#endif +#if !defined(TARGET_S390X) qmp_unregister_command("query-cpu-model-baseline"); qmp_unregister_command("query-cpu-model-comparison"); #endif diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 0a71594445..139b7ea12e 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -29,10 +29,16 @@ #include "qemu/option.h" #include "qemu/config-file.h" #include "qapi/qmp/qerror.h" +#include "qapi/qmp/qstring.h" +#include "qapi/qmp/qdict.h" +#include "qapi/qmp/qbool.h" +#include "qapi/qmp/qint.h" +#include "qapi/qmp/qfloat.h" #include "qapi-types.h" #include "qapi-visit.h" #include "qapi/visitor.h" +#include "qom/qom-qobject.h" #include "sysemu/arch_init.h" #if defined(CONFIG_KVM) @@ -2288,7 +2294,7 @@ static void x86_cpu_apply_props(X86CPU *cpu, PropValue *props) } } -/* Load data from X86CPUDefinition +/* Load data from X86CPUDefinition into a X86CPU object */ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp) { @@ -2297,6 +2303,11 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp) char host_vendor[CPUID_VENDOR_SZ + 1]; FeatureWord w; + /*NOTE: any property set by this function should be returned by + * x86_cpu_static_props(), so static expansion of + * query-cpu-model-expansion is always complete. + */ + /* CPU models only set _minimum_ values for level/xlevel: */ object_property_set_int(OBJECT(cpu), def->level, "min-level", errp); object_property_set_int(OBJECT(cpu), def->xlevel, "min-xlevel", errp); @@ -2341,6 +2352,184 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp) } +/* Return a QDict containing keys for all properties that can be included + * in static expansion of CPU models. All properties set by x86_cpu_load_def() + * must be included in the dictionary. + */ +static QDict *x86_cpu_static_props(void) +{ + FeatureWord w; + int i; + static const char *props[] = { + "min-level", + "min-xlevel", + "family", + "model", + "stepping", + "model-id", + "vendor", + "lmce", + NULL, + }; + static QDict *d; + + if (d) { + return d; + } + + d = qdict_new(); + for (i = 0; props[i]; i++) { + qdict_put_obj(d, props[i], qnull()); + } + + for (w = 0; w < FEATURE_WORDS; w++) { + FeatureWordInfo *fi = &feature_word_info[w]; + int bit; + for (bit = 0; bit < 32; bit++) { + if (!fi->feat_names[bit]) { + continue; + } + qdict_put_obj(d, fi->feat_names[bit], qnull()); + } + } + + return d; +} + +/* Add an entry to @props dict, with the value for property. */ +static void x86_cpu_expand_prop(X86CPU *cpu, QDict *props, const char *prop) +{ + QObject *value = object_property_get_qobject(OBJECT(cpu), prop, + &error_abort); + + qdict_put_obj(props, prop, value); +} + +/* Convert CPU model data from X86CPU object to a property dictionary + * that can recreate exactly the same CPU model. + */ +static void x86_cpu_to_dict(X86CPU *cpu, QDict *props) +{ + QDict *sprops = x86_cpu_static_props(); + const QDictEntry *e; + + for (e = qdict_first(sprops); e; e = qdict_next(sprops, e)) { + const char *prop = qdict_entry_key(e); + x86_cpu_expand_prop(cpu, props, prop); + } +} + +static void object_apply_props(Object *obj, QDict *props, Error **errp) +{ + const QDictEntry *prop; + Error *err = NULL; + + for (prop = qdict_first(props); prop; prop = qdict_next(props, prop)) { + object_property_set_qobject(obj, qdict_entry_value(prop), + qdict_entry_key(prop), &err); + if (err) { + break; + } + } + + error_propagate(errp, err); +} + +/* Create X86CPU object according to model+props specification */ +static X86CPU *x86_cpu_from_model(const char *model, QDict *props, Error **errp) +{ + X86CPU *xc = NULL; + X86CPUClass *xcc; + Error *err = NULL; + + xcc = X86_CPU_CLASS(cpu_class_by_name(TYPE_X86_CPU, model)); + if (xcc == NULL) { + error_setg(&err, "CPU model '%s' not found", model); + goto out; + } + + xc = X86_CPU(object_new(object_class_get_name(OBJECT_CLASS(xcc)))); + if (props) { + object_apply_props(OBJECT(xc), props, &err); + if (err) { + goto out; + } + } + + x86_cpu_expand_features(xc, &err); + if (err) { + goto out; + } + +out: + if (err) { + error_propagate(errp, err); + object_unref(OBJECT(xc)); + xc = NULL; + } + return xc; +} + +CpuModelExpansionInfo * +arch_query_cpu_model_expansion(CpuModelExpansionType type, + CpuModelInfo *model, + Error **errp) +{ + X86CPU *xc = NULL; + Error *err = NULL; + CpuModelExpansionInfo *ret = g_new0(CpuModelExpansionInfo, 1); + QDict *props = NULL; + const char *base_name; + + xc = x86_cpu_from_model(model->name, + model->has_props ? + qobject_to_qdict(model->props) : + NULL, &err); + if (err) { + goto out; + } + + + switch (type) { + case CPU_MODEL_EXPANSION_TYPE_STATIC: + /* Static expansion will be based on "base" only */ + base_name = "base"; + break; + case CPU_MODEL_EXPANSION_TYPE_FULL: + /* As we don't return every single property, full expansion needs + * to keep the original model name+props, and add extra + * properties on top of that. + */ + base_name = model->name; + if (model->has_props && model->props) { + props = qdict_clone_shallow(qobject_to_qdict(model->props)); + } + break; + default: + error_setg(&err, "Unsupportted expansion type"); + goto out; + } + + if (!props) { + props = qdict_new(); + } + x86_cpu_to_dict(xc, props); + + ret->model = g_new0(CpuModelInfo, 1); + ret->model->name = g_strdup(base_name); + ret->model->props = QOBJECT(props); + ret->model->has_props = true; + +out: + object_unref(OBJECT(xc)); + if (err) { + error_propagate(errp, err); + qapi_free_CpuModelExpansionInfo(ret); + ret = NULL; + } + return ret; +} + X86CPU *cpu_x86_init(const char *cpu_model) { return X86_CPU(cpu_generic_init(TYPE_X86_CPU, cpu_model)); -- 2.11.0.259.g40922b1

1 0

Re: [libvirt] Redhat 7: cgroup CPUACCT controller is not mounted
by youssef.elfathi＠orange.com 27 Feb '17

27 Feb '17

Sorry , please ignore my message I used the wrong mailing-list! -----Original Message----- From: EL FATHI Youssef OBS/OINIS Sent: Monday, February 27, 2017 14:40 To: 'libvir-list(a)redhat.com' Subject: Redhat 7: cgroup CPUACCT controller is not mounted Hi, With a non-root user account, I am launching virtual machines and would like to get CPU stats for each Core (using python API or not) but face the following problem: - When I issue the command "virsh --readonly cpu-stats MY_DOMAIN" I got the following error: error: Failed to retrieve CPU statistics for domain 'MY_DOMAIN' error: Requested operation is not valid: cgroup CPUACCT controller is not mounted - I checked that cgroup is well mounted: $ cat /proc/mounts | grep cgroup tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0 cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 $ cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 6 1 1 cpu 7 1 1 cpuacct 7 1 1 memory 11 1 1 devices 2 1 1 freezer 5 1 1 net_cls 8 1 1 blkio 10 1 1 perf_event 9 1 1 hugetlb 3 1 1 pids 4 1 1 net_prio 8 1 1 - I checked the system-cgtop but don't have no CPU info for my VMs (first line starting with /): Path Tasks %CPU Memory Input/s Output/s / 332 808.0 21.3G - - /system.slice/auditd.service 1 - - - - /system.slice/crond.service 1 - - - - /system.slice/dbus.service 1 - - - - /system.slice/gssproxy.service 1 - - - - /system.slice/irqbalance.service 1 - - - - /system.slice/ksmtuned.service 2 - - - - /system.slice/libvirtd.service 1 - - - - /system.slice/lvm2-lvmetad.service 1 - - - - /system.slice/polkit.service 1 - - - - /system.slice/rhnsd.service 1 - - - - /system.slice/rhsmcertd.service 1 - - - - /system.slice/rsyslog.service 1 - - - - /system.slice/sshd.service 1 - - - - /system.slice/system-getty.slice/getty(a)tty1.service 1 - - - - /system.slice/systemd-journald.service 1 - - - - /system.slice/systemd-logind.service 1 - - - - /system.slice/systemd-udevd.service 1 - - - - /system.slice/tuned.service 1 - - - - /user.slice/user-3972.slice/session-15191.scope 3 - - - - /user.slice/user-3972.slice/session-16005.scope 4 - - - - /user.slice/user-3972.slice/session-16019.scope 10 - - - - Thanks by advance for your help! Regards, Youssef _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

[libvirt] Redhat 7: cgroup CPUACCT controller is not mounted
by youssef.elfathi＠orange.com 27 Feb '17

27 Feb '17

Hi, With a non-root user account, I am launching virtual machines and would like to get CPU stats for each Core (using python API or not) but face the following problem: - When I issue the command "virsh --readonly cpu-stats MY_DOMAIN" I got the following error: error: Failed to retrieve CPU statistics for domain 'MY_DOMAIN' error: Requested operation is not valid: cgroup CPUACCT controller is not mounted - I checked that cgroup is well mounted: $ cat /proc/mounts | grep cgroup tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0 cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 $ cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 6 1 1 cpu 7 1 1 cpuacct 7 1 1 memory 11 1 1 devices 2 1 1 freezer 5 1 1 net_cls 8 1 1 blkio 10 1 1 perf_event 9 1 1 hugetlb 3 1 1 pids 4 1 1 net_prio 8 1 1 - I checked the system-cgtop but don't have no CPU info for my VMs (first line starting with /): Path Tasks %CPU Memory Input/s Output/s / 332 808.0 21.3G - - /system.slice/auditd.service 1 - - - - /system.slice/crond.service 1 - - - - /system.slice/dbus.service 1 - - - - /system.slice/gssproxy.service 1 - - - - /system.slice/irqbalance.service 1 - - - - /system.slice/ksmtuned.service 2 - - - - /system.slice/libvirtd.service 1 - - - - /system.slice/lvm2-lvmetad.service 1 - - - - /system.slice/polkit.service 1 - - - - /system.slice/rhnsd.service 1 - - - - /system.slice/rhsmcertd.service 1 - - - - /system.slice/rsyslog.service 1 - - - - /system.slice/sshd.service 1 - - - - /system.slice/system-getty.slice/getty(a)tty1.service 1 - - - - /system.slice/systemd-journald.service 1 - - - - /system.slice/systemd-logind.service 1 - - - - /system.slice/systemd-udevd.service 1 - - - - /system.slice/tuned.service 1 - - - - /user.slice/user-3972.slice/session-15191.scope 3 - - - - /user.slice/user-3972.slice/session-16005.scope 4 - - - - /user.slice/user-3972.slice/session-16019.scope 10 - - - - Thanks by advance for your help! Regards, Youssef _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

Re: [libvirt] Fail to start 2nd guest
by Stefan Hajnoczi 27 Feb '17

27 Feb '17

On Mon, Feb 27, 2017 at 08:50:03PM +0800, Xiong Zhou wrote: > On Mon, Feb 27, 2017 at 10:11:04AM +0000, Stefan Hajnoczi wrote: > > On Mon, Feb 27, 2017 at 05:40:50PM +0800, Xiong Zhou wrote: > > > It worked fine on Linus tree commit: > > > 7bb0338 Merge tag 'rodata-v4.11-rc1' of git://git.kernel.org/pub/scm/.. > > > > > > failed to start 2nd domain on this commit: > > > 37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/.. > > > (this commit probably is not the first bad, i didn't do the bisecting) > > > > > > > > > sh-4.2# uname -r > > > 4.10.0-master-37c8596+ > > > sh-4.2# rpm -qv qemu > > > qemu-2.0.0-1.el7.6.x86_64 > > > sh-4.2# ps ajxf | grep qemu > > > ... > > > sh-4.2# virsh list > > > Id Name State > > > ---------------------------------------------------- > > > 1 73h running > > > > > > sh-4.2# virsh start 73us > > > error: Failed to start domain 73us > > > error: internal error: qemu unexpectedly closed the monitor: ((null):11497): Spice-Warning **: reds.c:2499:reds_init_socket: listen: Address already in use > > > 2017-02-27T09:33:42.335708Z qemu-kvm: failed to initialize spice server > > > > The error message says that the spice remote desktop cannot listen on > > -spice port=5900,addr=127.0.0.1. > > > > Did you hardcode port 5900 in the domain XML? That could explain why > No. > > the second guest fails to launch - you need to use unique port numbers > > or let libvirt automatically assign them. Check the domain XML: > > > > <graphics type='spice' port='-1' tlsPort='-1' autoport='yes'> > > It looks like: > > <graphics type='spice' autoport='yes'> > <listen type='address'/> > <image compression='off'/> > </graphics> > > > > > > Another possibility is that a process running on the host is already > > using port 5900. Perhaps a guest or VNC server that was launched > > outside of libvirt? You can check this with: > > > > netstat -alpn | grep 5900 > # netstat -alpn | grep 5900 > tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN 11065/qemu-kvm Please check that 11065/qemu-kvm was launched by the same libvirtd and its domain XML also uses autoport='yes'. I have CCed the libvirt mailing list because they may be able to explain why there is a collision on TCP port 5900. Stefan

2 1