The spiceMigration flag will never be true if there is no SPICE graphics
configured for the domain.

https://bugzilla.redhat.com/show_bug.cgi?id=1151723Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Otherwise migration during which we didn't send client_migrate_info QMP
command will get stuck waiting for SPICE migration to finish if libvirtd
sent the QMP command in a previous migration attempt.

Broken by bd7c8a69.

https://bugzilla.redhat.com/show_bug.cgi?id=1151723Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

People debugging guest OS boot processes and reported that
the default 128 KB size is too small to capture an entire
boot up sequence. Increase the default size to 2 MB which
should allow capturing a full boot up even with verbose
debugging.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently virtlogd has a hardcoded max file size of 128kb
and max of 3 backups. This adds two new config parameters
to /etc/libvirt/virtlogd.conf to let these be customized.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Support for SMP topology was added by qemu commit dc6b1c09849484fbbc50
prior to 0.12.0, our minimum supported qemu version.

$ git describe --tags dc6b1c09849484fbbc50803307e4c7a3d81eab62
v0.11.0-rc0-449-gdc6b1c0
$ git describe --tags --contains dc6b1c09849484fbbc50803307e4c7a3d81eab
v0.12.0-rc0~1477

After 27726d8c a privateData is allocated in
virDomainHostdevDefAlloc(). However, the counter part - freeing
them in Free() is missing which leads to the following memory
leak:

==6489== 24 bytes in 1 blocks are definitely lost in loss record 684 of 1,003
==6489==    at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==6489==    by 0x54B7C94: virAllocVar (viralloc.c:560)
==6489==    by 0x5517BE6: virObjectNew (virobject.c:193)
==6489==    by 0x1B400121: qemuDomainHostdevPrivateNew (qemu_domain.c:798)
==6489==    by 0x5557B24: virDomainHostdevDefAlloc (domain_conf.c:2152)
==6489==    by 0x5575578: virDomainHostdevDefParseXML (domain_conf.c:12709)
==6489==    by 0x5582292: virDomainDefParseXML (domain_conf.c:16995)
==6489==    by 0x5583C98: virDomainDefParseNode (domain_conf.c:17470)
==6489==    by 0x5583B07: virDomainDefParse (domain_conf.c:17417)
==6489==    by 0x5583B95: virDomainDefParseFile (domain_conf.c:17441)
==6489==    by 0x55A3F24: virDomainObjListLoadConfig (virdomainobjlist.c:465)
==6489==    by 0x55A43E6: virDomainObjListLoadAllConfigs (virdomainobjlist.c:596)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Add a new capability for the -display command line option, which has
been present since QEMU 1.0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Libxl is the last user and I don't have the toolchain prepared to
compile the libxl driver. Move it to the libxl driver to avoid having to
refactor the code.

Few arguments of the function are not necessary any more which leads to
some cleanups. The 'uri' argument had a stray ATTRIBUTE_UNUSED.

The impls are identical and I don't have a reasonable idea where to
extract it.

This also kills yet another use of virDomainLiveConfigHelperMethod.

Use a VIR_ prefix even when it's a local helper macro. It will be later
synced with the LXC implementation.

The new package for the virt-admin binary is libvirt-admin.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Currently, we have libvirt-client library which serves as a
collection point for all the libraries and client binaries we
have. Therefore we have couple of silly dependencies, for
instance libvirt-daemon depends on libvirt-client. Only because
the shared library is in the client package.
To solve this, new package libvirt-libs is introduced where all
the libraries are going to live. The client package is then set
to depend on this new package, just like the rest of packages
that suffer the same problem.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is just a convenience method for discarding a list of filters instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Provide a separate method to free a logging filter object. This will come handy
once a method to create an individual logging filter object is introduced.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This is just a convenience method for discarding a list of outputs instead of
using a 'for' loop everywhere. It is safe to pass -1 as the number of elements
in the list as well as passing NULL as list reference.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Provide a separate method to free a logging output object. This will come handy
once a method to create an individual logging output object is introduced.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Same as with outputs; since the operations will be further divided into smaller
tasks, creating a filter will become a separate operation that will return
a reference to a newly created filter.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Right now, we define outputs one after another. However, the correct flow
should be to define a set of outputs as a whole unit. Therefore each output
should be first created, placed into an array/list and the list will be
defined. Output creation should be a separate operation, so an output will be
returned by a reference. From that perspective, it makes perfect sense to
only store pointers to actual outputs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In this particular case, reset is meant as clearing the whole list of
outputs/filters, not resetting it to a predefined default setting. Looking at
it from that perspective, returning the number of records removed doesn't help
the caller in any way (not that any of the callers would actually check for
it). Well, callers could detect an error from the number of successfully
removed records, but the only thing that can fail in virLogReset is force
closing a file descriptor in which case the error isn't propagated back to
virLogReset anyway. Conclusion: there is no practical use for having a return
type of 'int' rather than 'void' in this case.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Due to the way the hardware works, KVM on ppc64 always requires
memory locking; however, that is not the case for non-KVM ppc64
guests, eg. ppc64 guests that are running on x86_64 with TCG.

Only require memory locking for ppc64 guests if they are using
KVM or, as it's the case for all architectures, they have host
devices assigned using VFIO.

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

Fix mingw build regarding rpl_{printf,scanf} symbols.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

For type='ethernet' interfaces only.

(This patch had been pushed earlier in
commit 0b4645a7, but was reverted in
commit 84d47a3c because it had been
accidentally pushed during the freeze for release 2.0.0)

(This patch had been pushed earlier in
commit cd5c9f21, but was reverted in
commit 1549f168 because it had been
accidentally pushed during the freeze for release 2.0.0)

This will apply to any IP address setting that uses
virNetDevIPInfoAddToDev() (which so far is only the guest-side of LXC
type='ethernet' interfaces).

(This patch had been pushed earlier in
commit cb20f989, but was reverted in
commit cba06aea because it had been
accidentally pushed during the freeze for release 2.0.0)

This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:

    <interface type='ethernet'>
      <mac address='00:16:3e:0f:ef:8a'/>
      <source>
        <ip address='192.168.122.12' family='ipv4'
            prefix='24' peer='192.168.122.1'/>
        <ip address='192.168.122.13' family='ipv4' prefix='24'/>
        <route family='ipv4' address='0.0.0.0'
               gateway='192.168.122.1'/>
        <route family='ipv4' address='192.168.124.0' prefix='24'
               gateway='192.168.124.1'/>
      </source>
    </interface>

In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types if needed, and 2) we can retain the info
when set to an invalid interface type all the way through to
validation and report a proper error, rather than just ignoring it
(which is currently what happens for many other type-specific
settings).

(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).

(This patch had been pushed earlier in
commit fe6a7789, but was reverted in
commit d6584565 because it had been
accidentally pushed during the freeze for release 2.0.0)

The peer attribute is used to set the property of the same name in the
interface IP info:

  <interface type='ethernet'>
    ...
    <ip family='ipv4' address='192.168.122.5'
        prefix='32' peer='192.168.122.6'/>
    ...
  </interface>

Note that this element is used to set the IP information on the
*guest* side interface, not the host side interface - that will be
supported in an upcoming patch.

(This patch now has quite a history: it was originally pushed in
commit 690969af, which was subsequently reverted in commit 1d14b13f,
then reworked and pushed (along with a lot of other related/supporting
patches) in commit 93135abf; however *that* commit had been
accidentally pushed during dev. freeze for release 2.0.0, so it was
again reverted in commit f6acf039).
Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: NLaine Stump <laine@laine.org>

This patch takes the code out of
lxcContainerRenameAndEnableInterfaces() that adds all IP addresses and
IP routes to the interface, and puts it into a utility function
virNetDevIPInfoAddToDev() in virnetdevip.c so that it can be used by
anyone.

One small change in functionality -
lxcContainerRenameAndEnableInterfaces() previously would add all IP
addresses to the interface while it was still offline, then set the
interface online, and then add the routes. Because I don't want the
utility function to set the interface online, I've moved this up so
the interface is first set online, then IP addresses and routes are
added. This is the same order that the network service from
initscripts (in ifup-ether) does it, so it shouldn't pose any problem
(and hasn't, in the tests that I've run).

(This patch had been pushed earlier in commit
f1e0d0da, but was reverted in commit
05eab475 because it had been
accidentally pushed during the freeze for release 2.0.0)

Introduce a helper to help determine if a disk src could be possibly used
for a disk secret... Going to need this for hot unplug.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

For a luks device, allow the configuration of a specific cipher to be
used for encrypting the volume.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add parse and format of the luks/passphrase secret including tests for
volume XML parsing.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In order to use more common code and set up for a future type, modify the
encryption secret to allow the "usage" attribute or the "uuid" attribute
to define the secret. The "usage" in the case of a volume secret would be
the path to the volume as dictated by the backwards compatibility brought
on by virStorageGenerateQcowEncryption where it set up the usage field as
the vol->target.path and didn't allow someone to provide it. This carries
into virSecretObjListFindByUsageLocked which takes the secret usage attribute
value from from the domain disk definition and compares it against the
usage type from the secret definition. Since none of the code dealing
with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
cosmetic change. The real usage comes in a future path where the encryption
is expanded to be a luks volume and the secret will allow definition of
the usage field.

This code will make use of the virSecretLookup{Parse|Format}Secret common code.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a new secret type known as "passphrase" - it will handle adding the
secret objects that need a passphrase without a specific username.

The format is:

   <secret ...>
     <uuid>...</uuid>
     ...
     <usage type='passphrase'>
       <name>mumblyfratz</name>
     </usage>
   </secret>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since the virSecretDefParseUsage ensures each of the fields is present,
no need to check during virSecretDefFormatUsage (also virBufferEscapeString
is a no-op with a NULL argument).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

    This replicates the metadata field found in the domain configuration
    and adds it to the network configuration XML.

This is a generic version of virDomainDefMetadataSanitize() - the same
functionality is now needed for network metadata.

I can't think of any good reason to do either of those, and having the
examples there will just lead to unusable patch emails from people who
can't be bothered to read the entire page.