Also note that it's archived, because it's definitely
not maintained anymore.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

We've had no tarballs for almost 10 years.

Give up and delete the commented out links to them.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

To avoid bugs with mixing of g_object_(ref|unref) vs
virObject(Ref|Unref), we want every virObject to be
a GObject.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Memory allocated using g_object_new must never be released using
VIR_FREE/g_free because g_object_new uses a special allocation
strategy internally.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The ref count will be private to the GObject base class
and we must not peek at it, even for debugging messages.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

GObject has an arbitrary limit on the object struct size of 0xffff
bytes. It is expected that any large fields be separately allocated.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

To prepare for a conversion to GObject, we need virObjectUnref
to have the same API design as g_object_unref, which means it
needs to be void.

A few places do actually care about the return value though,
and in these cases a thread local flag is used to determine
if the dispose method was invoked.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Some, but not all, of the monitor event handlers check
the virObjectUnref return value to see if the domain
was disposed.

It should not be possible for this to happen, since
the function already holds a lock on the domain and
has only just acquired an extra reference on the
domain a few lines earlier.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Upon migration with disks, libvirt determines if each disk exists
on the destination and tries to pre-create missing ones. Well,
NVMe disks can't be pre-created, but they can be checked for
presence.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1823639Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The heading overline should only be used for the overall document title,
any subsequent headings should be underline only.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

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

According to the context, here we are checking net->downscript's validity,
Signed-off-by: NLiao Pingfang <liao.pingfang@zte.com.cn>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJaak Ristioja <jaak@ristioja.ee>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

If built without attr support removing any image will trigger
 qemuBlockRemoveImageMetadata (the one that emits the warning)
   -> qemuSecurityMoveImageMetadata
     -> virSecurityManagerMoveImageMetadata
       -> virSecurityDACMoveImageMetadata
         -> virSecurityDACMoveImageMetadataHelper
           -> virProcessRunInFork (spawns subprocess)
             -> virSecurityMoveRememberedLabel

In there due to !HAVE_LIBATTR virFileGetXAttrQuiet will return
ENOSYS and from there the chain will error out.

That is wrong and looks like:
  libvirtd[6320]: internal error: child reported (status=125):
  libvirtd[6320]: Unable to remove disk metadata on vm testguest from
  /var/lib/uvtool/libvirt/images/testguest.qcow (disk target vda)

This change makes virSecurityDACMoveImageMetadataHelper and
virSecuritySELinuxMoveImageMetadataHelper accept that
error code gracefully and in that sense it is an extension of:
5214b2f1 "security: Don't skip label restore on file systems lacking XATTRs"
which does the same for other call chains into the virFile*XAttr functions.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NChen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Support downscript for booting vm,
and hotunplug interface device.
Signed-off-by: NChen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

https://gitlab.com/libvirt/libvirt/-/issues/13

Add support for downscript:

<interface type='ethernet'>
    <mac address='00:11:22:33:44:55'/>
    <script path='/etc/qemu-ifup'/>
    <downscript path='/path/to/my/downscript'/>
</interface>
Signed-off-by: NChen Hanxiao <chen_han_xiao@126.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

With newer pycodestyle 2.6.0 (which is part of flake8-3.8.2) reports
the following pep violation during syntax-check:

../scripts/check-remote-protocol.py:95:9: E741 ambiguous variable name 'l'
    for l in err.strip().split("\n")

On all the distros we test on, this hasn't occurred yet, but with the
future update of flake8 it likely would. The fix is easy, just name the
variable appropriately.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The stepping range (10-11) is likely incomplete. QEMU uses 10 and the
CPUID data for Cooperlake show 11. We will update the range if needed
once more details about he CPU are available.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Commit v3.10.0-182-g237f045d ("qemu: Ignore fallback CPU attribute
on reconnect") forced CPU 'fallback' to ALLOW, regardless of user
choice. This fixed a situation in which guests created with older
Libvirt versions, which used CPU mode 'host-model' in runtime, would
fail to launch in a newer Libvirt if the fallback was set to FORBID.
This would lead to a scenario where the CPU was translated to 'host-model'
to 'custom', but then the FORBID setting would make the translation
process fail.

PSeries can operate with 'host-model' in runtime due to specific PPC64
mechanics regarding compatibility mode. The update() implementation of
the cpuDriverPPC64 driver is a NO-OP if CPU mode is 'host-model', and
the driver does not implement translate(). The commit mentioned above
is causing PSeries guests to get their 'fallback' setting to ALLOW,
overwriting user choice, exposing a design problem in
qemuProcessRefreshCPU() - for PSeries guests, handling 'host-model'
as it is being done does not apply.

All other cpuArchDrivers implements update() and changes guest mode
to VIR_CPU_MODE_CUSTOM, meaning that PSeries is currently the only
exception to this logic. Let's make it official.

https://bugzilla.redhat.com/show_bug.cgi?id=1660711Suggested-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200525123945.4049591-2-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The host CPU related info stored in the capabilities cache is no longer
valid after the host CPU changes. This is not a frequent situation in
real world, but it can easily happen in nested scenarios when a disk
image is started with various CPUs.

https://bugzilla.redhat.com/show_bug.cgi?id=1778819Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The purpose of this function is to give a short description that would
be change when a host CPU is replaced with a different model. This is
currently implemented by reading /proc/cpuinfo.

It should be implemented for all architectures for which the QEMU driver
stores host CPU data in the capabilities cache. In other words for archs
that support host-model CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use automatic cleanup on qemuProcessUpdateCPU and the functions called
by it.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-5-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Use automatic cleanup of variables.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-4-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Use automatic cleanup of variables.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-3-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Use automatic cleanup of variables.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20200522195620.3843442-2-danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NHan Han <hhan@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Currently the value for an enum is only emitted if it is a plain
string. If the enum is an integer or hex value, or a complex code block,
it is omitted from the API build. This fixes that by emitting the raw
value if no string value is present.

With this change:

  <macro name='LIBVIR_CHECK_VERSION'
         file='libvirt-common'
         params='major,minor,micro'>
  <macro name='LIBVIR_VERSION_NUMBER'
         file='libvirt-common'>
  <macro name='VIR_COPY_CPUMAP'
         file='libvirt-domain'
         params='cpumaps,maplen,vcpu,cpumap'>
  ...snip...

  <macro name='LIBVIR_CHECK_VERSION'
         file='libvirt-common'
         params='major,minor,micro'
         raw='((major) * 1000000 + (minor) * 1000 + (micro) <= LIBVIR_VERSION_NUMBER)'>
  <macro name='LIBVIR_VERSION_NUMBER'
         file='libvirt-common'
         raw='6004000'>
  <macro name='VIR_COPY_CPUMAP'
         file='libvirt-domain'
         params='cpumaps,maplen,vcpu,cpumap'
         raw='memcpy(cpumap, VIR_GET_CPUMAP(cpumaps, maplen, vcpu), maplen)'>
  ...snip...
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>