Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

* docs/news.xml: updated for the release
Signed-off-by: NDaniel Veillard <veillard@redhat.com>

Now that libvirt has firmware auto selection feature the nvram
config knob is more or less obsolete. It still makes sense in
cases where distro users are using does not provide FW descriptor
files, therefore I'm not removing it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Match the XML feature usage of the qemu driver, so the test driver
doesn't reject things like <os firmware='efi'/>.

Particularly VIR_DOMAIN_DEF_FEATURE_NET_MODEL_STRING is needed to
prevent regressions for test suite users with net model strings that
aren't in the virDomainNetModel enum yet
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Commit 3b71f2e4 added spec handling for with_firewalld_zone. We
now call %firewalld_reload if with_firewalld is set. But the matching
'BuildRequires: firewalld-filesystem' is only applied if
with_firewalld_zone is set.

Fix the former bit to use with_firewalld_zone
Reviewed-by: NLaine Stump <laine@laine.org>
Reported-by: NYuval Turgeman <yturgema@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This function is calling public API virNetworkLookupByName()
which resets the error. Therefore, if
virDomainNetReleaseActualDevice() is used in cleanup path it
actually resets the original error that got us jump into
'cleanup' label.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some basic features/bugfixes/removed features. Of course we've
done a lot more than recoded here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This caused the live XML to report the 'bridge' type instead of the
'network' type, which is a behavioural regression.

It also breaks 'virsh domif-setlink', 'virsh update-device' and
'virsh domiftune'

This reverts commit 518026e1.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 2f5e6502.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

vhostfd passed to cmd->passfd in virCommandPassFD, virCommandFree will
always close cmd->passfd when qemuBuildSCSIVHostHostdevDevStr failed.
Signed-off-by: NJie Wang <wangjie88@huawei.com>

This commit is similar with 692400f4. It fixes an uninitialized
variable to avoid garbage value. This case, returns 0 jiffies if an
error occurs with virNetDevBridgeGet.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

Commit a3dbaa36 neglected to add the source-protocol-ver to the
pool-define-as command.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>

Fix obvious typo.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>

firmware attribute from <os/> takes either 'efi' or 'bios' as its
allowed values. However, the current documentation mistakenly mentions
'uefi' instead of 'efi'.
Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1697676

If an user tries to attach a device with colliding user alias
then we attach it happily and thus leave domain unable to start.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When attaching a device to live XML we don't care (well,
shouldn't care) that there's already a device in inactive XML
that has the same user alias.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If we're attaching a device to both inactive and live XML then
@ret is overwritten which may result in incorrect return value.
For instance, if attaching to inactive XML succeeds, @ret is
assigned value of zero and control proceeds to attaching the
device to live XML. Here, if say
virDomainDeviceValidateAliasForHotplug() fails the control jumps
over to 'cleanup' label and zero is returned indicating success.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Our coding style specifies that only negative values are considered as
error. Check for return value of virDomainDiskInsert() properly,
following the style. Not that the function can now return anything other
than 0 or -1, but it just triggers my OCD.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Each attribute is on its own line. We forgot to add new line
character for <alias/>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Added in QEMU by v2.12.0-481-g0da0fb0628 (released in 3.0).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In cases when the hash function for a name collides with other entry
already in the hash we prepend to the bucket. This creates a 'stack
effect' on the buckets if we then iterate through the hash. Normally
this is not a problem, but in tests we want deterministic results.

Since it does not matter where we add the entry and it's usually more
probable that a different entry will be accessed next change it to
append to the end of the bucket. Luckily we already iterate throught the
bucket once thus we can easily find the last entry and just connect the
new entry after it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If the current QEMU guest can't wake up from suspend properly,
and we are able to determine that, avoid suspending the guest
at all. To be able to determine this support, QEMU needs to
implement the 'query-current-machine' QMP call. This is reflected
by the QEMU_CAPS_QUERY_CURRENT_MACHINE cap.

If the cap is enabled, a new function qemuDomainProbeQMPCurrentMachine
is called. This is wrapper for qemuMonitorGetCurrentMachineInfo,
where the 'wakeup-suspend-support' flag is retrieved from
'query-current-machine'. If wakeupSuspendSupport is true,
proceed with the regular flow of qemuDomainPMSuspendForDuration.

The absence of QEMU_CAPS_QUERY_CURRENT_MACHINE indicates that
we're dealing with a QEMU version older than 4.0 (which implements
the required QMP API). In this case, proceed as usual with the
suspend logic of qemuDomainPMSuspendForDuration, since we can't
assume whether the guest has support or not.

Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1759509Reported-by: NBalamuruhan S <bala24@linux.vnet.ibm.com>
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far, this command returns a structure with only one member:
'wakeup-suspend-support'. But that's okay. It's what we are after
anyway.

Based-on-work-of: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

QEMU commit 46ea94ca9cf ("qmp: query-current-machine with
wakeup-suspend-support") added a new QMP command called
'query-current-machine' that retrieves guest parameters that
can vary in the same machine model (e.g. ACPI support for x86 VMs
depends on the '--no-acpi' option). Currently, this API has a single
flag, 'wakeup-suspend-support', that indicates whether the guest has
the capability of waking up from suspended state.

Introduce a libvirt capability that reflects whether qemu has the
monitor command.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

virCgroup struct is always defined and the free function is not calling
anything that would require OS supporting cgroups.

This fixes an issue if we try to start a VM with QEMU binary that
doesn't support QXL.  The start operation will fail in
qemuProcessStartValidateVideo() which will set correct error message,
but later in one of the cleanup paths we will call
qemuDomainObjPrivateDataClear() which always calls virCgroupFree()
and that will fail on OS that doesn't support cgroups and it will
set a new error which will be eventually reported to user.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If a bitmap of a shorter length than the data buffer is passed to
virBitmapToDataBuf, it will read off the end of the bitmap and copy junk
into the returned buffer. Add a check to only copy the length of the
bitmap to the buffer.

The problem can be observed after setting a vcpu affinity using the vcpupin
command on a system with a large number of cores:
  # virsh vcpupin example_domain 0 0
  # virsh vcpupin example_domain 0
     VCPU   CPU Affinity
    ---------------------------
     0      0,192,197-198,202
Signed-off-by: NJohn Allen <john.allen@amd.com>

Different check values are not ABI compatible. For example
if on migration we change 'full' to 'partial' then guest cpu
on destination can be different.
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

If there's an error when setting up QoS on a bridge the control
jumps over to 'err5' label. Here, the virNetDevBandwidthClear()
is called to clear out any partially set QoS. This function can
also report an error which would overwrite the actual error that
caused us jumping here. Use virErrorPreserveLast() to preserve
the original error.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

qemu 4.0.0 will prefix most errors with 'Error: ', so consider any
string instance of that an error.

This fixes savevm failure detection when migration is blocked due to
usage of nested VMX

https://bugzilla.redhat.com/show_bug.cgi?id=1697997Acked-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Drop redundant NULL checks, and add an error string prefix
Acked-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Drop redundant NULL checks, add error string prefixes, consolidate
a few indentical reports.
Acked-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Replaced usage of virSaveLastError and virSetError/virFreeError with
virErrorPreserveLast and virErrorRestore respectively.
Signed-off-by: NSyed Humaid <syedhumaidbinharoon@gmail.com>

The @firmware string is allocated, but never freed.

 4 bytes in 1 blocks are definitely lost in loss record 1 of 44
    at 0x483579F: malloc (vg_replace_malloc.c:299)
    by 0x76FB469: strdup (strdup.c:42)
    by 0x497B6DE: virStrdup (virstring.c:966)
    by 0x48F6FD3: virConfGetValueString (virconf.c:908)
    by 0x4B3E9B6: virVMXGetConfigStringHelper (vmx.c:736)
    by 0x4B3EA6B: virVMXGetConfigString (vmx.c:756)
    by 0x4B41AEA: virVMXParseConfig (vmx.c:1832)
    by 0x10B8E4: testCompareFiles (vmx2xmltest.c:79)
    by 0x10BAB8: testCompareHelper (vmx2xmltest.c:124)
    by 0x10D058: virTestRun (testutils.c:174)
    by 0x10CDDA: mymain (vmx2xmltest.c:288)
    by 0x10F11C: virTestMain (testutils.c:1096)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPino Toscano <ptoscano@redhat.com>

Allocated in libxlDriverConfigNew(), the @configBaseDir is never
freed.

 13 bytes in 1 blocks are definitely lost in loss record 36 of 125
    at 0x483579F: malloc (vg_replace_malloc.c:299)
    by 0x8012469: strdup (strdup.c:42)
    by 0x52926DE: virStrdup (virstring.c:966)
    by 0x11D46B: libxlDriverConfigNew (libxl_conf.c:1749)
    by 0x114D78: testCompareXMLToDomConfig (libxlxml2domconfigtest.c:62)
    by 0x1152A3: testCompareXMLToDomConfigHelper (libxlxml2domconfigtest.c:160)
    by 0x115925: virTestRun (testutils.c:174)
    by 0x1154A4: mymain (libxlxml2domconfigtest.c:216)
    by 0x1179E9: virTestMain (testutils.c:1096)
    by 0x1154FD: main (libxlxml2domconfigtest.c:224)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's no need to keep @binary around.
virQEMUCapsInitGuestFromBinary() duplicates the string anyway.

 1,002 bytes in 36 blocks are definitely lost in loss record 54 of 59
    at 0x483579F: malloc (vg_replace_malloc.c:299)
    by 0x796B1C7: vasprintf (vasprintf.c:73)
    by 0x4C3F2C6: virVasprintfInternal (virstring.c:740)
    by 0x4C3F3DC: virAsprintfInternal (virstring.c:761)
    by 0x13AFC9: testGetCaps (qemucaps2xmltest.c:105)
    by 0x13B200: testQemuCapsXML (qemucaps2xmltest.c:157)
    by 0x13B642: virTestRun (testutils.c:174)
    by 0x13B366: doCapsTest (qemucaps2xmltest.c:191)
    by 0x13FF2B: testQemuCapsIterate (testutilsqemu.c:941)
    by 0x13B427: mymain (qemucaps2xmltest.c:215)
    by 0x13D706: virTestMain (testutils.c:1096)
    by 0x13B489: main (qemucaps2xmltest.c:221)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function is not used anymore. Let's remove it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

It's funny how this went unnoticed for such a long time. Long
story short, if a domain is configured with
VIR_DOMAIN_NUMATUNE_MEM_STRICT libvirt doesn't really honour
that. This is because of 7e72ac78 after which libvirt allowed
qemu to allocate memory just anywhere and only after that it used
some magic involving cpuset.memory_migrate and cpuset.mems to
move the memory to desired NUMA nodes. This was done in order to
work around some KVM bug where KVM would fail if there wasn't a
DMA zone available on the NUMA node. Well, while the work around
might stopped libvirt tickling the KVM bug it also caused a bug
on libvirt side: if there is not enough memory on configured NUMA
node(s) then any attempt to start a domain must fail. Because of
the way we play with guest memory domains can start just happily.

The solution is to move the child we've just forked into emulator
cgroup, set up cpuset.mems and exec() qemu only after that.

This basically reverts 7e72ac78 which was a workaround
for kernel bug. This bug was apparently fixed because I've tested
this successfully with recent kernel.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

This reverts commit f1d65853.

Turns out, this caused a regression. There is this (perhaps less
known) semantic of virDomainAttachDevice() where if the device
the API is trying to attach is a CDROM/floppy that is already in
the domain the attach request is handled as 'change the media in
the drive'.

We have a better fix anyways.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

This tries to fix the same problem as f1d65853 but it's doing
so in a less invasive way.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

Unit number 7 is kind of special. It's reserved for SCSI
controller. The comment in virDomainSCSIDriveAddressIsUsed()
summarizes that pretty nicely. Libvirt would never generate
such address.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>