December 2016 - Devel - libvirt List Archives

[libvirt] [PATCH v5 0/3] gluster: cache glfs connection object per volume
by Prasanna Kumar Kalever 17 Jan '17

17 Jan '17

v5: Address review comments from Peter on v4 Dropping Patch 3 from v3 Patch 1: fix transport type in all drivers, possible switch case converts Patch 2: use virObject with src->drv to avoid 'initFlag' for remembering 'virStorageFileInit' status Patch 3: * change virStorageBackendGlusterCacheQuery to *Lookup * change virStorageBackendGlusterCacheRefresh to *Release * Avoid the global Flags * Thread safe measure by using virCond* Thanks Peter! v4: Address review comments from Peter on v3 Patch 1: changes to fix test failures (qemuargv2xmltest, qemuxml2argvtest, qemuxml2xmltest and virstoragetest) Patch 2: fix hung in qemuxml2argvtest Patch 3 v3: Split this Patch to 2 parts as below Patch 3 v4: don't free metadata used for storage driver access Patch 4: * update variable naming as per standards * virStorageBackendGlusterPreopened* -> virStorageBackendGlusterCache* Thanks Peter! v3: Address comments by Daniel and Peter on v2 * Split the patch to 3 parts Patch 1: change the virStorageNetHostDef type Patch 2: optimize calls to virStorageFileInit and friends Patch 3: add the caching for glfs * Thanks to Daniel, this version make all the methods as thread safe * Thanks to Peter for pointing use of virObjectLockable, this had simplified rest of the parts a lot. v2: Address review comments from Peter on v1 * Rebased on latest master * Changes to commit msg * Introduce storage API's for Register and Unregister of volume * During qemu process Start/Stop and snapshot create * Check Transport and Port type * Atomic element add/del to list and ref counting Pending: Treating IP and FQDN belong to same host v1: Initial patch Prasanna Kumar Kalever (3): util: change the virStorageNetHostDef type storage: optimize calls to virStorageFileInit and friends gluster: cache glfs connection object per volume src/conf/domain_conf.c | 60 +++-- src/libxl/libxl_conf.c | 10 +- src/qemu/qemu_command.c | 97 ++++--- src/qemu/qemu_domain.c | 25 +- src/qemu/qemu_domain.h | 8 +- src/qemu/qemu_driver.c | 26 +- src/qemu/qemu_parse_command.c | 50 ++-- src/qemu/qemu_process.c | 49 ++++ src/qemu/qemu_process.h | 4 + src/storage/storage_backend.h | 1 + src/storage/storage_backend_fs.c | 5 + src/storage/storage_backend_gluster.c | 329 ++++++++++++++++++++--- src/storage/storage_driver.c | 40 ++- src/storage/storage_driver.h | 2 + src/util/virstoragefile.c | 93 ++++--- src/util/virstoragefile.h | 21 +- src/xenconfig/xen_xl.c | 10 +- tests/domainsnapshotxml2xmlin/disk_snapshot.xml | 2 +- tests/domainsnapshotxml2xmlout/disk_snapshot.xml | 2 +- tests/virstoragetest.c | 2 +- 20 files changed, 614 insertions(+), 222 deletions(-) -- 2.7.4

3 5

[libvirt] Performance about x-data-plane
by Weiwei Jia 16 Jan '17

16 Jan '17

Hi, With QEMU x-data-plane, I find the performance has not been improved very much. Please see following two settings. Setting 1: I/O thread in host OS (VMM) reads 4KB each time from disk (8GB in total). Pin the I/O thread to pCPU 5 which will serve I/O thread dedicatedly. I find the performance is around 250 MB/s. Setting 2: I/O thread in guest OS (VMM) reads 4KB each time from virtual disk (8GB in total). Pin the I/O thread to vCPU 5 and pin vCPU 5 thread to pCPU5 so that vCPU 5 handles this I/O thread dedicatedly and pCPU5 serve vCPU5 dedicatedly. In order to keep vCPU5 not to be idle, I also pin one cpu intensive thread (while (1) {i++}) on vCPU 5 so that the I/O thread on it can be served without delay. For this setting, I find the performance for this I/O thread is around 190 MB/s. NOTE: For setting 2, I also pin the QEMU dedicated IOthread (x-data-plane) in host OS to pCPU to handle I/O requests from guest OS dedicatedly. I think for setting 2, the performance of I/O thread should be almost the same as setting 1. I cannot understand why it is 60 MB/s lower than setting 1. I am wondering whether there are something wrong with my x-data-plane setting or virtio setting for VM. Would you please give me some hints? Thank you. Libvirt version: 2.4.0 QEMU version: 2.3.0 The libvirt xml configuration file is like following (I only start one VM with following xml config). <domain type='kvm' id='1' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>vm</name> <uuid>3290a8d0-9d9f-b2c4-dd46-5d0d8a730cd6</uuid> <memory unit='KiB'>8290304</memory> <currentMemory unit='KiB'>8290304</currentMemory> <vcpu placement='static'>15</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='3'/> <vcpupin vcpu='4' cpuset='4'/> <vcpupin vcpu='5' cpuset='5'/> <vcpupin vcpu='6' cpuset='6'/> <vcpupin vcpu='7' cpuset='7'/> <vcpupin vcpu='8' cpuset='8'/> <vcpupin vcpu='9' cpuset='9'/> <vcpupin vcpu='10' cpuset='10'/> <vcpupin vcpu='11' cpuset='11'/> <vcpupin vcpu='12' cpuset='12'/> <vcpupin vcpu='13' cpuset='13'/> <vcpupin vcpu='14' cpuset='14'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.2'>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>/usr/bin/kvm-spice</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source file='/var/lib/libvirt/images/vm.img'/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <disk type='block' device='cdrom'> <driver name='qemu' type='raw'/> <target dev='hdc' bus='ide'/> <readonly/> <alias name='ide0-1-0'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <controller type='usb' index='0'> <alias name='usb0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='ide' index='0'> <alias name='ide0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='scsi' index='0'> <alias name='scsi0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='network'> <mac address='52:54:00:8e:3d:06'/> <source network='default'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/8'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/8'> <source path='/dev/pts/8'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> </graphics> <video> <model type='cirrus' vram='9216' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> <seclabel type='none'/> <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.virtio-disk0.scsi=off'/> <qemu:arg value='-set'/> <qemu:arg value='device.virtio-disk0.config-wce=off'/> <qemu:arg value='-set'/> <qemu:arg value='device.virtio-disk0.x-data-plane=on'/> </qemu:commandline> </domain> Thank you, Weiwei Jia

4 8

[libvirt] [PATCH v2 00/10] Introduce new libvirt-guest NSS module
by Michal Privoznik 13 Jan '17

13 Jan '17

v2 of: https://www.redhat.com/archives/libvir-list/2016-November/msg01456.html diff to v1: - New module is created instead of putting everything into already existing one - Few hints from review of v1 were worked in Michal Privoznik (10): network: Don't unlock non-locked network driver nssmock: Prefer free() over VIR_FREE() virstring: Introduce virStringListAdd virstring: Introduce virStringListRemove util: Introduce virFileRewriteStr util: Introduce virMACMap module network: Track MAC address map nss: Use macro to generate public API names nss: Move address appending code into a separate function nss: Introduce libvirt-guest module cfg.mk | 2 +- docs/news.html.in | 4 + docs/nss.html.in | 58 ++++- po/POTFILES.in | 1 + src/Makefile.am | 9 + src/conf/network_conf.h | 4 + src/conf/virsecretobj.c | 20 +- src/libvirt_private.syms | 12 ++ src/network/bridge_driver.c | 95 ++++++++- src/network/leaseshelper.c | 14 +- src/util/virfile.c | 24 ++- src/util/virfile.h | 7 +- src/util/virmacmap.c | 399 +++++++++++++++++++++++++++++++++++ src/util/virmacmap.h | 48 +++++ src/util/virstring.c | 84 ++++++++ src/util/virstring.h | 6 + src/util/virxml.c | 4 +- tests/Makefile.am | 36 +++- tests/nssdata/virbr0.macs | 23 ++ tests/nssdata/virbr0.status | 5 + tests/nssdata/virbr1.macs | 21 ++ tests/nssdata/virbr1.status | 5 + tests/nsslinktest.c | 2 +- tests/nssmock.c | 25 ++- tests/nsstest.c | 17 +- tests/virmacmapmock.c | 29 +++ tests/virmacmaptest.c | 232 ++++++++++++++++++++ tests/virmacmaptestdata/complex.json | 45 ++++ tests/virmacmaptestdata/empty.json | 3 + tests/virmacmaptestdata/simple.json | 8 + tests/virmacmaptestdata/simple2.json | 16 ++ tests/virstringtest.c | 98 +++++++++ tools/Makefile.am | 46 +++- tools/nss/libvirt_guest_nss.syms | 12 ++ tools/nss/libvirt_nss.c | 216 +++++++++++++------ tools/nss/libvirt_nss.h | 30 +-- 36 files changed, 1531 insertions(+), 129 deletions(-) create mode 100644 src/util/virmacmap.c create mode 100644 src/util/virmacmap.h create mode 100644 tests/nssdata/virbr0.macs create mode 100644 tests/nssdata/virbr1.macs create mode 100644 tests/virmacmapmock.c create mode 100644 tests/virmacmaptest.c create mode 100644 tests/virmacmaptestdata/complex.json create mode 100644 tests/virmacmaptestdata/empty.json create mode 100644 tests/virmacmaptestdata/simple.json create mode 100644 tests/virmacmaptestdata/simple2.json create mode 100644 tools/nss/libvirt_guest_nss.syms -- 2.11.0

3 26

[libvirt] [PATCH 0/2] Fix issues getting voldef capacity value
by John Ferlan 12 Jan '17

12 Jan '17

Details in each patch - essentially trying to get "more correct" values. John Ferlan (2): storage: Fix virStorageBackendUpdateVolTargetInfo type check storage: Allow probe of volume capacity for BLOCK type src/storage/storage_backend.c | 12 ++++++++---- src/storage/storage_backend.h | 3 ++- src/storage/storage_backend_fs.c | 3 ++- 3 files changed, 12 insertions(+), 6 deletions(-) -- 2.7.4

2 5

[libvirt] [PATCH] disk: Fixup error handling path for devmapper when part_separator='yes'
by John Ferlan 12 Jan '17

12 Jan '17

https://bugzilla.redhat.com/show_bug.cgi?id=1346566 If libvirt_parthelper is erroneously told to append the partition separator 'p' onto the generated output for a disk pool using device mapper that has 'user_friendly_names' set to true, then the error recovery path will fail to find volume resulting in the pool being in an unusable state. So, augment the documentation to provide the better hint that the part_separator='yes' should be set when user_friendly_names are not being used. Additionally, once we're in the error path where the returned name doesn't match the expected partition name try to see if the reason is because the 'p' was erroneosly added. If so alter the about to be removed vol->target.path so that the DiskDeleteVol code can find the partition that was created and remove it. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- docs/formatstorage.html.in | 5 ++++- src/storage/storage_backend_disk.c | 23 +++++++++++++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in index ed1f0d1..7690114 100644 --- a/docs/formatstorage.html.in +++ b/docs/formatstorage.html.in @@ -138,7 +138,10 @@ causes libvirt to attempt to generate and find target volume path's using a "p" separator. The default algorithm used by device mapper is to add the "p" separator only when the source device path ends - with a number. + with a number; however, it's possible to configure the devmapper + device to not use 'user_friendly_names' thus creating partitions + with the "p" separator even when the device source path does not + end with a number. <span class="since">Since 1.3.1</span></p></dd> <dt><code>dir</code></dt> <dd>Provides the source for pools backed by directories (pool diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index 666ad03..07a04f1 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -95,6 +95,29 @@ virStorageBackendDiskMakeDataVol(virStoragePoolObjPtr pool, virReportError(VIR_ERR_INVALID_ARG, _("invalid partition name '%s', expected '%s'"), vol->name, partname); + + /* Let's see if we by chance parthelper created a name that won't be + * found later when we try to delete. We tell parthelper to add a 'p' + * to the output via the part_separator flag, but if devmapper has + * user_friendly_names set, the creation won't happen that way, thus + * our deletion will fail because the name we generated is wrong. + * Check for our conditions and see if the generated name is the + * same as StablePath returns and has the 'p' in it */ + if (pool->def->source.devices[0].part_separator == + VIR_TRISTATE_BOOL_YES && + !virIsDevMapperDevice(vol->target.path) && + STREQ(groups[0], vol->target.path) && + (tmp = strrchr(groups[0], 'p'))) { + + /* If we remove the 'p' from groups[0] and the resulting + * device is a devmapper device, then we know parthelper + * was told to create the wrong name based on the results. + * So just remove the 'p' from the vol->target.path too. */ + memmove(tmp, tmp + 1, strlen(tmp)); + if (virIsDevMapperDevice(groups[0]) && + (tmp = strrchr(vol->target.path, 'p'))) + memmove(tmp, tmp + 1, strlen(tmp)); + } return -1; } -- 2.7.4

2 4

[libvirt] [PATCH 00/11] Adjust build/start format checking for fs, disk, and logical backends
by John Ferlan 11 Jan '17

11 Jan '17

Two of these patches (2 and 10) are followups to no-overwrite patches previously posted (I left links in the patches for reference). Essentially this series works to unify the probing code from the file system backend using blkid and the parted format reading code from the disk backend in one common set of functions. In doing so, the disk backend will now pick up the ability to use the blkid 'partitions' APIs in order to "probe" the target device for a valid/known partition format type. Additionally, the file system probe will pick up a fallback to the parted mechanism from the disk backend if the 'blkid' APIs are not built into the system. A few extra bells/whistles were added for fs pool startup to ensure that the format in the startup XML matches the format on the target disk, which is essentially the mechanism the disk backend used (although it was slightly broken). Then in order to really pile on, the overwrite logic was added to the logical pool which didn't have any such checking (both build and start). Testing was done locally using an iSCSI device and laying down different formats and seeing what would happen on various usages of the format (with --overwrite and --no-overwrite). John Ferlan (11): storage: Introduce virStorageBackendDeviceProbeEmpty storage: Fix implementation of no-overwrite for file system backend storage: Add partition type checks for BLKID probing storage: Add writelabel bool for virStorageBackendDeviceProbe storage: For FS pool check for properly formatted target volume storage: Move and rename disk backend label checking storage: Adjust disk label found to match labels storage: Clean up logical pool devices on build failure storage: Extract logical device initialize into a helper storage: Add overwrite flag checking for logical pool storage: Validate the device formats at logical startup src/libvirt_private.syms | 1 + src/storage/storage_backend.c | 396 ++++++++++++++++++++++++++++++++++ src/storage/storage_backend.h | 4 + src/storage/storage_backend_disk.c | 150 ++----------- src/storage/storage_backend_fs.c | 118 ++-------- src/storage/storage_backend_fs.h | 5 - src/storage/storage_backend_logical.c | 180 ++++++++++------ tools/virsh-pool.c | 2 +- tools/virsh.pod | 42 ++-- 9 files changed, 585 insertions(+), 313 deletions(-) -- 2.7.4

3 22

[libvirt] [PATCH 00/11] tests: qemu: Add cpu hotplug testing
by Peter Krempa 11 Jan '17

11 Jan '17

Add some useful monitor infrastructure to simplify testing and add testing for the cpu hotplug code. The code has some complex logic which was not covered by current test suite. Peter Krempa (11): qemu: monitor: More strict checking of 'query-cpus' if hotplug is supported util: json: Add helper to reformat JSON strings tests: qemu: Document qemuMonitorTestNewFromFile qemu: Prepare for reuse of qemuDomainSetVcpusLive qemu: Move cpu hotplug code into qemu_hotplug.c tests: qemumonitor: Propagate better error messages tests: qemu: monitor: Add helpers to test full command syntax tests: qemu: Add helper to load full monitor conversation from file tests: hotplug: Add test infrastructure for testing qemu CPU hotplug code tests: hotplug: Add test data for legacy cpu hotplug tests: hotplug: Test CPU hotplug with ppc64 data src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 319 ----------- src/qemu/qemu_hotplug.c | 328 ++++++++++++ src/qemu/qemu_hotplug.h | 7 + src/qemu/qemu_monitor.c | 6 +- src/qemu/qemu_monitor_json.c | 6 +- src/qemu/qemu_monitor_json.h | 3 +- src/util/virjson.c | 29 + src/util/virjson.h | 2 + tests/qemuagenttest.c | 3 +- tests/qemuhotplugtest.c | 194 +++++++ tests/qemuhotplugtestcpus/ppc64-bulk-domain.xml | 20 + tests/qemuhotplugtestcpus/ppc64-bulk-monitor.json | 593 +++++++++++++++++++++ .../qemuhotplugtestcpus/ppc64-bulk-result-conf.xml | 64 +++ .../qemuhotplugtestcpus/ppc64-bulk-result-live.xml | 72 +++ .../qemuhotplugtestcpus/x86-modern-bulk-domain.xml | 21 + .../x86-modern-bulk-monitor.json | 471 ++++++++++++++++ .../x86-modern-bulk-result-conf.xml | 40 ++ .../x86-modern-bulk-result-live.xml | 48 ++ tests/qemuhotplugtestcpus/x86-old-bulk-domain.xml | 21 + .../qemuhotplugtestcpus/x86-old-bulk-monitor.json | 193 +++++++ .../x86-old-bulk-result-conf.xml | 30 ++ .../x86-old-bulk-result-live.xml | 38 ++ tests/qemumonitorjsontest.c | 2 +- tests/qemumonitortestutils.c | 322 ++++++++++- tests/qemumonitortestutils.h | 12 +- 26 files changed, 2505 insertions(+), 340 deletions(-) create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-domain.xml create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-monitor.json create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-result-conf.xml create mode 100644 tests/qemuhotplugtestcpus/ppc64-bulk-result-live.xml create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-domain.xml create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-monitor.json create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-result-conf.xml create mode 100644 tests/qemuhotplugtestcpus/x86-modern-bulk-result-live.xml create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-domain.xml create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-monitor.json create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-result-conf.xml create mode 100644 tests/qemuhotplugtestcpus/x86-old-bulk-result-live.xml -- 2.10.2

1 13

[libvirt] [PATCH v3 0/8] aggregate multiple pcie-root-ports onto a single slot
by Laine Stump 11 Jan '17

11 Jan '17

Another rebase of the series with no other changes Laine Stump (8): conf: use struct instead of int for each slot in virDomainPCIAddressBus conf: eliminate concept of "reserveEntireSlot" conf: eliminate repetitive code in virDomainPCIAddressGetNextSlot() conf: start search for next unused PCI address at same slot as previous find conf: new function virDomainPCIAddressIsMulti() qemu: use virDomainPCIAddressIsMulti() to determine multifunction setting conf: aggregate multiple devices on a slot when assigning PCI addresses conf: aggregate multiple pcie-root-ports onto a single slot src/conf/domain_addr.c | 290 ++++++++++++++------- src/conf/domain_addr.h | 48 +++- src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 16 +- src/qemu/qemu_domain_address.c | 35 ++- .../qemuxml2argv-pcie-root-port.args | 5 +- .../qemuxml2argv-pcie-switch-upstream-port.args | 5 +- .../qemuxml2argv-q35-default-devices-only.args | 7 +- .../qemuxml2argv-q35-multifunction.args | 43 +++ .../qemuxml2argv-q35-multifunction.xml | 51 ++++ .../qemuxml2argv-q35-pcie-autoadd.args | 30 ++- tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 28 +- .../qemuxml2argv-q35-virt-manager-basic.args | 13 +- .../qemuxml2argv-q35-virtio-pci.args | 28 +- tests/qemuxml2argvtest.c | 25 ++ .../qemuxml2xmlout-pcie-root-port.xml | 2 +- .../qemuxml2xmlout-pcie-switch-upstream-port.xml | 4 +- .../qemuxml2xmlout-q35-default-devices-only.xml | 8 +- .../qemuxml2xmlout-q35-multifunction.xml | 120 +++++++++ .../qemuxml2xmlout-q35-pcie-autoadd.xml | 52 ++-- .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 48 ++-- .../qemuxml2xmlout-q35-virt-manager-basic.xml | 20 +- .../qemuxml2xmlout-q35-virtio-pci.xml | 48 ++-- tests/qemuxml2xmltest.c | 25 ++ 24 files changed, 676 insertions(+), 276 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-multifunction.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-multifunction.xml -- 2.7.4

4 26

[libvirt] Do different Virgil3D users running have the same CANVAS fingerprint?
by bancfc＠openmailbox.org 11 Jan '17

11 Jan '17

Background: Canvas fingerprinting is a technique to track users based on their GPUs. https://en.wikipedia.org/wiki/Canvas_fingerprinting Someone did some testing and the good news is the fingerprint is common for all users of the same OS across all KVM users because it presents the same virtual GPU/drivers for everybody. What I need your help to find out is whether this holds for Virgil3D users that enable graphics acceleration. (I am running on Debian and the libvirt version in the repos is too old to have this included also I don't have multiple machines) To test this you need: To run plain FireFox on a virtualized distro (with GL acceleration enabled in libvirt) of your choice and visit https://browserleaks.com/canvas . Then repeat the same steps with that same distro (in a VM) on another physical machine and compare values. A good result is if you see the same numbers for both machines. That means the virtual device fingerprint is uniform for all virtual users.

2 3

[libvirt] [PATCH 00/12] vbox: remove support for vbox 3.x and older.
by Dawid Zamirski 10 Jan '17

10 Jan '17

Hello, This series removes support for legacy VirtualBox versions (3.x and older) that did not have upstream support for a while and won't even work on any relatively recent distro. The idea for doing this was first mentioned here [1] and this makes the driver code cleaner as the APIs for those old versions were quite different from v4.0+ and required abstractions to handle the differences. Please note that the first patch in the series is sent to ML as a compressed attachment because it deletes VirtualBox SDK header files for those old verions which are large and the patch would not pass ML message size limit. [1] https://www.redhat.com/archives/libvir-list/2016-November/msg01133.html Regards, Dawid Dawid Zamirski (12): vbox: remove SDK header files for vbox 3 and older. vbox: remove calls to *InstallUniformedAPI macros. vbox: remove code for old API versions. vbox: remove _vboxAttachDrivesOld vbox: do not use IHardDisk anymore. vbox: remove getMachineForSession flag. vbox: remove domain events support. vbox: remove code dealing with oldMediumInterface vbox: IVRDxServer to IVRDEServer. vbox: fix _displayTakeScreenShotPNGToArray vbox: consolidate vbox IID structures. docs: add news entry in improvements section. docs/news.html.in | 8 + src/Makefile.am | 4 - src/vbox/vbox_CAPI_v2_2.h | 4869 ----------------------------------- src/vbox/vbox_CAPI_v3_0.h | 5396 --------------------------------------- src/vbox/vbox_CAPI_v3_1.h | 5297 -------------------------------------- src/vbox/vbox_CAPI_v3_2.h | 5625 ----------------------------------------- src/vbox/vbox_V2_2.c | 37 - src/vbox/vbox_V3_0.c | 37 - src/vbox/vbox_V3_1.c | 37 - src/vbox/vbox_V3_2.c | 37 - src/vbox/vbox_XPCOMCGlue.h | 2 +- src/vbox/vbox_common.c | 402 +-- src/vbox/vbox_common.h | 13 +- src/vbox/vbox_network.c | 12 +- src/vbox/vbox_storage.c | 76 +- src/vbox/vbox_tmpl.c | 3006 ++-------------------- src/vbox/vbox_uniformed_api.h | 171 +- 17 files changed, 438 insertions(+), 24591 deletions(-) delete mode 100644 src/vbox/vbox_CAPI_v2_2.h delete mode 100644 src/vbox/vbox_CAPI_v3_0.h delete mode 100644 src/vbox/vbox_CAPI_v3_1.h delete mode 100644 src/vbox/vbox_CAPI_v3_2.h delete mode 100644 src/vbox/vbox_V2_2.c delete mode 100644 src/vbox/vbox_V3_0.c delete mode 100644 src/vbox/vbox_V3_1.c delete mode 100644 src/vbox/vbox_V3_2.c -- 2.9.3

2 14