This patch adds new xml element, and so we can have the option of
also having perf events enabled immediately at startup.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Message-id: 1459171833-26416-6-git-send-email-qiaowei.ren@intel.com
This patch implement a set of interfaces for perf event. Based on
these interfaces, we can implement internal driver API for perf,
and get the results of perf conuter you care about.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Message-id: 1459171833-26416-4-git-send-email-qiaowei.ren@intel.com
API agreed on in
https://www.redhat.com/archives/libvir-list/2015-October/msg00872.html
* include/libvirt/libvirt-domain.h (virDomainGetPerfEvents,
virDomainSetPerfEvents): New declarations.
* src/libvirt_public.syms: Export new symbols.
* src/driver-hypervisor.h (virDrvDomainGetPerfEvents,
virDrvDomainSetPerfEvents): New typedefs.
* src/libvirt-domain.c: Implement virDomainGetPerfEvents and
virDomainSetPerfEvents.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Message-id: 1459171833-26416-2-git-send-email-qiaowei.ren@intel.com
If the pool creation thread happens to detect the luns in
the scsi target, the size parameters will be calculated as
part of the refreshPool called from storagePoolCreate().
This means the virStoragePoolFCRefreshThread (commit id
'512b874') waiting to run and "refresh" the pool will
essentially double the allocation and capacity values.
A separate refresh would correct the values.
To avoid this, the FCRefreshThread needs to reinitialize
the pool size values prior to calling virStorageBackendSCSIFindLUs
which eventually calls virStorageBackendSCSINewLun and
updates the size values for each volume found.
After the recent commits the build didn't work for me. Fix it by
using size_t as the callback argument is using and the correct
formatter. The attempted fixup to use %llu as a formatter was wrong.
Commit e6336442 changed the 'out:' label to 'cleanup' in
libxlDomainAttachNetDevice(), but missed a comment referencing
the 'out:' label. Remove it from the comment since it is no
longer accurate anyhow.
This patch adds support for "vpindex", "runtime", "synic",
"stimer", and "vendor_id" features available in qemu 2.5+.
- When Hyper-V "vpindex" is on, guest can use MSR HV_X64_MSR_VP_INDEX
to get virtual processor ID.
- Hyper-V "runtime" enlightement feature allows to use MSR
HV_X64_MSR_VP_RUNTIME to get the time the virtual processor consumes
running guest code, as well as the time the hypervisor spends running
code on behalf of that guest.
- Hyper-V "synic" stands for Synthetic Interrupt Controller, which is
lapic extension controlled via MSRs.
- Hyper-V "stimer" switches on Hyper-V SynIC timers MSR's support.
Guest can setup and use fired by host events (SynIC interrupt and
appropriate timer expiration message) as guest clock events
- Hyper-V "reset" allows guest to reset VM.
- Hyper-V "vendor_id" exposes hypervisor vendor id to guest.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
1. All hyperv features are tristate ones. So make tristate generating part common.
2. Reduce nesting on spinlocks.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
1. All hyperv features are tristate ones. So make tristate parsing code common.
2. Reindent switch statement.
3. Reduce nesting in spinlocks parsing.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
After the patches that added tracking of in-use macvtap names (commit
370608, first appearing in libvirt-1.3.2), if the function to allocate
a new macvtap device came to a device name created outside libvirt, it
would retry the same device name MACVLAN_MAX_ID (8191) times before
finally giving up in failure.
The problem was that virBitmapNextClearBit was always being called
with "0" rather than the value most recently checked (which would
increment each time through the loop), so it would always return the
same id (since we dutifully release that id after failing to create a
new device using it).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1321546
Signed-off-by: Laine Stump <laine@laine.org>
For those VF allocated from a network pool, we need to set its backend
to be VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN so that later work can be
correct.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
This reverts commit bb5f2dc91f43f48ff726aa589bdac546738d2980.
The "if (vol->target.format != VIR_STORAGE_FILE_RAW)" check in the
createVol backend. This check is bogus because virStorageVolDefParseXML()
in conf/storage_conf.c sets target.format only if volOptions in
virStoragePoolTypeInfo has formatFromString set, and that's not the
case the zfs backend.
So the check always fails and breaks volume creation.
This reverts commit 6682d6219d4595b51f06867e0c30e7efd745f682.
The "if (vol->target.format != VIR_STORAGE_FILE_RAW)" check in the
createVol backend. This check is bogus because virStorageVolDefParseXML()
in conf/storage_conf.c sets target.format only if volOptions in
virStoragePoolTypeInfo has formatFromString set, and that's not the
case the logical backend.
So the check always fails and breaks volume creation.
When hostdev parent is network device, should call
libxlDomainDetachNetDevice to detach the device from a higher level.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
When AttachNetDevice failed, should call networkReleaseActualDevice
to release actual device, and if actual device is hostdev, should
remove the hostdev from vm->def->hostdevs.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
networkStartNetwork() and networkShutdownNetwork() were calling the
wrong type-specific function in the case of networks that were
configured for macvtap ("direct") bridge mode - they were instead
calling the functions for a tap+bridge network. Currently none of
these functions does anything (they just return 0) so it hasn't
created any problems, but that could change in the future.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316465
An attempt to simplify the code for the VIR_NETWORK_FORWARD_BRIDGE
case of networkUpdateState in commit b61db335 (first in release
1.2.14) resulted in networks based on macvtap bridge mode being
erroneously marked as inactive any time libvirtd was restarted.
The problem is that the original code had differentiated between a
network using tap devices to connect to an existing host-bridge device
(forward mode of VIR_NETWORK_FORWARD_BRIDGE and a non-NULL
def->bridge), and one using macvtap bridge mode to connect to any
ethernet device (still forward mode VIR_NETWORK_FORWARD_BRIDGE, but
null def->bridge), but the changed code assumed that all networks with
VIR_NETWORK_FORWARD_BRIDGE were tap + host-bridge networks, so a null
def->bridge was interpreted as "inactive".
This patch restores the original code in networkUpdateState
The adminDispatchConnectListServers() function is generated by
our great perl script. However, it has a tiny flaw: if
adminConnectListServers() it calls fails, the control jumps onto
cleanup label where we try to free any list of servers built so
far. However, in the loop @i is unsigned (size_t) while @nresults
is signed (int). Currently, it does no harm because of the check
for @result being non-NULL. But if that ever changes in the
future, this bug will be hard to chase.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
If a user specify network type ethernet, then create it via libvirt and run
script if it provided. After this commit user does not need to
run external script to create tap device or add root permissions to qemu
process.
Signed-off-by: Vasiliy Tolstov <v.tolstov@selfip.ru>
Instead of forcing the values for the unbind_from_stub, remove_slot
and reprobe properties, look up the actual device and use that when
calling virPCIDeviceReattach().
This ensures the device is restored to its original state after
reattach: for example, if it was not bound to any driver before
detach, it will not be bound forcefully during reattach.
We would be just fine looking up the information in pcidevs most
of the time; however, some corner cases would not be handled
properly, so look up the actual device instead.
After this patch, ownership of virPCIDevice instances is very easy
to keep track of: for each host PCI device, the only instance that
actually matters is the one inside one of the bookkeeping list.
Whenever some operation needs to be performed on a PCI device, the
actual device is looked up first; when this is not the case, a
comment explains the reason.
Unmanaged devices, as the name suggests, are not detached
automatically from the host by libvirt before being attached to a
guest: it's the user's responsability to detach them manually
beforehand. If that preliminary step has not been performed, the
attach operation can't complete successfully.
Instead of relying on the lower layers to error out with cryptic
messages such as
error: Failed to attach device from /tmp/hostdev.xml
error: Path '/dev/vfio/12' is not accessible: No such file or directory
prevent the situation altogether and provide the user with a more
useful error message.
Unmanaged devices are attached to guests in two steps: first,
the device is detached from the host and marked as inactive;
subsequently, it is marked as active and attached to the guest.
If the daemon is restarted between these two operations, we lose
track of the inactive device.
Steps 5 and 6 of virHostdevPreparePCIDevices() already subtly
take care of this situation, but some planned changes will make
it so that's no longer the case. Plus, explicit is always better
than implicit.
This will skip few steps from qemuProcessStart in order to create only
qemu CMD. Use a VIR_QEMU_PROCESS_START_PRETEND for all the qemuProcess*
functions called by this one to not modify or check host.
This new function will be used later on for XMLToNative API and also for
qemuxml2argvtest to make sure that both API and test uses the same code
as qemuProcessStart.
We need also update qemuProcessInit to wrap few lines of code with check
that VIR_QEMU_PROCESS_START_PRETEND that makes sense only for
qemuProcessStart.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Move all code that checks host and domain. Do not check host if we use
VIR_QEMU_PROCESS_START_PRETEND flag.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Move all code that modifies only live XML to this function. The new
VIR_QEMU_PROCESS_START_PRETEND flag will be used by qemuXMLToNative and
qemuxml2argvtest later in order to reuse the same code as
qemuProcessStart uses.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The postParse callback is the correct place to generate default values
that should be present in offline XML.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
QEMU changed the error message to:
"Tray of device 'drive-sata0-0-1' is not open"
and they may change the error massage in the future.
This updates the code to not depend on the text from the error message
but only on error itself.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When reading in an XML definition for a SCSI target device, the name
property of struct scsi_target refers to the @target element.
Let's fix this obvious typo and also extend the XML schema to provide
validation.
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Until now, the libxl driver ignored any <hap> setting in domain XML
and deferred to libxl, which enables hap if not specified. While
this is a good default, it prevents disabling hap if desired.
This change allows disabling hap with <hap state='off'/>. hap is
explicitly enabled with <hap/> or <hap state='on/>. Absense of <hap>
retains current behavior of deferring default state to libxl.
hap is enabled by default in xm and xl config and usually only
specified when it is desirable to disable hap (hap = 0). Change
the xm,xl <-> xml converter to behave similarly. I.e. only
produce 'hap = 0' when <hap state='off'/> and vice versa.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Most hypervisors use Hardware Assisted Paging by default and don't
require specifying the feature in domain conf. But some hypervisors
support disabling HAP on a per-domain basis. To enable HAP by default
yet provide a knob to disable it, extend the <hap> feature with a
'state=on|off' attribute, similar to <pvspinlock> and <vmport> features.
In the absence of <hap>, the hypervisor default (on) is used. <hap>
without the state attribute would be the same as <hap state='on'/> for
backwards compatibility. And of course <hap state='off'/> disables hap.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
The function already takes two bool arguments, switching to flags makes
it a lot easier to read. Especially in case we need to add another
boolean in the future.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
