Create four smaller blocks of texts instead of one large one.

Simplify the function by leaving out the local copy and checking
return values of virStrToLong.

Request that the number be parsed as decimal, to allow 08
and 09.

Format it with the leading zero, 1.01 and 1.10 are two
different versions.

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

We don't format the default '-1' fields back.

On arm, we probe for virtio-*-pci devices, but use their
virtio-*-device variants.

Set the capabilities based on the -device variants as well,
to make them work with qemus with the PCI devices compiled out.

When pre-creating storage for domains, we need to find corresponding
disk in the XML on the destination (domain XML may differ there, e.g.
disk is accessible under different path). For better debugging, I'm
printing all info I received on a disk. But there was a typo when
printing the disk capacity: "%lluu" instead of "%llu".
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The problem with the previous implementation is,
even when qemuMigrationUpdateJobStatus() detects a migration job
has completed, it will do a sleep for 50 ms (which is unnecessary
and only adds up to the VM pause time).
Signed-off-by: NXing Lin <xinglin@cs.utah.edu>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The tag is already marked as optional in the schema, so no changes
are needed there.

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

Future IOThread setting patches would copy the code anyway, so create
and generalize the adding of pindef for the vcpu and the pinning of the
thread into their own APIs.

We've been explicitly requesting IPv4 for some reason,
even if there were only IPv6 addresses in the network
definition.

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

Add static virNetDevGetifaddrsAddress to attempt to get the interface
IP address. If getifaddrs is not supported, fall back to
virNetDevGetIPv4AddressIoctl to get the IP address.

This allows IPv6 addresses to be used for <listen type='network>
with device-backed networks.

https://bugzilla.redhat.com/show_bug.cgi?id=1192318Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Rename it to virNetDevGetIPv4AddressIoctl and make
virNetDevGetIPAddress a wrapper around it, allowing
other ways of getting the address to be implemented,
and still falling back to the old method.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

PCS doesn't store domain config in managed save state file.
It's forbidden to change config for VMs in this state.
It's possible to change config for containers, but after
restoring domain will have that new config, not a config,
which domain had at the moment of virDomainManagedSave.

So we need to handle this case differently from other states.
Let's forbid this operation, if config is changed and if it's
not changed - just do nothing.

Openstack/nova calls virDomainDefineXML on resume with
current domain config, so we can't forbid this operation
in managed save state.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

We should add input devices with proper bus,
not VIR_DOMAIN_INPUT_BUS_XEN.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Handle input devices in virDomainDefParseXML properly
in case of parallels containers and VMs.

Parallels containers support only
VIR_DOMAIN_INPUT_BUS_PARALLELS. And if VNC is enabled
we should add implicit mouse and keyboard.

For VMs we should add implicit PS/2 mouse and
keyboard.

BTW, is it worth to refactor code and move
all this code to drivers, to *DomainDefPostParse
functions?
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add implicit input devices in parallelsLoadDomains,
when VNC is enabled.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Add VIR_DOMAIN_INPUT_BUS_PARALLELS device type
to handle domain configuration properly for
parallels containers, when VNC is enabled.

When domain configuration has at least one
'graphics', there should be mouse and keyboard.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Fix function virDomainVideoDefaultType for
parallels VMs and containers. It should return
VGA for VMs and VIR_DOMAIN_VIDEO_TYPE_PARALLELS
for containers.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

We support VNC for containers to have the same
interface with VMs. At this moment it just renders
linux text console.

Of course we don't pass any physical devices and
don't emulate virtual devices. Our VNC server
renders text from terminal master and sends
input events from VNC client to terminal.

So add special video type VIR_DOMAIN_VIDEO_TYPE_PARALLELS
for these pseudo-devices.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Network adapter model has no sense for container,
so we shouldn't set it to e1000 in
parallelsDomainDeviceDefPostParse.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

We handle this parameter for VMs while defining
domains, so let's get this property from PCS and
set corresponding field of virDomainNetDef in
prlsdkLoadDomains function.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Call virDomainDefAddImplicitControllers to add disk
controllers, so virDomainDef, filled by this function
will look exactly like the one returned by virDomainDefParseString.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Set readonly flag for cdrom devices when we
retrieve a list of domains from PCS.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Implement virDomainManagedSave api function. In PCS
this feature called "suspend". You can suspend VM or
CT while it is in running or paused state. And after
resuming (or starting) it will have the same state, as
before suspend.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Split function prlsdkDomainChangeState into
prlsdkDomainChangeStateLocked and prlsdkDomainChangeState.
So it can be used from places, where virDomainObj already
found and locked.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Return value of functions prlsdkStart/Kill/Stop e.t.c.
is PRL_RESULT in parallels_sdk.c and int in parallels_sdk.h.
PRL_RESULT is int, so compiler didn't report errors.
Let's fix the difference.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Future IOThread setting patches would copy the code anyway, so create
and generalize a delete cgroup and pindef for the vcpu into its own API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Future IOThread setting patches would copy the code anyway, so create
and generalize the add the vcpu to a cgroup into its own API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Replace the virCgroupNew{Vcpu|Emulator|IOThread} calls with the common
virCgroupNewThread API
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Create a new common API to replace the virCgroupNew{Vcpu|Emulator|IOThread}
API's using an emum to generate the cgroup name
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

If the backend driver updates the pool available and/or allocation values,
then the storage_driver VolCreateXML, VolCreateXMLFrom, and VolDelete APIs
should not change the value; otherwise, it will appear as if the values
were "doubled" for each change.  Additionally since unsigned arithmetic will
be used depending on the size and operation, either or both values could be
appear to be much larger than they should be (in the EiB range).

Currently only the disk pool updates the values, but other pools could.
Assume a "fresh" disk pool of 500 MiB using /dev/sde:

$ virsh pool-info disk-pool
...
Capacity:       509.88 MiB
Allocation:     0.00 B
Available:      509.84 MiB

$ virsh vol-create-as disk-pool sde1 --capacity 300M

$ virsh pool-info disk-pool
...
Capacity:       509.88 MiB
Allocation:     600.47 MiB
Available:      16.00 EiB

Following assumes disk backend updated to refresh the disk pool at deletion
of primary partition as well as extended partition:

$ virsh vol-delete --pool disk-pool sde1
Vol sde1 deleted

$ virsh pool-info disk-pool
...
Capacity:       509.88 MiB
Allocation:     9.73 EiB
Available:      6.27 EiB

This patch will check if the backend updated the pool values and honor that
update.

Commit id '471e1c4e' only considered updating the pool if the extended
partition was removed. As it turns out removing a primary partition
would also need to update the freeExtent list otherwise the following
sequence would fail (assuming a "fresh" disk pool for /dev/sde of 500M):

$  virsh pool-info disk-pool
...
Capacity:       509.88 MiB
Allocation:     0.00 B
Available:      509.84 MiB

$ virsh vol-create-as disk-pool sde1 --capacity 300M
$ virsh vol-delete --pool disk-pool sde1
$ virsh vol-create-as disk-pool sde1 --capacity 300M
error: Failed to create vol sde1
error: internal error: no large enough free extent

$

This patch will refresh the pool, rereading the partitions, and
return

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

When creating a volume in a pool, the creation allows the 'capacity'
value to be larger than the available space in the pool. As long as
the 'allocation' value will fit in the space, the volume will be created.

However, resizing the volume checks were made with the new absolute
capacity value against existing capacity + the available space without
regard for whether the new absolute capacity was actually allocating
space or not.  For example, a pool with 75G of available space creates
a volume of 10G using a capacity of 100G and allocation of 10G will succeed;
however, if the allocation used a capacity of 10G instead and then tried
to resize the allocation to 100G the code would fail to allow the backend
to try the resize.

Furthermore, when updating the pool "available" and "allocation" values,
the resize code would just "blindly" adjust them regardless of whether
space was "allocated" or just "capacity" was being adjusted.  This left
a scenario whereby a resize to 100G would fail; however, a resize to 50G
followed by one to 100G would both succeed.  Again, neither was adjusting
the allocation value, just the "capacity" value.

This patch adds more logic to the resize code to understand whether the
new capacity value is actually "allocating" space as well and whether it
shrinking or expanding. Since unsigned arithmatic is involved, the possibility
that we adjust the pool size values incorrectly is probable.

This patch also ensures that updates to the pool values only occur if we
actually performed the allocation.

NB: The storageVolDelete, storageVolCreateXML, and storageVolCreateXMLFrom
each only updates the pool allocation/availability values by the target
volume allocation value.

Old compilers whine that 'sync' is being shadowed in the function
introduced in 1eccac1d.

Support for drive-reopen was never present in the upstream code so we
don't need to pause the VM when doing the block pivot. Kill all the
code related to this semi-upstream artifact.

There are two leftover unused variables. Remove them and clean up the
fallout of the change.

Refactor the function to use the new helpers.

We need to check that qemu supports block jobs in multiple places. Add a
helper to do the check.

In some cases where the function does not need to access the private
data this helper may be used to retrieve the monitor object.