- Devel - libvirt List Archives

[libvirt] [PATCH] IPv6 route check: list devices only once
by Cédric Bosdonnat 26 Apr '17

26 Apr '17

If several RA routes are found for the same device, only list that device once in the error message. --- src/util/virnetdevip.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/util/virnetdevip.c b/src/util/virnetdevip.c index 09925e1d7..bf98ed8a5 100644 --- a/src/util/virnetdevip.c +++ b/src/util/virnetdevip.c @@ -551,6 +551,8 @@ virNetDevIPCheckIPv6ForwardingCallback(const struct nlmsghdr *resp, int ret = 0; int len = RTM_PAYLOAD(resp); int oif = -1; + size_t i; + bool hasDevice; /* Ignore messages other than route ones */ if (resp->nlmsg_type != RTM_NEWROUTE) @@ -587,7 +589,13 @@ virNetDevIPCheckIPv6ForwardingCallback(const struct nlmsghdr *resp, accept_ra = virNetDevIPGetAcceptRA(ifname); VIR_DEBUG("Checking route for device %s, accept_ra: %d", ifname, accept_ra); - if (accept_ra != 2 && VIR_APPEND_ELEMENT(data->devices, data->ndevices, ifname) < 0) + hasDevice = false; + for (i = 0; i < data->ndevices && !hasDevice; i++) { + if (STREQ(data->devices[i], ifname)) + hasDevice = true; + } + if (accept_ra != 2 && !hasDevice && + VIR_APPEND_ELEMENT(data->devices, data->ndevices, ifname) < 0) goto error; cleanup: -- 2.12.2

2 1

[libvirt] Plans for next release
by Daniel Veillard 26 Apr '17

26 Apr '17

I didn't realized that end of month was getting that close. So I suggest to enter freeze for 3.3.0 on Friday. I can then push an RC2 on Monday evening or Tuesday and push the release Wed or Thursday, I hope that works for everybody, there is roughtly 2 days to push patches you want in (except bug fixes of course :) thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [RFC] Adopting 'Tested-by' tag (and probably other tags)?
by Kashyap Chamarthy 26 Apr '17

26 Apr '17

Hi folks, I was wondering if the upstream would be receptive to adding a 'Tested-by' tag for patches that had someone give tested feedback on the list. Personally, what I consider a bar for giving a 'Tested-by' is, when someone: - Applies a patch or a series (following the iterations as needed, over time) locally, compile them, spend time understanding the functional change in question, and its implications.) - Do a concrete test (w/ either a Python API or a `virsh`-based command-line) that exercises the said code path. - *Post* the above test procedure / and necessary outputs as evidence to the list, in reasonable detail. (Not a: "yeah, I tested and it works" -- this isn't a 'rule'; it can have exceptions) >From a quick glance, in its 10-year history, libvirt upstream had about a mere 21 entries of 'Tested-by' tags: $ git log | grep Tested-by | wc -l 21 I bring this up because, when someone spends effort following (sometimes over weeks / months) a patch (or a series) from the list, gives reasonably detailed test feedback, in my books, it would be fair to acknowledge it in the Git. And it will encourage them to spend time in future. --- I realize that if it's not automated (via Git hooks or similar), it can become "lossy", i.e. if Joe posts v1 of a patch, you give a 'Tested-by', then there are two scenarios that immediately spring to mind: (1) Joe respins a v2 to make some corrections, adds your 'Tested-by' tag, and whoever applies the patch picks it up -- all good. (b) However, if a v2 was _not_ necessary, then whoever is applying the patch / series must remember to add the tag -- "lossy". Thoughts / remarks / rotten tomatoes welcome. -- /kashyap

5 9

[libvirt] [PATCH v2 00/10] Add mdev reporting capability to the nodedev driver
by Erik Skultety 26 Apr '17

26 Apr '17

since v1: - dropped the <description> element from the parent device nested capability - added missing RNG schema and tests - updated the documentation to describe the MDEV elements in both the parent and the child So, regarding the discussion about the presence of <description> element in the device XML, I dropped it for v2. There were points that we could continue debating about, but one of the major points against it is that libvirt should understand the information it's gathering and then exposing it in a structured way, which in this case wasn't the case, which wouldn't make the management layer's job any easier in any way, since they'd have to parse it either way (from libvirt or on their own). So, until this is resolved among vendors so that we can apply some kind of device classification (no userspace DB), management will have to simply read the description directly from sysfs. As part of a private discussion, another interesting point has been raised - virsh nodedev-list does support '--cap' option which filters only devices matching the pattern. However, with SRIOV, NPIV, and MDEV we have nested capabilities which are kept private and cannot be filtered by. That might be a nice feature for users: 1) OK, let's see what MDEVs are there on the host virsh nodedev-list --cap="mdev-<child|whatever>" 2) I'd like to create some on my own, so which physical devices do support MDEV? virsh nodedev-list --cap='mdev-<parent|whatever>' 3) create the device on that physical device The same goes for SRIOV, where we have virt_functions in parent and phys_function in child and NPIV (I don't remember what it was here), I didn't check in depth, but I think it should be possible for us to do and it's a valid use case where users don't have to parse dumpxml's output for information about the parent's nested capabilities. Erik Erik Skultety (10): nodedev: Make use of the compile-time missing enum in switch error conf: nodedev: Split virNodeDeviceDefFormat into more functions nodedev: udevProcessPCI: Drop syspath variable docs: Utilize our XSLT list generating template more nodedev: conf: Split PCI sub-capability parsing to a separate method nodedev: Introduce the mdev capability to the nodedev driver structure nodedev: Introduce the mdev capability to a PCI parent device nodedev: Introduce mdev capability for child devices docs: Provide a nodedev driver stub documentation docs: Document the mediated devices within the nodedev driver docs/drivers.html.in | 6 +- docs/drvnodedev.html.in | 344 +++++++++ docs/remote.html.in | 106 +-- docs/schemas/nodedev.rng | 41 ++ docs/storage.html.in | 62 +- include/libvirt/libvirt-nodedev.h | 1 + src/conf/node_device_conf.c | 812 +++++++++++++-------- src/conf/node_device_conf.h | 21 +- src/conf/virnodedeviceobj.c | 3 +- src/libvirt-nodedev.c | 1 + src/libvirt_private.syms | 1 + src/node_device/node_device_driver.c | 1 + src/node_device/node_device_udev.c | 242 +++++- .../mdev_3627463d_b7f0_4fea_b468_f1da537d301b.xml | 8 + tests/nodedevschemadata/pci_0000_02_10_7_mdev.xml | 27 + tests/nodedevxml2xmltest.c | 1 + tools/virsh-nodedev.c | 2 + 17 files changed, 1223 insertions(+), 456 deletions(-) create mode 100644 docs/drvnodedev.html.in create mode 100644 tests/nodedevschemadata/mdev_3627463d_b7f0_4fea_b468_f1da537d301b.xml create mode 100644 tests/nodedevschemadata/pci_0000_02_10_7_mdev.xml -- 2.12.2

3 23

Re: [libvirt] How to get VM memory usage
by Eric Blake 26 Apr '17

26 Apr '17

[moderator note: I'm forwarding a stripped down version of the original mail which was rejected in the moderator queue. I stripped the .jpg attachments, which are inappropriate for a technical list. Either paste the text contents (rather than a screenshot) of the window you are describing, or host your images elsewhere and have your list email merely give a URL of the externally-hosted images] > ForwardedMessage.eml > > Subject: > Re: Re: [libvirt] How to get VM memory usage > From: > "wangyufeng(a)cloudguarding.com" <wangyufeng(a)cloudguarding.com> > Date: > 04/26/2017 01:21 AM > > To: > "Daniel P. Berrange" <berrange(a)redhat.com> > CC: > libvir-list <libvir-list(a)redhat.com> > > > Hi Daniel, > > I found method MemoryStats in domain.go: > func (d *Domain) MemoryStats(nrStats uint32, flags uint32) ([]DomainMemoryStat, error) { > ptr := make([]C.virDomainMemoryStatStruct, nrStats) > > result := C.virDomainMemoryStats( > d.ptr, (C.virDomainMemoryStatPtr)(unsafe.Pointer(&ptr[0])), > C.uint(nrStats), C.uint(flags)) > > if result == -1 { > return []DomainMemoryStat{}, GetLastError() > } > > out := make([]DomainMemoryStat, result) > for i := 0; i < int(result); i++ { > out = append(out, DomainMemoryStat{ > Tag: int32(ptr[i].tag), > Val: uint64(ptr[i].val), > }) > } > return out, nil > } > > Do you mean this method can get used memory info? > While I invoke the method, which can only get values of tag 0 and tag 6: > > And the balloon driver have been activated on the monitored vm: > > Below is my code, could you tell me what's wrong with my code? > > Thank you very much. > > ---------------------------------------------------------------------------------------------------------- > On Fri, Apr 21, 2017 at 09:58:12AM +0800, wangyufeng(a)cloudguarding.com wrote: >> Hi Daniel, >> >> In method 'GetInfo', we can only get memory and max memory. However I >> need to get used memory for calculating memory usage. The virsh command >> 'dommemstat' can obtain used memory, is there a method in libvirt-go to >> obtain used memory? > > That command uses the virDomainMemoryStats() API call > > > Regards, > Daniel > -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange > :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: > https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org

1 0

[libvirt] [PATCH v3 0/5] Alter the clearing of device for new partition table
by John Ferlan 26 Apr '17

26 Apr '17

Well kind of a v2/v3 type mashup - essentially reworked the portion of the series: https://www.redhat.com/archives/libvir-list/2017-April/msg00402.html that dealt with the zeroing of the header of the device path. The changes now will allow both the head and tail of the device path to be cleared rather than just the header of the file which was ACK'd for at least the logical backend. Additionally, bump the size of the clear/zero from 2048KB to 1MB and use it for both the logical and disk backends. John Ferlan (5): storage: Modify storageBackendWipeLocal to allow zero from end of device storage: Introduce virStorageBackendZeroPartitionTable logical: Use virStorageBackendZeroPartitionTable logical: Increase the size of the data to wipe disk: Use virStorageBackendZeroPartitionTable src/storage/storage_backend_disk.c | 6 ++- src/storage/storage_backend_logical.c | 44 +--------------------- src/storage/storage_util.c | 70 ++++++++++++++++++++++++++++------- src/storage/storage_util.h | 4 ++ 4 files changed, 67 insertions(+), 57 deletions(-) -- 2.9.3

2 10

[libvirt] [PATCH] Update keycodemapdb submodule for python2 compat fixes
by Daniel P. Berrange 26 Apr '17

26 Apr '17

There were a few bugs in keycodemap tool that broke it when run on python circa 2.7.5 or older, which affected RHEL builds. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Pushed as a CI build fix for rhel6/7 src/keycodemapdb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/keycodemapdb b/src/keycodemapdb index bd754b8..7bf5710 160000 --- a/src/keycodemapdb +++ b/src/keycodemapdb @@ -1 +1 @@ -Subproject commit bd754b861e7de5c7919aa249a975913cb207b85d +Subproject commit 7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 -- 2.9.3

1 0

[libvirt] [PATCH v2 00/13] Multiple cleanups within nwfilterobj and nwfilter drivers
by John Ferlan 26 Apr '17

26 Apr '17

v1: https://www.redhat.com/archives/libvir-list/2017-April/msg01074.html Changes since v1: * Patch 2 -> Do not add the local @def when just dereference obj->def * Patch 13 & 15 dropped Most patches were ACK'd, but patch 2's impact was felt in a few other patches so I just resent the whole thing. In particular patch 5 for nwfilterUndefine and nwfilterGetXMLDesc as well as patch 7 for the _virNWFilterObjListDefLoopDetect call w/ _virNWFilterObjListDefLoopDetect John Ferlan (13): nwfilter: Use consistent naming for variables nwfilter: Use virNWFilterDefPtr rather than deref virNWFilterObjPtr nwfilter: Remove unused 'active' in virNWFilterObj nwfilter: Convert wantRemoved to bool nwfilter: Make _virNWFilterObjPtr private nwfilter: Introduce virNWFilterObjNew nwfilter: Rename some virNWFilterObj* API's nwfilter: Make _virNWFilterObjList private nwfilter: Make a common UUID lookup function from driver nwfilter: Replace virNWFilterConfigFile with virFileBuildPath nwfilter: Replace virNWFilterSaveDef with virNWFilterSaveConfig nwfilter: Move creation of configDir to driver initialization nwfilter: Move save of config until after successful assign src/conf/nwfilter_conf.c | 57 +------ src/conf/nwfilter_conf.h | 8 - src/conf/virnwfilterobj.c | 270 +++++++++++++++++++++------------ src/conf/virnwfilterobj.h | 70 ++++----- src/libvirt_private.syms | 20 ++- src/nwfilter/nwfilter_driver.c | 138 ++++++++++------- src/nwfilter/nwfilter_gentech_driver.c | 42 ++--- 7 files changed, 320 insertions(+), 285 deletions(-) -- 2.9.3 FWIW: The diffs between this series and the previous taking away patches 13/15: diff --git a/src/conf/virnwfilterobj.c b/src/conf/virnwfilterobj.c index 62206b8..8c9da13 100644 --- a/src/conf/virnwfilterobj.c +++ b/src/conf/virnwfilterobj.c @@ -92,16 +92,11 @@ virNWFilterObjWantRemoved(virNWFilterObjPtr obj) static void virNWFilterObjFree(virNWFilterObjPtr obj) { - virNWFilterDefPtr def; - virNWFilterDefPtr newDef; - if (!obj) return; - def = obj->def; - newDef = obj->newDef; - virNWFilterDefFree(def); - virNWFilterDefFree(newDef); + virNWFilterDefFree(obj->def); + virNWFilterDefFree(obj->newDef); virMutexDestroy(&obj->lock); @@ -204,7 +199,6 @@ _virNWFilterObjListDefLoopDetect(virNWFilterObjListPtr nwfilters, size_t i; virNWFilterEntryPtr entry; virNWFilterObjPtr obj; - virNWFilterDefPtr objdef; if (!def) return 0; @@ -221,8 +215,7 @@ _virNWFilterObjListDefLoopDetect(virNWFilterObjListPtr nwfilters, obj = virNWFilterObjListFindByName(nwfilters, entry->include->filterref); if (obj) { - objdef = obj->def; - rc = _virNWFilterObjListDefLoopDetect(nwfilters, objdef, + rc = _virNWFilterObjListDefLoopDetect(nwfilters, obj->def, filtername); virNWFilterObjUnlock(obj); if (rc < 0) @@ -386,13 +379,11 @@ virNWFilterObjListNumOfNWFilters(virNWFilterObjListPtr nwfilters, { size_t i; int nfilters = 0; - virNWFilterDefPtr def; for (i = 0; i < nwfilters->count; i++) { virNWFilterObjPtr obj = nwfilters->objs[i]; virNWFilterObjLock(obj); - def = obj->def; - if (!aclfilter || aclfilter(conn, def)) + if (!aclfilter || aclfilter(conn, obj->def)) nfilters++; virNWFilterObjUnlock(obj); }

2 14

[libvirt] Unbounded client streams
by Michal Privoznik 26 Apr '17

26 Apr '17

Dear list, as you might have seen, I've been playing with our streams lately. One of the things I wanted to try was how my sparse streams deal with vol-download and slow writer (e.g. slow disk). Note to whomever wants to try that out: blkio,throttle.write_* is no good for this. So I went the old way: diff --git i/tools/virsh-util.c w/tools/virsh-util.c index 4b86e29..8f5738d 100644 --- i/tools/virsh-util.c +++ w/tools/virsh-util.c @@ -149,6 +149,8 @@ virshStreamSink(virStreamPtr st ATTRIBUTE_UNUSED, { int *fd = opaque; + sleep(60); + return safewrite(*fd, bytes, nbytes); } And found out something ugly: the memory footprint of virsh just keeps growing as vol-download progresses. I've tracked down the problem to: 1) The client event loop (virNetClientIOEventLoop) sees some incoming data, so it reads it (virNetClientIOHandleInput -> virNetClientCallDispatch) and queues the packet (virNetClientCallDispatchStream) regardless of the length of already queued packets 2) Since the server sees client has read all the data, it sends even more data. And the queue in step 1) just grows and grows. Ideally, the packets are taken out from the queue by virStreamRecv (which boils down to virNetClientStreamRecvPacket), but that is not on the schedule for the next minute. Frankly, I don't have any idea how to fix this. We can stop reading the data (i.e. not set POLLIN on the client <-> server socket) if the queue reaches certain length. BUT, this would mean no other call is processed. Not even keepalive - and the connection would break. The other option is to pretend I've never send this e-mail and you've read nothing O:-) Michal

4 9

[libvirt] [PATCHv2 0/6] Support more options for intel-iommu
by Ján Tomko 26 Apr '17

26 Apr '17

For https://bugzilla.redhat.com/show_bug.cgi?id=1427005 v2: * use != VIR_TRISTATE_SWITCH_ABSENT more often * use symlinks for identical XMLs * move capability checks in qemuBuildIOMMUCommandLine to the beginning, to be shared with qemuBuildIOMMUCommandLine Documentation changes reflecting current QEMU implementation limits are not included. Ján Tomko (6): conf: add <irqchip mode> to <features> qemu: format kernel_irqchip on the command line conf: add <driver intremap> to <iommu> qemu: format intremap= on intel-iommu command line conf: add caching attribute to iommu device qemu: format caching-mode on iommu command line docs/formatdomain.html.in | 41 +++++++++- docs/schemas/domaincommon.rng | 30 ++++++++ src/conf/domain_conf.c | 90 ++++++++++++++++++++-- src/conf/domain_conf.h | 14 ++++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 12 +++ src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 40 ++++++++++ tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies | 22 ++++-- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies | 24 ++++-- tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies | 24 ++++-- tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 28 +++++-- tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.8.0.x86_64.replies | 37 +++++++-- tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 + .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 49 +++++++++--- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 3 + .../qemuxml2argv-intel-iommu-caching.args | 19 +++++ .../qemuxml2argv-intel-iommu-caching.xml | 28 +++++++ .../qemuxml2argv-intel-iommu-irqchip.args | 19 +++++ .../qemuxml2argv-intel-iommu-irqchip.xml | 31 ++++++++ tests/qemuxml2argvtest.c | 10 +++ .../qemuxml2xmlout-intel-iommu-caching.xml | 1 + .../qemuxml2xmlout-intel-iommu-irqchip.xml | 1 + tests/qemuxml2xmltest.c | 2 + 37 files changed, 496 insertions(+), 49 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu-caching.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu-caching.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu-irqchip.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-intel-iommu-irqchip.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-intel-iommu-caching.xml create mode 120000 tests/qemuxml2xmloutdata/qemuxml2xmlout-intel-iommu-irqchip.xml -- 2.10.2

2 14