- 12 9月, 2019 9 次提交
-
-
由 Michal Privoznik 提交于
The LIBVIRT_RESULT function takes two or three arguments. The first one is the name of the result (aka CHECK_NAME). It is printed before the colon character. The rest of the arguments is printed after the character. To produce colourized output a couple of changes needs to be made. Firstly, we need to print the CHECK_NAME using "echo -n" so that the new line is not appended at the end of the message. To achieve this, AS_MESSAGE_N function is introduced. It's a verbatim copy of AS_MESSAGE (which is just another alias to AC_MSG_NOTICE) except it doesn't put '\n' at the EOL. The alias is defined at /usr/share/autoconf-*/autoconf/general.m4 and the AS_MESSAGE is then defined at /usr/share/autoconf-2.69/m4sugar/m4sh.m4. Secondly, the rest of the arguments are printed colourized and to achieve that and also keep printing them into the log file the _AS_ECHO and COLORIZE_RESULT functions need to be called. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
If we're running from a TTY we can put some colors around 'yes', 'no' and other messages. Shamelessly copied from Ruby source code and modified a bit to comply with syntax-check. https://github.com/ruby/ruby/commit/e4879592873abd4cd8aeed56f4cbaa360a3d3736Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
Now that we have qemuFirmwareGetSupported() so that it also returns a list of FW image paths, we can use it to report them in domain capabilities instead of the old time default list. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
The qemuFirmwareGetSupported() function is called from qemu driver to generate domain capabilities XML based on FW descriptor files. However, the function currently reports only some features from domcapabilities XML and not actual FW image paths. The paths reported in the domcapabilities XML are still from pre-FW descriptor era and therefore the XML might be a bit confusing. For instance, it may say that secure boot is supported but secboot enabled FW is not in the listed FW image paths. To resolve this problem, change qemuFirmwareGetSupported() so that it also returns a list of FW images (we have the list anyway). Luckily, we already have a structure to represent a FW image - virFirmware. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
This function is going to get some new arguments. Document the current ones for clarity. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
This function frees a _virFirmware struct. So far, it doesn't need to be called from outside of the module, but this will change shortly. In the light of recent VIR_DEFINE_AUTOPTR_FUNC() additions, do the same to virFirmwareFree(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
The times, when we had small CRTs are long gone. Now, in the era of wide screens we can be more generous when it comes to aligning the output of configure. The longest string before the colon is 'wireshark_dissector' which counts 19 characters. Therefore, align the strings at 20. At the same time, drop the useless result alignment. It behaves oddly - it puts a space at the end of each "no" because of the %-3s format we use. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
One of the advantages is that LIBVIRT_RESULT aligns the resulting message for us. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
- 11 9月, 2019 6 次提交
-
-
由 Kashyap Chamarthy 提交于
Rewrite some parts for clarity, elaborate the meaning of some of the XML attributes. And where necessary, distinguish that we're dealing with two different XML documents here: - the domainCapabilities XML, to detect the host "hypervisor" (QEMU/KVM) capabilities, and what libvirt knows about them. - the guest XML definition, i.e. what features a guest can use, based on the capabilities (of QEMU and libvirt and the host) reported in the domainCapabilities XML. Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Kashyap Chamarthy 提交于
Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries (an unintentional omission, checking with Cole on #virt, OFTC) for 'x86_64' and 'ia32'. Add them. This way, getDomainCapabilities() will report all the OVMF binaries that are present on the system. E.g. on Fedora 29, if you only have the edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running `virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead of just the OVMF_CODE.fd): $> virsh getdomcapabilities ... <loader supported='yes'> <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> ... ( Learnt this from a discussion with Michal Privoznik in this bug, comment#2: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report firmware (FW) paths in domainCapabilities based on FW descriptor files ) Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Maxiwell S. Garcia 提交于
The snapshot-create operation of running guests saves the live XML and uses it to replace the active and inactive domain in case of revert. So, the config XML is ignored by the snapshot process. This commit changes it and adds the config XML in the snapshot XML as the <inactiveDomain> entry. In case of offline guest, the behavior remains the same and the config XML is saved in the snapshot XML as <domain> entry. The behavior of older snapshots of running guests, that don't have the new <inactiveDomain>, remains the same too. The revert, in this case, overrides both active and inactive domain with the <domain> entry. So, the <inactiveDomain> in the snapshot XML is not required to snapshot work, but it's useful to preserve the config XML of running guests. Signed-off-by: NMaxiwell S. Garcia <maxiwell@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Maxiwell S. Garcia 提交于
The function virDomainDefFormatInternal() has the predefined root name "domain" to format the XML. But to save both active and inactive domain in the snapshot XML, the new root name "inactiveDomain" was created. So, the new function virDomainDefFormatInternalSetRootName() allows to choose the root name of XML. The former function became a tiny wrapper to call the new function setting the correct parameters. Signed-off-by: NMaxiwell S. Garcia <maxiwell@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Once we copy the domain definition from virDomainSnapshotDef, we either need to assign it to the domain object or free it to avoid memory leaks. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Eric Blake 提交于
Commit f1056279 introduced a regression: if reverting to a snapshot fails early (such as when we refuse to revert to an external snapshot), we lose track of the domain's current snapshot. Before that patch, we were tracking the notion of the domain's current snapshot via two means: vm->current_snapshot (which was left untouched on early exit) and snap->def->current (which only controls what gets written to XML to remember snapshots across libvirtd restarts). That patch was fixing a real bug: if a revert operation failed early, later questions from the same libvirtd did not see any change to the current snapsthot, but restarting libvirtd would now claim there is no current snapshot. But it fixed it in the wrong direction, in that the current snapshot was forgotten unconditionally, rather than only when the snapshot to revert to has a chance of being useful. It didn't help that the code after that patch had two separate spots clearing the old notion of the current snapshot - one after determining the snapshot to revert to was viable, the other unconditionally on all failure exit paths. At any rate, the fix is simple: drop the unconditional cleanup on error paths, and rely only on the normal cleanup after early checks. Sadly, it is not possible to test this bug in the existing tests/virsh-snapshot, as the test driver does not have the same prohibition against reverting to an external snapshot as the qemu driver. See: https://bugzilla.redhat.com/1738747Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20190909205242.15406-1-eblake@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
- 10 9月, 2019 18 次提交
-
-
由 Michal Privoznik 提交于
In recent commit of 3d21ff72 the virNetDevMacVLanTapOpen() and virNetDevMacVLanTapSetup() functions were exported in our private symbols. But these functions live in an #ifdef so they need a stub implementation. Then in 1b46566e the virNetDevMacVLanIsMacvtap() function was implemented but again, only for #idef and without stub. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrangé 提交于
The Perl bindings for libvirt use the test driver for unit tests. This tries to load the cpu_map/index.xml file, and when run from an uninstalled build will fail. The problem is that virFileActivateDirOverride is called by our various binaries like libvirtd, virsh, but is not called when a 3rd party app uses libvirt.so To deal with this we allow the LIBVIRT_DIR_OVERRIDE=1 env variable to be set and make virInitialize look for this. The 'run' script will set it, so now build using this script to run against an uninstalled tree we will correctly resolve files to the source tree. Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jiri Denemark 提交于
The only caller for which this check makes sense is virDomainDefParse. Thus the check should be moved there. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This reverts commit 39dded7b. This commit broke virpolkittest on Ubuntu 18 which has an old dbus (v1.12.2). Any other distro with the recent one works (v1.12.16) which hints its a bug in dbus somewhere. Revert the commit to stop tickling it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Michal Privoznik 提交于
There are two 'cleanup' labels - one in virQEMUDriverConfigHugeTLBFSInit() and the other in virQEMUDriverConfigSetDefaults() that do nothing more than return and integer value. No memory freeing or anything important is done there. Drop them in favour of returning immediately. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Michal Privoznik 提交于
Our naming rules prefer qemuObjectOperation() scheme rather than qemuOperationObject() for function names. These were not honoured in recent commits to qemu_conf.c. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Laine Stump 提交于
Traditionally, macvtap devices are supported using <interface type='direct'>, but that type requires specifying a source device name and macvtap mode which can't be altered after the initial device creation (and may not even be available to the management software that's creating the XML config to feed to libvirt). But the attributes in the <source> are essentially describing how the device will be connected to the network, and if libvirt is to be supplied with the name of a macvtap device that has already been created, that device will also already be connected to the network (and the connection can't be changed). Thus it seems more appropriate to use type='ethernet', which was created explicitly for this purpose - for devices that have already been (or will be) connected to the external network by someone/something outside of libvirt. The fact that it is a *macv*tap rather than a contentional tap device is just a detail. This patch supports using an existing macvtap device with <interface type='ethernet'> by checking the supplied target dev name to see if it is a macvtap device and, when this is the case, calling virNetDevMacVLanTapOpen() instead of virNetDevTapCreate(). For consistency, this is only done when target managed='no'. Resolves: https://bugzilla.redhat.com/1723367 (partially) Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
If managed='no', then the tap device must already exist, and setting of MAC address and online status (IFF_UP) is skipped. NB: we still set IFF_VNET_HDR and IFF_MULTI_QUEUE as appropriate, because those bits must be properly set in the TUNSETIFF we use to set the tap device name of the handle we've opened - if IFF_VNET_HDR has not been set and we set it the request will be honored even when running libvirtd unprivileged; if IFF_MULTI_QUEUE is requested to be different than how it was created, that will result in an error from the kernel. This means that you don't need to pay attention to IFF_VNET_HDR when creating the tap devices, but you *do* need to set IFF_MULTI_QUEUE if you're going to use multiple queues for your tap device. NB2: /dev/vhost-net normally has permissions 600, so it can't be opened by an unprivileged process. This would normally cause a warning message when using a virtio net device from an unprivileged libvirtd. I've found that setting the permissions for /dev/vhost-net permits unprivileged libvirtd to use vhost-net for virtio devices, but have no idea what sort of security implications that has. I haven't changed libvrit's code to avoid *attempting* to open /dev/vhost-net - if you are concerned about the security of opening up permissions of /dev/vhost-net (probably a good idea at least until we ask someone who knows about the code) then add <driver name='qemu'/> to the interface definition and you'll avoid the warning message. Note that virNetDevTapCreate() is the correct function to call in the case of an existing device, because the same ioctl() that creates a new tap device will also open an existing tap device. Resolves: https://bugzilla.redhat.com/1723367 (partially) Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
Although <interface type='ethernet'> has always been able to use an existing tap device, this is just a coincidence due to the fact that the same ioctl is used to create a new tap device or get a handle to an existing device. Even then, once we have the handle to the device, we still insist on doing extra setup to it (setting the MAC address and IFF_UP). That *might* be okay if libvirtd is running as a privileged process, but if libvirtd is running as an unprivileged user, those attempted modifications to the tap device will fail (yes, even if the tap is set to be owned by the user running libvirtd). We could avoid this if we knew that the device already existed, but as stated above, an existing device and new device are both accessed in the same manner, and anyway, we need to preserve existing behavior for those who are already using pre-existing devices with privileged libvirtd (and allowing/expecting libvirt to configure the pre-existing device). In order to cleanly support the idea of using a pre-existing and pre-configured tap device, this patch introduces a new optional attribute "managed" for the interface <target> element. This attribute is only valid for <interface type='ethernet'> (since all other interface types have mandatory config that doesn't apply in the case where we expect the tap device to be setup before we get it). The syntax would look something like this: <interface type='ethernet'> <target dev='mytap0' managed='no'/> ... </interface> This patch just adds managed to the grammar and parser for <target>, but has no functionality behind it. (NB: when managed='no' (the default when not specified is 'yes'), the target dev is always a name explicitly provided, so we don't auto-remove it from the config just because it starts with "vnet" (VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the same pattern of names that libvirt itself uses when it automatically creates the tap devices.) Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
This will simplify addition of another attribute to the <target> element Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
This just moves around a few things in qemuInterfaceConnect() with no functional difference (except that a few failures that would have previously resulted in a "success" audit log will now properly produce a "fail" audit). The change is so that adding support for unmanaged tap/macvtap devices will be more easily reviewable. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
In virNetDevMacVLanOpen(), The "retries" arg has been removed and the value hardcoded as 10, since previously the function was only called from one place, so it was always 10. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
This function returns T if the given name is a macvtap device. This is determined by 1) getting the ifindex of the device with that name (if there is one), and 2) checking for existence of /dev/tapXX, where "XX" is the ifindex learned in (1). It's also possible to learn this by getting a netlink dump of the interface and parsing through it to look for some attributes, but that is complicated to figure out, takes longer to execute, and I'm lazy. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 09 9月, 2019 7 次提交
-
-
由 Shivaprasad G Bhat 提交于
There are already good number of test cases with hostdevices, few have multifunction devices but none having more than one than one multifunction cards. This patch adds a case where there are two multifunction cards and two Virtual functions part of the same XML. 0001:01:00.X & 0005:09:00.X - are Multifunction PCI cards. 0000:06:12.[5|6] - are SRIOV Virtual functions Future commits will improve on automatically detecting the multifunction cards and auto-assinging the addresses appropriately. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Daniel Henrique Barboza 提交于
Previous patch had to add '/sys/kernel/' prefix in opendir() because the path, which is being mocked, wasn't being considered due to an 'if SYSFS_PCI_PREFIX' guarding the call to getrealpath(). In fact, all current getrealpath() callers are guarding it with a conditional to ensure that the function will never be called with a non-mocked path. In this case, an extra non-NULL verification is needed for the 'newpath' string to use the variable - which is counterintuitive, given that getrealpath() will always write the 'newpath' string in any non-error conditon. However, simply removing the guard of all getrealpath() instances causes an abort in init_env(). This happens because tests will execute access() to non-mocked paths even before the LIBVIRT_FAKE_ROOT_DIR variable is declared in the test files. We don't need 'fakerootdir' to be created at this point though. This patch does the following changes to simplify getrealpath() usage: - getrealpath() will now guard the init_env() call by checking if both fakeroot isn't created and the required path is being mocked. This ensures that we're not failing inside init_env() because we're too early and LIBVIRT_FAKE_ROOT_DIR wasn't defined yet; - remove all conditional guards to call getrealpath() from access(), virMockStatRedirect(), open(), open_2(), opendir() and virFileCanonicalizePath(). As a bonus, remove all ternary conditionals with 'newpath'; - a new 'pathPrefixIsMocked()' helper to aggregate all the prefixes we're mocking, making it easier to add/remove them. If a prefix is added inside this function, we can be sure that all functions are mocking them. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Shivaprasad G Bhat 提交于
This patch adds hostdev test cases in qemuhotplugtest.c. Note: the small tweak inside virpcimock.c was needed because the new tests added a code path in which virHostHasIOMMU() (virutil.c) started being called, and the mocked '/sys/kernel/' prefix that is mocked in virpcimock.c wasn't being considered in the opendir() mock. An alternative to avoid these situations in virpcimock.c is implemented in the next patch. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Shivaprasad G Bhat 提交于
The softlink to physfn is the way to know if the device is VF or not. So, the patch softlinks 'physfn' to the parent function. The multifunction PCI devices dont have 'physfn' softlinks. The patch adds few Virtual functions to the mock environment and changes the existing VFIO test xmls using the VFs to use the newly added VFs for their use case. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel Henrique Barboza 提交于
This patch adds mock of the /dev/vfio path, needed for proper implementation of the support for multifunction/multiple devices per iommu groups. To do that, the existing bind and unbind operations were adapted to operate with the mocked filesystem as well. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Eric Farman 提交于
When starting a domain, we use the presence of a vfio-pci or mdev hostdev to determine if the memlock maximum needs to be increased. But if we hotplug either of these devices, only the vfio-pci path gets that love. This means that attaching a, say, vfio-ccw device will appear to succeed but the device may be unusable as the guest may see I/O errors on long CCW chains. The host, meanwhile, would be flooded with these messages: vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded Let's adjust the maximum memlock value in the mdev hotplug path, so that the domain has the same value as if it were started with one or more mdev devices in its configuration. Signed-off-by: NEric Farman <farman@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Eric Farman 提交于
If attaching a PCI hostdev fails, there are several things that need to be un-done as part of the cleanup. One thing that is not done is re-calculating/re-setting the maximum amount of locked memory for the domain, since we may have changed that. Let's fix that, just to ensure everything is back the way it was. Signed-off-by: NEric Farman <farman@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-