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

Apart from generic checks, we need to constrain netmask/prefix
length a bit. Thing is, with current implementation QEMU needs to
be able to 'assign' some IP addresses to the virtual network. For
instance, the default gateway is at x.x.x.2, dns is at x.x.x.3,
the default DHCP range is x.x.x.15-x.x.x.30. Since we don't
expose these settings yet, it's safer to require shorter prefix
to have room for the defaults.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: laine@laine.org

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

Currently, all that users can specify for an interface type of
'user' is the common attributes: PCI address, NIC model (and
that's basically it). However, some need to configure other
address range than the default one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: laine@laine.org

The function checks whether all CPU features used in a CPU definition
are specified in cpu_map.xml.

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

Only feature policy is checked on s390, which was previously done in
virCPUUpdate, but that's not the correct place for the check once we
have virCPUValidateFeatures.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This new API may be used to check whether all features used in a CPU
definition are valid (e.g., libvirt knows their name, their policy is
supported, etc.). Leaving this API unimplemented in an arch subdriver
means libvirt does not restrict CPU features usable on the associated
architectures.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The host CPU definitions reported in the capabilities XML may contain
CPU features unknown to QEMU, but the result of virConnectBaselineCPU is
supposed to be directly usable as a guest CPU definition and thus it
should only contain features QEMU knows about.

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

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The filter only needs to know the CPU architecture. Passing
virQEMUCapsPtr as opaque is a bit overkill.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The implementation of virConnectBaselineCPU may be different for each
hypervisor. Thus it shouldn't really be implmented in the cpu code.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

They are logged in cpuBaseline anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

For parsing a list of CPU XMLs into a NULL-terminated list of CPU defs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1373783Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The macro needs to be defined closer to its usage

This is required by the fedora packaging guidelines:

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines

This macro isn't available on stock RHEL6 so provide a backcompat
definition

https://bugzilla.redhat.com/show_bug.cgi?id=1483293Reported-by: NVille Skyttä <ville.skytta@iki.fi>

Owning all created directories is a requirement of the Fedora
packaging guidelines

https://bugzilla.redhat.com/show_bug.cgi?id=1483293Signed-off-by: NCole Robinson <crobinso@redhat.com>

Luckily it only returns 0 or -1

Commit id 'e02ff020' neglected to use the attrBuf and childBuf
in the virDomainDiskSourceFormatNetwork call.

So make the necessary alterations to allow usage.

Rather than checking during XML processing, move the check for
valid <encryption> into virDomainDiskDefParseValidate and alter
the text of the message slightly to be a bit more correct.

Add a test to prove checking for invalid luks disk formatting check.
The error message will indicate supplying the <cipher> element is
unnecessary.

Rather than checking during XML processing, move the checks for correct
and valid auth into virDomainDiskDefParseValidate. This will introduce
virDomainDiskSourceDefParseAuthValidate to validate that the authdef
stored for the virStorageSource is valid. This can then be expanded
to service backingStore sources as well.

Alter the message text slightly as well to distinguish between an
unknown name and an incorrectly used name.  Since type is not a
mandatory field, add the NULLSTR() around the output of the unknown
error. NB, a config using unknown formatting would fail virschematest
since it only accepts 'iscsi' and 'ceph' as "valid" types.

Add a couple of tests to "validate" checks in domain_conf that either
a missing secrettype (CONFIG_UNSUPPORTED) or an mismatched secrettype
of ceph for an iSCSI disk (INTERNAL_ERROR) will cause a parsing error.

Alter the example to remove the <auth> from:

  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-pool' volume='unit:0:0:1' mode='host'/>
    <auth username='myuser'>
      <secret type='iscsi' usage='libvirtiscsi'/>
    </auth>
    <target dev='vdb' bus='virtio'/>
  </disk>

and

  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-pool' volume='unit:0:0:2' mode='direct'/>
    <auth username='myuser'>
      <secret type='iscsi' usage='libvirtiscsi'/>
    </auth>
    <target dev='vdc' bus='virtio'/>
  </disk>

The reality is, it's not even used. For a <source pool> the authdef
from the storage source pool will supercede whatever is in the <disk>
definition during virStorageTranslateDiskSourcePool processing. In fact,
if the pool doesn't have/need authentication, then the authdef would
be removed anyway as the storage pool would be handling things.

The "proof" for this is in the adjustment to the test to add an
<auth> for a disk. The resulting .args file won't add what normally
would be added "myname:encodedpassword@" prior to the hostname in
the IQN (e.g. iscsi://myname:encodedpassword@iscsi.example.org:3260/...

Some operations done to rollback disk image labelling and locking might
overwrite (or clear) the actual error. Remember the original error when
tearing down disk access so that it's not obscured.

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

The helpers allow to simplify restoring original errors in most cases.

Some cleanup paths overwrite a usefull error message with a less useful
one and we then try to preserve the original message. The handlers added
in this patch will simplify the operations since they are designed right
for the purpose.

Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Order them more logically and make sure that stuff that doesn't
need to be modified frequently if at all, such as the notification
settings, are out of the way.

Perform other very minor tweaks as well.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Since configure automatically picks up as many optional dependencies
as possible, installing more packages allows us to improve our test
coverage.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

The default distribution is apparently ignored if an explicit test
matrix is provided, so we haven't actually been testing the precise
plus gcc combo.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

Make parts of the build command OS-dependent instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

The openwsman header files are at fault here, but precise is entirely
unmaintained at this point so the issue will never be fixed.

Better to ignore the error and have coverage over the Hyper-V driver
than disabling it: if code that would trigger the warning will be
added to libvirt, the CentOS CI will catch it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

We don't need 50 commits for our purposes, so might as well save some
bandwidth and possibly some time by making the clone shallower.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

For reference, these were generated by updating a local qemu git
repository to the latest upstream, making sure the latest dependencies
were met via "dnf builddep qemu" from my sufficiently privileged root
account, checking out the v2.10.0 tag, and building in order to generate
an "x86_64-softmmu/qemu-system-x86_64" image.

Then using a clean libvirt tree updated to master and built, the image
was then provided as input:

    tests/qemucapsprobe /path/to/x86_64-softmmu/qemu-system-x86_64 > \
       tests/qemucapabilitiesdata/caps_2.10.0.x86_64.replies

With the .replies file in place and the DO_TEST line added and build,
then running the following commands:

    touch tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
    VIR_TEST_REGENERATE_OUTPUT=1 ./tests/qemucapabilitiestest

to generate tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml and both
were added to the commit.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Interestingly, none of the qemus we have caps for supported it ...
Reviewed-by: NEric Blake <eblake@redhat.com>

Drop all the monitor code necessary to do the downstream block jobs.
Reviewed-by: NEric Blake <eblake@redhat.com>

Block job QMP commands with underscores rather than dashes were never
released in upstream qemu, (they were added, but modified in the same
release [1]), but a certain distro managed to backport the version in the
middle.

The change also slightly modified semantics for the abort command, which
made us have a lot of code which was only ever present in certain
downstream distros.

Clean the upstream code from the legacy cruft and support only the
upstream implementations.

[1] See qemu commit v1.0-2176-gdb58f9c060
Reviewed-by: NEric Blake <eblake@redhat.com>

No need to pass a @driver parameter since all that's done is deref
the @cfg especially since the only caller can just pass an already
referenced @cfg.

Also, looks like commit id '0298531b' at one time had a different
name for the API, so I took the liberty of fixing the comments too
since I would already be updating them for the @cfg variable.