Instead duplicating the capability check for each possible target
model, introduce a small helper that matches the target model with
the corresponding capability and collapse all existing checks into
a single one.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Now that we've created a distinction between target type and target
model, with the latter being the concrete device name, it's time to
switch to formatting the model instead of the type.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Target model and target type must agree for the configuration
to make sense, so check that's actually the case and error out
otherwise.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

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

This information will be used to select, and store in the guest
configuration in order to guarantee ABI stability, the concrete
(hypervisor-specific) model for serial devices.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Instead of validating each target type / address type combination
separately, create a small helper to perform the matching and
collapse all existing checks into a single one.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Instead of waiting until we get to command line generation, we can
validate the target for a char device much earlier.

Move all the checks out of qemuBuildSerialChrDeviceStr() and into
the new fuction. This will later allow us to validate the target
for platform devices.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Formatting the <target/> element for serial devices will become a
bit more complicated later on, and leaving the fallthrough behavior
there would do nothing but complicate it further.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Make the switch statement type-aware, avoid calling
virDomainChrTargetTypeToString() more than once and check its
return value before using it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The function can fail, but none of the caller were accounting
for that.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

We don't need to store the return value since we never modify it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Move formatting of the <target/> element for char devices out of
virDomainChrDefFormat() and into its own function.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This attribute was used to decide whether to format the type
attribute of the <target> element, but the logic didn't take into
account all possible cases and as such could lead to unexpected
results. Moreover, it's one more thing to keep track of, and can
easily fall out of sync with other attributes.

Now that we have VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_NONE, we can
use that value to signal that no specific target type has been
configured for the serial device and as such the attribute should
not be formatted at all. All other values are now formatted.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This is the first step in getting rid of the assumption that
isa-serial is the default target type for serial devices.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The devicePostParse() callback is invoked for all devices so that
drivers have a chance to set their own specific values; however,
virDomainDefAddImplicitDevices() runs *after* the devicePostParse()
callbacks have been invoked and can add new devices, in which case
the driver wouldn't have a chance to customize them.

Work around the issue by invoking the devicePostParse() callback
after virDomainDefAddImplicitDevices(), only for the first serial
devices, which might have been added by it. The same was already
happening for the first video device for the very same reason.

This will become important later on, when we will change
virDomainDefAddConsoleCompat() not to set a targetType for
automatically added serial devices.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Having a separate function for char device handling is better than
adding even more code to qemuDomainDeviceDefPostParse().
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

Our current documentation is missing some information and doesn't
do a great job at explaining how the <serial> and <console> elements
are connected. Let's try to fix that.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This commit fixes the virsh prompt when reconnection to the same URI is
called: `virsh # connect --readonly` (Reconnect). The problem is
happening because the code is considering URI (name) as a mandatory
parameter to change the prompt. This commit remove the assignment into
`priv->readonly` from `if (name)` conditional.

Before:
    virsh # uri
    qemu:///system

    virsh # connect --readonly

    virsh #

After:
    virsh # uri
    qemu:///system

    virsh # connect --readonly

    virsh >

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1507737Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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

The blockdev-add code provides a mechanism to sanely provide user
and password-secret arguments for iscsi without placing them on the
command line to be viewable by a 'ps -ef' type command or needing
to create separate -iscsi devices for each disk/volume found.

So modify the iSCSI command line building to check for the presence
of the capability in order properly setup and use the domain master
secret object to encrypt the password in a secret object and alter
the parameters for the command line to utilize.

Modify the xml2argvtest to exhibit the syntax for both disk and
hostdev configurations.

Detect the capability via the query-qmp-schema for blockdev-add
to find the 'password-secret' parameter that will allow the iSCSI
code to use the master secret object to encrypt the secret for an
and only need to provide the object id of the secret on the command
line thus obsfuscating the passphrase.

Rather than building the "file" string in qemuBuildSCSIHostdevDrvStr
build it in the called helper.

Since it's not longer used to shuttle the @secinfo, let's remove
the private hostdev completely.

Rather than placing/using privateData about secinfo in the hostdev,
let's use the virStorageSource private data instead.

Rather than picking apart the two pieces we need/want (path, hosts,
and auth)- let's allocate/use a virStorageSourcePtr for iSCSI storage.

The end result is that qemuBuildSCSIiSCSIHostdevDrvStr doesn't need
to "fake" one for the qemuBuildNetworkDriveStr call.

Utilize all the newly introduced function to create the evdev node
and label it on hotplug and destroy it on hotunplug.

This was forgotten in commits bc9ffafc and 67486bb2.

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

Introudce functions that will let us create the evdevs in namespaces
and label the devices on input device hotplug/hotunplug.

Export qemuSetupInputCgroup and introduce qemuTeardownInputCgroup
for hotunplug.

Export the existing DAC and SELinux for separate use and introduce
functions for stack, nop and the security manager.

Use it to denadify qemuDomainSetupInput.

Libvirt prints an error on startup when it is missing host cpu model
information for any queried qemu binary. On s390 we only have host cpu model
information for kvm enabled qemu instances. So when virt type is not kvm, this
is actually not an error on s390.

This patch adds virt type as a parameter to virQEMUCapsInitCPUModelS390, and a
new return code 2 for virQEMUCapsInitCPUModel and virQEMUCapsInitCPUModelS390.
If the virt type is not kvm then we skip printing the scary error message
and return 2 because this case is actually expected behavior. The new return
code is meant to differentiate between the failure case and the case where we
simply expect the cpu model information to be unattainable.
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Commit id '5d5c732d' had an incorrect assignment and was found
by travis build:

storage/storage_driver.c:1668:14: error: equality comparison with extraneous
      parentheses [-Werror,-Wparentheses-equality]
    if ((obj == virStoragePoolObjListSearch(&driver->pools,

         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now that we're moved the object into virstorageobj, let's make the
code use the lockable object.

Create an API to search through the storage pool objects looking for
a specific truism from a callback API in order to return the specific
storage pool object that is desired.

Create an API to walk the pools->objs[] list in order to perform a
callback function for each element of the objs array that doesn't care
about whether the action succeeds or fails as the desire is to run the
code over every element in the array rather than fail as soon as or if
one fails.

For now it'll just call the virStoragePoolObjUnlock, but a future
adjustment will do something different. Since the new API will check
for a NULL object before the Unlock call, callers no longer need to
check for NULL before calling.

The virStoragePoolObjUnlock is now private/static to virstorageobj.c
with a short term forward reference.

Commit id '36555364' removed the setting of the driver->privileged,
which the udevProcessPCI would need in order to read the PCI device
configs.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the setup of the disk attribute to the disk source prepare function
which will allow proper usage with JSON props and move the fallback
(legacy) generating code into the block which is executed with legacy
options.

As a side-effect of this change we can clean up propagation of 'cfg'
into the command generator.

Also it's nice to see that the test output is the same even when the
value is generated in a different place.