It's obvious that unsigned long long is 64 bit and also our web page
generator would misplace the comment after the return value due to the
way it's parsing them.

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

 - Add a news entry
 - Update driver's page with information about the new
   vgaconf attribute and provide usage example; while here,
   fix a grammar mistake
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Replace the switch statement with a simpler if statement. This also
removes the fallthrough path that coverity was complaining about.

Combine and "clean up" a bit two places that are removing the vport

Commit id '95ea171b' was a bit too aggressive in removing the if (obj)
check since cleanup is reachable after Unlock and obj = NULL.

vcpu 0 must be always enabled and non-hotpluggable, thus you can't
modify it using the vcpu hotplug APIs. Disallow it so that users can't
create invalid configurations.

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

The default conf files, for example libvirtd.conf, virtlockd.conf, and
virtlogd.conf, should be located under the directory "/etc/libvirt" when
root as root, rather than "/etc". When run as non-root, the configuration
files should be located under "$XDG_CONFIG_HOME/libvirt/", rather than
"XDG_CONFIG_HOME".
Signed-off-by: NLily Zhu <lizhu@redhat.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

When one has a non-blocking stream and aborts or finishes it without
removing the callback, any event loop invocation will trigger that
callback, but it cannot be removed any more.  We cannot remove the
callback automatically from virStream{Abort,Finish} functions due to
forward-compatibility.  So let's at least document this behaviour,
because it is not easy to find out the reason for.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Resolves a bug in domxml-to-native command option, so that the
following command displays the help information correctly:
'virsh domxml-to-native --help'.
Signed-off-by: NDaniel Liu <srwx4096@gmail.com>
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

Add support for vgaconf driver configuration. In domain xml it looks like
this:

  <video>
    <driver vgaconf='io|on|off'>
    <model .../>
  </video>

It was added with bhyve gop video in mind to allow users control how the
video device is exposed to the guest, specifically, how VGA I/O is
handled.

One can refer to the bhyve manual page to get more detailed description
of the possible VGA configuration options:

https://www.freebsd.org/cgi/man.cgi?query=bhyve&manpath=FreeBSD+12-current

The relevant part could be found using the 'vgaconf' keyword.

Also, add some tests for this new feature.
Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This reverts commit 70c9b442.

This commit breaks existing aarch64 machvirt configs with:

    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>

Which fails with:

error: Failed to start domain fedora25-aarch64
error: internal error: process exited while connecting to monitor:
2017-06-26T13:55:34.726293Z qemu-system-aarch64: -chardev pty,id=charserial0:
char device redirected to /dev/pts/5 (label charserial0)
2017-06-26T13:55:34.782121Z qemu-system-aarch64: -device
isa-serial,chardev=charserial0,id=serial0: No 'ISA' bus found for device
'isa-serial'

Commit 54fa1b44 added virDomainDeviceInfo::loadparm
and updated virDomainDeviceInfoClear() accordingly, but
omitted the necessary virDomainDeviceInfoCopy() changes.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Despite being a generated file, HACKING has been tracked in
the git repository along with actual source files. As far as
I'm aware, it's the only generated file for which that happens.

Times and times again, people[1] have committed changes to
the source file without refreshing the generated copy at the
same time.

The rationale for tracking the generated file is to help out
people who just cloned the git repository looking to contribue;
however, README-hacking already contains enough information to
get perspective contributors to a place where they can simply
look at docs/hacking.html instead.

[1] Mostly me, to be honest
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The use of 'git send-email' is described in detail in the
contributor guidelines (docs/hacking.html), which are
mentioned in docs/contribute.html, the non-local version
of which is in turn mentioned in README.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

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

People looking to help out should really go through the
contributor guidelines when getting started, so the more
documents point to them the better.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

While qemuProcessIncomingDefNew takes an fd argument and stores it in
qemuProcessIncomingDef structure, the caller is still responsible for
closing the file descriptor.

Introduced by commit v1.2.21-140-ge7c6f457.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Commit 79c1900f changed docs/hacking.html.in, but *of
course* I forgot once again to update the text-only version
of the file at the same time.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

For the benefit of first time contributors, we point out that 'git
send-email' might have to be installed separately; however, we omit
the fact that some configuration will likely be needed before it
can successfully deliver patches to the mailing list.

Some minor tweaks to the existing contents are included as well.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Since qemu commit 3ef6c40ad0b it can fail if trying to hotplug a
disk that is not qcow2 despite us saying it is. We need to error
out in that case.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

If a remote call fails during event registration (more than likely from
a network failure or remote libvirtd restart timed just right), then when
calling the virObjectEventStateDeregisterID we don't want to call the
registered @freecb function because that breaks our contract that we
would only call it after succesfully returning.  If the @freecb routine
were called, it could result in a double free from properly coded
applications that free their opaque data on failure to register, as seen
in the following details:

    Program terminated with signal 6, Aborted.
    #0  0x00007fc45cba15d7 in raise
    #1  0x00007fc45cba2cc8 in abort
    #2  0x00007fc45cbe12f7 in __libc_message
    #3  0x00007fc45cbe86d3 in _int_free
    #4  0x00007fc45d8d292c in PyDict_Fini
    #5  0x00007fc45d94f46a in Py_Finalize
    #6  0x00007fc45d960735 in Py_Main
    #7  0x00007fc45cb8daf5 in __libc_start_main
    #8  0x0000000000400721 in _start

The double dereference of 'pyobj_cbData' is triggered in the following way:

    (1) libvirt_virConnectDomainEventRegisterAny is invoked.
    (2) the event is successfully added to the event callback list
        (virDomainEventStateRegisterClient in
        remoteConnectDomainEventRegisterAny returns 1 which means ok).
    (3) when function remoteConnectDomainEventRegisterAny is hit,
        network connection disconnected coincidently (or libvirtd is
        restarted) in the context of function 'call' then the connection
        is lost and the function 'call' failed, the branch
        virObjectEventStateDeregisterID is therefore taken.
    (4) 'pyobj_conn' is dereferenced the 1st time in
        libvirt_virConnectDomainEventFreeFunc.
    (5) 'pyobj_cbData' (refered to pyobj_conn) is dereferenced the
         2nd time in libvirt_virConnectDomainEventRegisterAny.
    (6) the double free error is triggered.

Resolve this by adding a @doFreeCb boolean in order to avoid calling the
freeCb in virObjectEventStateDeregisterID for any remote call failure in
a remoteConnect*EventRegister* API. For remoteConnect*EventDeregister* calls,
the passed value would be true indicating they should run the freecb if it
exists; whereas, it's false for the remote call failure path.

Patch based on the investigation and initial patch posted by
fangying <fangying1@huawei.com>.

The function to check if -chardev is supported by QEMU was written a
long time ago, where adding chardevs did not make sense on the fixed ARM
platforms.  Since then, we now have a general purpose virt platform,
which should support plugging in any device over PCIe which is supported
in a similar fashion on x86.
Signed-off-by: NChristoffer Dall <cdall@linaro.org>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The option allows someone to run domain-to-native on already existing
domain without the need of supplying their XML.  It is basically
wrapper around 'virsh dumpxml  | virsh domxml-to-native /dev/stdin'.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=835476Signed-off-by: NDaniel Liu <srwx4096@gmail.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

As it turns out the volume create, build, and refresh path was not peeking
at the meta data, so immediately after a create operation the value displayed
for capacity was still incorrect. However, if a pool refresh was done the
correct value was fetched as a result of a meta data peek.

The reason is it seems historically if the file type is RAW then peeking
at the file just took the physical value for the capacity. However, since
we know if it's an encrypted file, then peeking at the meta data will be
required in order to get a true capacity value.

So check for encryption in the source and if present, use the meta data
in order to fill in the capacity value and set the payload_offset.

Similarly to commit 5da28cc3 this check
actually does not make sense since duplicate WWNs are used e.g. when
multipathing disks.

This reverts commit 780fe4e4.

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

When fetching stats for a vhost-user type of interface, we run
couple of ovs-vsctl commands and parse their output. However, not
all stats exist at all times, for instance "rx_dropped" or
"tx_errors" can be missing. Thing is, we ask for a bulk of
statistics and if one of them is missing an error is reported
instead of returning the rest. Since we ignore errors, we fail to
set statistics. Fix this by asking for each piece alone.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Split out the object fetch in virObject{Lock|Unlock} into a helper
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Alter to use more recent formatting guidelines
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Commit 5c54d29a forgot to do that when moving the only function
using it and it broke the build on some platforms.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Our commit e13e8808 was way too generic. Currently, virtlogd is
used only for chardevs type of file and nothing else. True, we
must not relabel the path in this case, but we have to in all
other cases. For instance, if you want to have a physical console
attached to your guest:

    <console type='dev'>
      <source path='/dev/ttyS0'/>
      <target type='virtio' port='1'/>
    </console>

Starting such domain fails because qemu doesn't have access to
/dev/ttyS0 because we haven't relabelled the path.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>