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

The virsh command 'domblkinfo' returns the capacity, allocation and phisycal
size of the devices attached in a domain. Usually, this sizes are very big
and hard to understand and calculate. This commits introduce a human readable
support to check the size of each field easilly.

For example, the command before:

virsh # domblkinfo my_domain hda
Capacity:       21474836480
Allocation:     14875545600
Physical:       21474836480

and after this patch:

virsh # domblkinfo my_domain hda --human
Capacity:       20.000G
Allocation:     13.900G
Physical:       20.000G
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Nested HVM support in the libxl driver is a news-worthy
improvement for libvirt 3.3.0.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

... with VIR_NET_GENERATED_MACV???_PREFIX, which is defined in
util/virnetdevmacvlan.h.

Since VIR_NET_GENERATED_PREFIX is used for plain tap devices, it is
renamed to VIR_NET_GENERATED_TAP_PREFIX and moved to virnetdev.h

The parser had been clearing out *all* suggested device names for
type='direct' (aka macvtap) interfaces. All of the code implementing
macvtap allows for a user-specified device name, so we should allow
it. In the case that an interface name starts with "macvtap" or
"macvlan" though, we do still clear it out, just as we do with "vnet"
(which is the prefix used for automatically generated tap device
names), since those are the prefixes for the names we autogenerate for
macvtap and macvlan devices.

Resolves: https://bugzilla.redhat.com/1335798

MACVTAP_NAME_PREFIX and MACVLAN_NAME_PREFIX could be useful to other
files if they were defined in virnetdevmacvlan.h instead of
virnetdevmacvlan.c, so do that (while slightly renaming them and also
adding yet another #define that chooses between macvlan/macvtap based
on flags).

This is a prerequisite to fix: https://bugzilla.redhat.com/1335798

If the network isn't active during networkNotifyActualDevice(), we
would log an error message stating that the bridge device didn't
exist. This patch adds a check to see if the network is active, making
the logs more useful in the case that it isn't.

Partially resolves: https://bugzilla.redhat.com/1442700

Nothing that could happen during networkNotifyActualDevice() could
justify unceremoniously killing the qemu process, but that's what we
were doing.

In particular, new code added in commit 85bcc022 (first appearred in
libvirt-3.2.0) attempts to reattach tap devices to their assigned
bridge devices when libvirtd restarts (to make it easier to recover
from a restart of a libvirt network). But if the network has been
stopped and *not* restarted, the bridge device won't exist and
networkNotifyActualDevice() will fail.

This patch changes networkNotifyActualDevice() and
qemuProcessNotifyNets() to return void, so that qemuProcessReconnect()
will soldier on regardless of what happens (any errors will still be
logged though).

Partially resolves: https://bugzilla.redhat.com/1442700

This patch changes following output:

    ...
    <graphics type='vnc' port='-1' autoport='yes'>
      <listen type='none'/>
    </graphics>
    ...

into this output:

    ...
    <graphics type='vnc'>
      <listen type='none'/>
    </graphics>
    ...
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

After 1eb66479 nobody calls the iohelper with 6 arguments.
Everybody uses the other mode. Well, the only user of iohelper
after the previous commit is virFileWrapperFd really.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Currently we use iohelper for virFDStream implementation. This is
because UNIX I/O can lie sometimes: even though a FD for a
file/block device is set as unblocking, actual read()/write() can
block. To avoid this, a pipe is created and one end is kept for
read/write while the other is handed over to iohelper to
write/read the data for us. Thus it's iohelper which gets blocked
and not our event loop.

This approach has two problems:
1) we are spawning a new process.
2) any exchange of information between daemon and iohelper can be
done only through the pipe.

Therefore, iohelper is replaced with an implementation in thread
which is created just for the stream lifetime. The data are still
transferred through pipe (for now), but both problems described
above are solved.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

While this is no functional change, it makes the code look a bit
nicer. Moreover, it prepares ground for future work.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

There is really no reason why we should have to have 'struct'
everywhere.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

It helps with debugging if we know what's the return value of
saferead().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Because of copy-paste the temporary directory used for this test
is called "fakesysdir". That's probably misleading.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Acked-by: NAndrea Bolognani <abologna@redhat.com>

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Acked-by: NAndrea Bolognani <abologna@redhat.com>

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

This is a USB3 controller and it's a better choice than piix3-uhci.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Acked-by: NAndrea Bolognani <abologna@redhat.com>

The new logic will set the piix3-uhci if available regardless of
any architecture and it will be updated to better model based on
architecture and device existence.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Acked-by: NAndrea Bolognani <abologna@redhat.com>

NBD does not mandate a "filename". Gluster can have more servers. Split
them so that we can tighten the schema.

ftp/tftp/sheepdog have a mandatory filename and support only one host.
There are no additional options for them.

Make the schema more strict for HTTP disks requiring a name and
mandating exactly one source host.

ftp/tftp entries were not moved here, since http transport also will
support cookies and other options, which will be added later.

RBD driver supports specifying a snapshot image name or config file.
Create a define for RBD and move the specifics there.

Move it to the place where actually interleaving elements can be placed.

'diskSourceNetwork' schema define was rather big and it would be hard to
simplify it. Split out the host portion subelement into a separate
define.

They don't contain any elements to interleave.

Since commit c5f61513 qemuDomainBlockInfo tries to update the
"physical" storage size for all network storage and not only block
devices.

Since the storage driver APIs to do this are not implemented for certain
storage types (RBD, iSCSI, ...) the code would fail to retrieve any data
since the failure of qemuDomainStorageUpdatePhysical is fatal.

Since it's desired to return data even if the total size can't be
updated we need to ignore errors from that function and return plausible
data.

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

Rather than freeing the list before starting a new VM clear it after
stopping the old instance when the data becomes invalid.

The alias would be leaked, since it's not freed on the vm stop path.

Since the private data structure is not freed upon stopping a VM, the
usbaddrs pointer would be leaked:

==15388== 136 (16 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 893 of 1,019
==15388==    at 0x4C2CF55: calloc (vg_replace_malloc.c:711)
==15388==    by 0x54BF64A: virAlloc (viralloc.c:144)
==15388==    by 0x5547588: virDomainUSBAddressSetCreate (domain_addr.c:1608)
==15388==    by 0x144D38A2: qemuDomainAssignUSBAddresses (qemu_domain_address.c:2458)
==15388==    by 0x144D38A2: qemuDomainAssignAddresses (qemu_domain_address.c:2515)
==15388==    by 0x144ED1E3: qemuProcessPrepareDomain (qemu_process.c:5398)
==15388==    by 0x144F51FF: qemuProcessStart (qemu_process.c:5979)
[...]

Clean the stale data after shutting down the VM. Otherwise the data
would be leaked on next VM start. This happens due to the fact that the
private data object is not freed on destroy of the VM.

Testing various configuration schemas targeting postive and negative
nestedhvm under libvirt <cpu mode="host-passthrough"> configuration.

Mode "host-passthrough" generates nestedhvm=1 in/from xl format where

Intel virtualization (VT-x):
<feature policy='disable' name='vmx'/>

    or

AMD virtualization (AMD-V):
<feature policy='disable' name='svm'/>

disables virtualization mode under guest domains.
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Per xen-xl conversions from and to native under host-passthrough
mode we take care for Xen (nestedhvm = mode) applied and inherited
settings generating or processing correct feature policy:

[On Intel (VT-x) architectures]
<feature policy='disable' name='vmx'/>

or

[On AMD (AMD-V) architectures]
<feature policy='disable' name='svm'/>

It will then generate (or parse) for nestedhvm=1 in/from xl format.
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>

Xen feature nestedhvm is the option on Xen 4.4+ which enables
nested virtualization when mode host-passthrough is applied.

nested HVM is enabled by adding below on the target domain;
<cpu mode='host-passthrough'/>

Virtualization on target domain can be disabled by specifying
such under feature policy rule on target name;

[On Intel (VT-x) architecture]
<feature policy='disable' name='vmx'/>

or:

[On AMD (AMD-V) architecture]
<feature policy='disable' name='svm'/>
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>

This patch maps /domain/cpu/cache element into -cpu parameters:

- <cache mode='passthrough'/> is translated to host-cache-info=on
- <cache level='3' mode='emulate'/> is transformed into l3-cache=on
- <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off

Any other <cache> element is forbidden.

The tricky part is detecting whether QEMU supports the CPU properties.

The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480,
earlier QEMU releases enabled host-cache-info by default and had no way
to disable it. If the property is present, it defaults to 'off' for any
QEMU until at least 2.9.0.

The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa.
Earlier versions worked as if l3-cache=off was passed. For any QEMU
until at least 2.9.0 l3-cache is 'off' by default.

QEMU 2.9.0 was the first release which supports probing both properties
by running device-list-properties with typename=host-x86_64-cpu. Older
QEMU releases did not support device-list-properties command for CPU
devices. Thus we can't really rely on probing them and we can just use
query-cpu-model-expansion QMP command as a witness.

Because the cache property probing is only reliable for QEMU >= 2.9.0
when both are already supported for quite a few releases, we let QEMU
report an error if a specific cache mode is explicitly requested. The
other mode (or both if a user requested CPU cache to be disabled) is
explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case
the QEMU defaults change. Any older QEMU already turns them off so not
doing so explicitly does not make any harm.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This patch introduces

    <cache level='N' mode='emulate'/>
    <cache mode='passthrough'/>
    <cache mode='disable'/>

sub element of /domain/cpu. Currently only a single <cache> element is
allowed.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The type of this parameter is virCPUType so calling it 'mode' is pretty
strange, 'type' is a much better name.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Not all async jobs are visible via virDomainGetJobStats (either they are
too fast or getting the stats is not allowed during the job), but
forcing all of them to advertise the operation is easier than hunting
the jobs for which fetching statistics is allowed. And we won't need to
think about this when we add support for getting stats for more jobs.

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