instead of:

  virBufferAdd(buf, "arg1,");
  virBufferAdd(buf, "arg2");

lets have:

  virBufferAdd(buf, "arg1");
  virBufferAdd(buf, ",arg2");

Because it's better. Consider we want to add conditionally arg3.
With this change, it's simple:

  if (cond)
    virBufferAdd(buf, ",arg3");

with current code there might be a comma hanging at EOL.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

from virDomainDefPtr to virDomainObjPtr so that the function has
access to the other parts of the virDomainObjPtr. Take advantage of
this by removing the "priv" arg and retrieving it from the
virDomainObjPtr instead.

No functional change.

This error should only ever be seen by a developer anyway, but the
existing message made even less sense that this new version.

This is already set by virDomainPCIAddressSetAlloc().

For some reason the values of memballoon model are set using an
anonymous enum, making it impossible to perform nice tricks like
demanding there are cases for all possible values in a switch. This
patch turns the anonymous enum into virDomainMemballoonModel.

More occurences of repeatedly dereferencing the same pointer stored in
an array are replaced with the definition of a temporary pointer that
is then used directly. No functional change.

There's no functional change here. This pointer was just used so many
times that the extra long lines became annoying.

Commit id '5f2a1327' should have placed the data in the host source
def structure since that's also used by smartcard, redirdev, and rng in
order to provide a backend tcp channel.  The data in the private structure
will be necessary in order to provide the secret properly.

This also renames the previous names from "Chardev" to "ChrSource" for
the private data structures and API's

Change the virDomainChrDef to use a pointer to 'source' and allocate
that pointer during virDomainChrDefNew.

This has tremendous "fallout" in the rest of the code which mainly
has to change source.$field to source->$field.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than VIR_ALLOC of the virDomainChrDefPtr

Added a brief description of the VCPU states.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

This function is never called for VIR_DOMAIN_NET_TYPE_HOSTDEV,
and the dead code comment agrees.

Introduced by commit 1dcbef8a.

Put the comma at the end and trim it later for consistency.

When hotplugging networks with ancient QEMUs not supporting
QEMU_CAPS_NETDEV, we use space instead of a comma as the separator
between the network type and other options.

Except for "user", all the network types pass other options
and use up the first separator by the time we get to the section
that adds the alias (or vlan for QEMUs without CAPS_NETDEV).

Since the alias/vlan is mandatory, convert all preceding code to add
the separator at the end, removing the need to rewrite type_sep for
all types but NET_TYPE_USER.

Absent driver name attribute is invalid xml. Which in turn makes
unusable 'virsh edit' for example. The value does not make
much sense and ignored on input so nobody will hurt.

vz sdk supports setting serial number only for disk devices.
Getting serial upon cdrom(for example) is error however
setting is just ignored. Let's check for disk device
explicitly for clarity in both cases.

Setting serial number for other devices is ignored
with an info note just as before.

We need usual conversion from "" to NULL in direction
vz sdk -> libvirt, because "" is not valid for libvirt
and "" means unspecifiend in vz sdk which is NULL for libvirt.

Commit id '5f2a1327' missed this one.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

We should set localhost as vnc address in case of empty string.
Because Virtuozzo sets 0.0.0.0 as default vnc address.

The autoconf manual says we shouldn't be using this variable (and
some others) outside of Makefiles as it prevents users providing
their own prefix at the installation phase.

https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Installation-Directory-Variables.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

New line character in name of network is now forbidden because it
mess virsh output and can be confusing for users.  Validation of
name is done in network driver, after parsing XML to avoid
problems with disappeared network which was already created with
new-line char in name.

Closes-Bug: https://bugzilla.redhat.com/show_bug.cgi?id=818064Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

New util function virXMLCheckIllegalChars is now used to test if
parsed network contains illegal char '/' in it's name.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This new function can be used to check if e.g. name of XML
node don't contains forbidden chars like "/" or "\n".
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Modeled after the qemuDomainHostdevPrivatePtr (commit id '27726d8c'),
create a privateData pointer in the _virDomainChardevDef to allow storage
of private data for a hypervisor in order to at least temporarily store
secret data for usage during qemuBuildCommandLine.

NB: Since the qemu_parse_command (qemuParseCommandLine) code is not
expecting to restore the secret data, there's no need to add code
code to handle this new structure there.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a new qemu.conf variables to store the UUID for the secret that could
be used to present credentials to access the TLS chardev.  Since this will
be a server level and it's possible to use some sort of default, introduce
both the default and chardev logic at the same time making the setting of
the chardev check for it's own value, then if not present checking whether
the default value had been set.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

xlconfigtest expects the comma, don't clean it up even if there is
no target to write.

We only claim support for OSs that are still supported by the
respective vendors, which means anything older than Fedora 23
is out. Reword the comment a bit to highlight the criteria.

When converting a domain xml containing a CDROM device without
any attached source, don't add a target=(null) to the libxl config
disk definition: xen doesn't like it at all and would fail to start
the domain.

There was inconsistency between alias used to create tls-creds-x509
object and alias used to link that object to chardev while hotpluging.
Hotplug ends with this error:

  error: Failed to detach device from channel-tcp.xml
  error: internal error: unable to execute QEMU command 'chardev-add':
  No TLS credentials with id 'objcharchannel3_tls0'

In XML we have for example alias "serial0", but on qemu command line we
generate "charserial0".

The issue was that code, that creates QMP command to hotplug chardev
devices uses only the second alias "charserial0" and that alias is also
used to link the tls-creds-x509 object.

This patch unifies the aliases for tls-creds-x509 to be always generated
from "charserial0".
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Instead of typing the prefix every time we want to append parameters
to qemu command line use a variable that contains prefixed alias.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We need to make sure that the chardev is TCP.  Without this check we
may access different part of union and corrupt pointers.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

qemuDomainSecret{Disk|Hostdev}Prepare has a prototype that checks for
ATTRIBUTE_NONNULL(1) for 'conn'.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Missing the option to set verify-peer to yes
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

qemuProcessPrepareDomain has no need to fetch/unref the cfg, so remove it.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The code is entirely correct, but it still managed to trip me
up when I first ran into it because I did not realize right away
that VIR_PCI_CONNECT_TYPES_ENDPOINT was not a single flag, but
rather a mask including both VIR_PCI_CONNECT_TYPE_PCI_DEVICE and
VIR_PCI_CONNECT_TYPE_PCIE_DEVICE.

In order to save the next distracted traveler in PCI Address Land
some time, document this fact with a comment. Add a test case for
the behavior as well.

A pci-bridge has *almost* the same rules as a legacy PCI endpoint
device for where it can be automatically connected, and until now both
had been considered identical. There is one pairing that is okay when
specifically requested by the user (i.e. manual assignment), but we
want to avoid it when auto-assigning addresses - plugging a pci-bridge
directly into pcie-root (it is cleaner to plug in a dmi-to-pci-bridge,
then plug the pci-bridge into that).

In order to allow that difference, this patch makes a separate
CONNECT_TYPE for pci-bridge, and uses it to restrict auto-assigned
addresses for pci-bridges to be only on pci-root, pci-expander-bus,
dmi-to-pci-bridge, or on another pci-bridge.

NB: As with other discouraged-but-seem-to-work configurations
(e.g. plugging a legacy PCI device into a pcie-root-port) if someone
*really* wants to, they can still force a pci-bridge to be plugged
into pcie-root (by manually specifying its PCI address.)

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

Rather than return a 0 or -1 and the *result string, return just the result
string to the caller.  Alter all the callers to handle the different return.

As a side effect or result of this, it's much clearer that we cannot just
assign the returned string into the scsi_host wwnn, wwpn, and fabric_wwn
fields - rather we should fetch a temporary string, then as long as our
fetch was good, VIR_FREE what may have been there, and STEAL what we just got.
This fixes a memory leak in the virNodeDeviceCreateXML code path through
find_new_device and nodeDeviceLookupSCSIHostByWWN which will continually
call nodeDeviceSysfsGetSCSIHostCaps until the expected wwnn/wwpn is found
in the device object capabilities.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Without them we're keeping <alias/> even for inactive XML.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

As with all other devices, it's not part of 'address'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

There are couple of things that needs to be done in order to
allow vhost-user hotplug. Firstly, vhost-user requires a chardev
which is connected to vhost-user bridge and through which qemu
communicates with the bridge (no acutal guest traffic is sent
through there, just some metadata). In order to generate proper
chardev alias, we must assign device alias way sooner.

Then, because we are plugging the chardev first, we need to do
the proper undo if something fails - that is remove netdev too.
We don't want anything to be left over in case attach fails at
some point.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>