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

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

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

This macro is being used as an inline body after an if and might get
pretty confusing.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Rule sc_prohibit_newline_at_end_of_diagnostic for syntax-check does
check for passing strings ending with '\n' two lines after known
functions.  This is, of course subject to false positives, so for the
sake of future changes, trick that syntax-check by adding one more line
with a comment.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

A previous commit introduced use of locking with invocation
of iptables in the viriptables.c module

  commit ba95426d
  Author: Serge Hallyn <serge.hallyn@ubuntu.com>
  Date:   Fri Nov 1 12:36:59 2013 -0500

    util: use -w flag when calling iptables

This only ever had effect with the virtual network driver,
as it was not wired up into the nwfilter driver. Unfortunately
in the firewall refactoring the use of the -w flag was
accidentally lost.

This patch introduces it to the virfirewall.c module so that
both the virtual network and nwfilter drivers will be using
it. It also ensures that the equivalent --concurrent flag
to ebtables is used.

Since QEMU 1.2.0, we switched to QMP probing instead of parsing -help
(and other commands, such as -cpu ?) output. However, if QMP probing
failed, we still tried starting QEMU with various options and parsing
the output, which was guaranteed to fail because the output changed.
Let's just refuse parsing -help for QEMU >= 1.2.0.

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

We used to set migration capabilities only when a user asked for them in
flags. This is fine when migration succeeds since the QEMU process is
killed in the end but in case migration fails or if it's cancelled, some
capabilities may remain turned on with no way to turn them off. To fix
that, migration capabilities have to be turned on if requested but
explicitly turned off in case they were not requested but QEMU supports
them.

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

Recent commit 12bd207e fixed few
VSH_OT_STRING options that should've been VSH_OT_DATA.  That lead me to
this commit that enforces people to check that newly added options have
proper type.  Thanks to virsh erroring out with error message, this will
immediately show up in 'make check' thanks to our virsh-synopsis test.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Even though vshCmddefOptParse() tried returning -1 if there was an
optional option specification that preceded a required one, it failed to
check that for boolean type options and options with VSH_OFLAG_REQ_OPT
flag set.  On the other hand, it makes sense that VSH_OT_ARGV is
specified at the end of the option list.

Returning -1 enforces the proper ordering thanks to virsh-synopsis test
in 'make check'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

According to comments in parsing functions, optional options should be
specified *after* required ones.  It makes sense and help output looks
cleaner.  The only exceptions are options with type == VSH_OT_ARGV.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Rather than just picking the first CD (or failing that, HDD) we come
across, if the user has picked a boot device ordering with <boot
order=''>, respect that (and just try to boot the lowest-index device).

Adds two sets of tests to bhyve2xmlargv; 'grub-bootorder' shows that we
pick a user-specified device over the first device in the domain;
'grub-bootorder2' shows that we pick the first (lowest index) device.

When user calls setmem on a running LXC machine, we do update its cgroup
entry, however we neither update domain's runtime XML nor
we update our internal structures and this patch fixes it.

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

The API docs generators were broken by the header file
re-organization. Specifically

 * html/libvirt-libvirt.html was empty (and should be deleted)
 * Makefile.am didn't install html/libvirt-libvirt-*.html
 * hvsupport.html was mostly empty
 * sitemap.html.in didn't list the new html/*.html files

Commit 6e5c79a1 tried to fix deadlock between nwfilter{Define,Undefine}
and starting of guest, but this same deadlock exists for
updating/attaching network device to domain.

The deadlock was introduced by removing global QEMU driver lock because
nwfilter was counting on this lock and ensure that all driver locks are
locked inside of nwfilter{Define,Undefine}.

This patch extends usage of virNWFilterReadLockFilterUpdates to prevent
the deadlock for all possible paths in QEMU driver. LXC and UML drivers
still have global lock.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1143780Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

In one of my previous patches (3a3c3780) I've tried to fix the
problem of nvram path disappearing on a domain that's been
started and shut down again. I fixed this by explicitly saving
domain's config file.  However, I did a bit of clumsy without
realizing we have a transient domains for which we don't save the
config file. Hence, any domain using UEFI became persistent.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As I was reviewing bhyve commits, I've noticed qemuxml2argvtest
failing for some test cases. This is not bug in qemu driver code
rather than being unable to load qemuxml2argvmock on non-Linux
platforms. For instance:

318) QEMU XML-2-ARGV numatune-memnode
... libvirt:  error : internal error: NUMA node 0 is unavailable
FAILED

Rather than disabling qemuxml2argvtest on BSD (we do compile qemu
driver there) disable only those test cases which require mocking.
To achieve that goal new DO_TEST_LINUX() macro is introduced which
invokes the test case on Linux only and consume arguments on other
systems.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Introduce a 'managed' attribute to allow libvirt to decide whether to
delete a vHBA vport created via external means such as nodedev-create.
The code currently decides whether to delete the vHBA based solely on
whether the parent was provided at creation time. However, that may not
be the desired action, so rather than delete and force someone to create
another vHBA via an additional nodedev-create allow the configuration of
the storage pool to decide the desired action.

During createVport when libvirt does the VPORT_CREATE, set the managed
value to YES if not already set to indicate to the deleteVport code that
it should delete the vHBA when the pool is destroyed.

If libvirtd is restarted all the memory only state was lost, so for a
persistent storage pool, use the virStoragePoolSaveConfig in order to
write out the managed value.

Because we're now saving the current configuration, we need to be sure
to not save the parent in the output XML if it was undefined at start.
Saving the name would cause future starts to always use the same parent
which is not the expected result when not providing a parent. By not
providing a parent, libvirt is expected to find the best available
vHBA port for each subsequent (re)start.

At deleteVport, use the new managed value to decide whether to execute
the VPORT_DELETE.  Since we no longer save the parent in memory or in
XML when provided, if it was not provided, then we have to look it up.

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

Introduce the ability to save a configuration of a persistent configuration
that may be changed by storage pool backend activity, such as start or stop

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

Passing a copy of the storage pool adapter to a function just changes the
copy of the fields in the particular function and then when returning to
the caller those changes are discarded.  While not yet biting us in the
storage clean-up case, it did cause an issue for the fchost storage pool
startup case, createVport.  The issue was at startup, if no parent is found
in the XML, the code will search for the 'best available' parent and then
store that in the in memory copy of the adapter.  Of course, in this case
it was a copy, so when returning to the virStorageBackendSCSIStartPool that
change was discarded (or lost) from the pool->def->source.adapter which
meant at shutdown (deleteVport), the code assumed no adapter was passed
and skipped the deletion, leaving the vHBA created by libvirt still defined
requiring an additional stop of a nodedev-destroy to remove.

Adjusted the createVport to take virStoragePoolDefPtr instead of the
adapter copy. Then use the virStoragePoolSourceAdapterPtr when processing.
A future patch will need the 'def' anyway, so this just sets up for that.

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

The existing code assumed that the configuration of a 'parent' attribute
was correct for the createVport path. As it turns out, that may not be
the case which leads errors during the deleteVport path because the
wwnn/wwpn isn't associated with the parent.

With this change the following is reported:

error: Failed to start pool fc_pool_host3
error: XML error: Parent attribute 'scsi_host4' does not match parent 'scsi_host3' determined for the 'scsi_host16' wwnn/wwpn lookup.

for XML as follows:

  <pool type='scsi'>
    <name>fc_pool</name>
    <source>
      <adapter type='fc_host' parent='scsi_host4' wwnn='5001a4aaf3ca174b' wwpn='5001a4a77192b864'/>
    </source>

Where 'nodedev-dumpxml scsi_host16' provides:

  <device>
    <name>scsi_host16</name>
    <path>/sys/devices/pci0000:00/0000:00:04.0/0000:10:00.0/host3/vport-3:0-11/host16</path>
    <parent>scsi_host3</parent>
    <capability type='scsi_host'>
      <host>16</host>
      <unique_id>13</unique_id>
      <capability type='fc_host'>
        <wwnn>5001a4aaf3ca174b</wwnn>
        <wwpn>5001a4a77192b864</wwpn>
...

The patch also adjusts the description of the storage pool to describe the
restrictions.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

If a 'parent' attribute is provided for the fchost, then at startup
time check to ensure it is a vport capable scsi_host. If the parent
is not vport capable, then disallow the startup. The following is the
expected results:

error: Failed to start pool fc_pool
error: XML error: parent 'scsi_host2' specified for vHBA is not vport capable

where the XML for the fc_pool is:

    <pool type='scsi'>
      <name>fc_pool</name>
      <source>
        <adapter type='fc_host' parent='scsi_host2' wwnn='5001a4aaf3ca174b' wwpn='5001a4a77192b864'/>
      </source>
...

and 'scsi_host2' is not vport capable.

Providing an incorrect parent and a correct wwnn/wwpn could lead to
failures at shutdown (deleteVport) where the assumption is the parent
is for the fchost.

NOTE: If the provided wwnn/wwpn doesn't resolve to an existing scsi_host,
      then we will be creating one with code (virManageVport) which
      assumes the parent is vport capable.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

reported here: http://www.redhat.com/archives/libvir-list/2014-November/msg00327.html

I could have just remove bool supportMaxOptions variable, but
if I had do this, we could not check anymore if the nparams variable is
superior to QEMU_NB_BLOCK_IO_TUNE_PARAM_MAX.

v2: change following this proposal:
http://www.redhat.com/archives/libvir-list/2014-November/msg00379.html

Fix for this: http://www.redhat.com/archives/libvir-list/2014-November/msg00324.htmlSigned-off-by: NMatthias Gatto <matthias.gatto@outscale.com>

This enables booting interactive GRUB menus (e.g. install CDs) with
libvirt-bhyve.

Caveat: A terminal other than the '--console' option to 'virsh start'
(e.g. 'cu -l /dev/nmdm0B -s 115200') must be used to connect to
grub-bhyve because the bhyve loader path is synchronous and must occur
before the VM actually starts.

Changing the bhyveProcessStart logic around to accommodate '--console'
for interactive loader use seems like a significant project and probably
not worth it, if UEFI/BIOS support for bhyve is "coming soon."

Additionally, make the <bootloader> tag optional (for bhyveload with
custom arguments) (also, matches the actual parser).

We still default to bhyveloader(1) if no explicit bootloader
configuration is supplied in the domain.

If the /domain/bootloader looks like grub-bhyve and the user doesn't
supply /domain/bootloader_args, we make an intelligent guess and try
chainloading the first partition on the disk (or a CD if one exists,
under the assumption that for a VM a CD is likely an install source).

Caveat: Assumes the HDD boots from the msdos1 partition. I think this is
a pretty reasonable assumption for a VM. (DrvBhyve with Bhyveload
already assumes that the first disk should be booted.)

I've tested both HDD and CD boot and they seem to work.

virStorageFileBackendGlusterInit did not check nhosts.

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

Use the device type name if we know it instead of its number,
even if we can't hotplug it:
qemuMonitorJSONAttachCharDevCommand:6094 : operation failed: Unsupported
char device type '10'

virDomainChrSourceDefIsEqual should return 'true' for
identical SPICEVMC chardevs, and those that have no source
specification.

After this change, a failed hotplug no longer leaves a stale
pointer in the domain definition.

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

If the memory mode is specified as 'strict' and with one node, we
get the following error when starting domain.

error: Unable to write to '$cgroup_path/cpuset.mems': Device or resource busy

XML is configured with numatune as follows:
  <numatune>
    <memory mode='strict' nodeset='0'/>
  </numatune>

It's broken by Commit 411cea63
which moved qemuSetupCgroupForEmulator() before setting cpuset.mems
in qemuSetupCgroupPostInit.

Directory '$cgroup_path/emulator/' is created in qemuSetupCgroupForEmulator.
But '$cgroup_path/emulator/cpuset.mems' it not set and has a default value
(all nodes, such as 0-1). Then we setup '$cgroup_path/cpuset.mems' to the
nodemask (in this case it's '0') in qemuSetupCgroupPostInit. It must fail.

This patch makes '$cgroup_path/emulator/cpuset.mems' is set before
'$cgroup_path/cpuset.mems'. The action is similar with that in
qemuDomainSetNumaParamsLive.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

If the memory mode in numatune is not 'strict', we should not setup
cpuset.mems. Before commit 1a7be8c6
we have checked the memory mode in virDomainNumatuneGetNodeset. This
patch adds the check as before.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

If the memory mode in numatune is specified as 'preferred' with one node
(such as nodeset='0'), domain's memory is not all in node 0 absolutely.
Assumption that node 0 doesn't have enough memory, memory can be allocated
on node 1 when qemu process startup. Then if we set cpuset.mems to '0',
it may invoke OOM.

Commit 1a7be8c6 changed the former logic of
checking memory mode in virDomainNumatuneGetNodeset. This patch adds the
check as before.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

This patch fixes the following issues.

1)  When an invalid wwn is introduced, libvirt reports
    "Malformed wwn: %s". The template won't be replaced.

2)  "target" option for dompmsuspend and "xml" option for
    save-image-define are required options and should use
    VSH_OT_DATA instead of VSH_OT_STRING as an option type.

3)  A typo.
Signed-off-by: NHao Liu <hliu@redhat.com>

Coverity found out that commit cd490086 caused a possible NULL pointer
dereference.  This is due to the fact, that phyp_driver is NULL at the
time of closing the socket, instead of connection_data, which kept the
socket before the mentioned commit, could not be NULL.

However, internal_socket is still the local socket that can be
closed, even unconditionally, if we initialize it to -1.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>