These operations aren't necessarily time consuming, but need to
wait in the queue of modify jobs.
Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com>
These operations aren't necessarily time consuming, but need to
wait in the queue of modify jobs.
Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com>
Large balloon operation can be time consuming. Use the recently
added job functions and unlock the virDomainObj while ballooning.
Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com>
Creating a large domain could potentially be time consuming. Use the
recently added job functions and unlock the virDomainObj while
the create operation is in progress.
Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com>
Follows the pattern used in the libxl driver for managing multiple,
simultaneous jobs within the driver.
Signed-off-by: Katerina Koukiou <k.koukiou@gmail.com>
If the stats for a block device can't be acquired from qemu we've
fallen back to loading them from the file on the disk in libvirt.
If qemu is not cooperating due to being stuck on an inaccessible NFS
share we would then attempt to read the files and get stuck too with
the VM object locked. All other APIs would eventually get stuck waiting
on the VM lock.
Avoid this problem by skipping the block stats if the VM is online but
the monitor did not provide any stats.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1337073
Some Intel processor families (e.g. the Intel Xeon processor E5 v3
family) introduced some RDT (Resource Director Technology) features
to monitor or control shared resource. Among these features, MBM
(Memory Bandwidth Monitoring), which is build on the CMT (Cache
Monitoring Technology) infrastructure, provides OS/VMM a way to
monitor bandwidth from one level of cache to another.
With current perf framework, this patch adds support to perf event
for MBM.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
vz puts uuids into curly braces. Simply introduce new contstant to reflect this
and get rid of magic +2 in code.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Peer to peer migration is implemented just as in managed case. Basically
it is copy paste from managed case but with all the branches that are not
applied to vz removed.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
The newest version of migration protocol - version 3 with parameters is implemented.
Supported flags is VIR_MIGRATE_PAUSED only. Supported parameters are
VIR_MIGRATE_PARAM_URI and VIR_MIGRATE_PARAM_DEST_NAME. VIR_MIGRATE_PARAM_DEST_XML
is in VZ_MIGRATION_PARAMETERS for technical onyl reasons.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
This session uuid acts as authN token for different multihost vz operations one
of which is migration. Unfortunately we can't get it from server at any time
thus we need to save it at login.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Finally wire-up virAdmServer{Get,Set}ClientLimits APIs into virt-admin client.
Update the virt-admin's man page accordingly.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Opposite operation to virAdmServerGetClientLimits. Understandably though,
setting values for current number of clients connected or still waiting
for authentication does not make sense, since changes to these values are event
dependent, i.e. a client connects - counter is increased. Thus only the limits
to maximum clients connected and waiting for authentication can be set. Should
a request for other controls to be set arrive (provided such a setting will
be first introduced to the config), the set of configuration controls can be
later expanded (thanks to typed params). This patch also introduces a
constraint that the maximum number of clients waiting for authentication has to
be less than the overall maximum number of clients connected and any attempt to
violate this constraint will be denied.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Enable retrieval of the number of maximum clients connected to all sockets
combined, as well as the number of maximum clients waiting for authentication,
in order to be successfully connected. These are the attributes configurable
through libvirtd.conf, however, it could be handy to not only know values for
these limits, but also the values for the current number of clients
connected and number of clients currently waiting for authentication which are
changing dynamically. This API does both, retrieves the limits as well as the
current dynamic values.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
In order for typed params validation to pass on daemon side, we should
encourage users to use our exported constants with typed params to diminish
to avoid any potential problems related to argument validity.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Add some trivial getters for client related attributes to virnetserver before
any admin method can be introduced.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
QEMU needs access to the /dev/dri/render* device for
virgl to work.
Allow access to all /dev/dri/* devices for domains with
<video>
<model type='virtio' heads='1' primary='yes'>
<acceleration accel3d='yes'/>
</model>
</video>
https://bugzilla.redhat.com/show_bug.cgi?id=1337290
All qemu versions we support have QEMU_CAPS_DEVICE, so checking
for it is redundant. Remove the usage.
The code diff isn't clear, but all that code is just inindented
with no other change.
Test cases that hit qemuDomainAssignAddresses but don't have
infrastructure for specifying qemuCaps values see lots of
churn, since now PCI addresses are in the XML output.
Upcoming patches are going to make the disk portion of these
test cases fail. In order to make it work, we would need to
extend the qemuargv2xml test infrastructure to handle qemuCaps.
This is worthwhile to do at some point but isn't critical.
Instead just drop the offending portion, which isn't even the
target of the test cases anyways
hotplug APIs with the AFFECT_CONFIG flag are essentially replicating
'insert <device> into XML document, and redefine XML'. Thinking of
it this way, it's natural that we call virDomainDefPostParse after
manually editing the XML here.
Not only does doing so allow us to drop a bunch of open coded calls
to qemuDomainAssignAddresses, but it also means we are going through
the standard channels for XML validation and potentially catching
errors in user submitted XML.
This wires up qemuDomainAssignAddresses into the new
virDomainDefAssignAddressesCallback, so it's always triggered
via virDomainDefPostParse. We are essentially doing this already
with open coded calls sprinkled about.
qemu argv parse output changes slightly since previously it wasn't
hitting qemuDomainAssignAddresses.
This solution does not keep snapshots cache because vz sdk lacks good support
for snapshot related events.
Libvirt and vz sdk has different approach to snapshot ids. vz sdk always
auto generate them while libvirt has ability to specify id by user.
Thus I have no other choice rather than simply ignore ids set by user
or generated by libvirt.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1331552
Instead of disabling auto-login of all scsi targets (even those
that do not "belong" to libvirt), use iscsiadm's "--op nonpersistent"
during discovery of iSCSI targets (e.g. "iscsiadm --mode discovery
--type sendtargets") in order to avoid the node database being altered
which led to the need for the "large hammer" approach taken by
commit id '3c12b654'.
This commit removes the virISCSITargetAutologin adjustment (eg. the setting
of node.startup to "manual"). The iscsiadm command has supported this mode
of operation as of commit id 'ad873767' to open-iscsi.
Utilize the exit status parameter for virCommandRunRegex in order to
check the return error from the 'iscsiadm --mode session' command.
Without this enabled, if there are no sessions running then virCommandRun
would have displayed an error such as:
2016-05-13 15:17:15.165+0000: 10920: error : virCommandWait:2553 :
internal error: Child process (iscsiadm --mode session)
unexpected exit status 21: iscsiadm: No active sessions.
It is possible that for certain paths (when probe is true) we only care
whether it's running or not to make certain decisions. Spitting out
the error for those paths is unnecessary.
If we do have a situation where probe = false and there's an error,
then display the error from iscsiadm if it's there.
Rather than have virCommandRun just spit out the error, allow callers
to decide to pass the exitstatus so the caller can make intelligent
decisions based on the error.
The only case where the hardware capabilities influence the result
is when no <gic/> element was provided.
The test programs now ensure both that the correct GIC version is
picked in that case, and that hardware capabilities are not taken
into account when the user has already picked a GIC version.
Now that we choose the GIC version based on hardware features when
no <gic/> element has been provided, we need a way to fake the GIC
capabilities of the host.
Update the qemuxml2argv and qemuxml2xml tests to allow this.
When the <gic/> element in not present in the domain XML, use the
domain capabilities to figure out what GIC version is usable and
choose that one automatically.
This allows guests to be created on hardware that only supports
GIC v3 without having to update virt-manager and similar tools.
Keep using the default GIC version if the <gic/> element has been
added to the domain XML but no version has been specified, as not
to break existing guests.
According to current xl.cfg docs and xl codes, it uses type=vif
instead of type=netfront.
Currently after domxml-to-native, libvirt xml model=netfront will be
converted to xl type=netfront. This has no problem before, xen codes
for a long time just check type=ioemu, if not, set type to _VIF.
Since libxl uses parse_nic_config to avoid duplicate codes, it
compares 'type=vif' and 'type=ioemu' for valid parameters, others
are considered as invalid, thus we have problem with type=netfront
in xl config file.
#xl create sles12gm-hvm.orig
Parsing config from sles12gm-hvm.orig
Invalid parameter `type'.
Correct the conversion in libvirt, so that it matchs libxl codes
and also xl.cfg.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
It was only needed for rpm versions that are much older than our
minimally supported distro
Some more details here: https://fedorahosted.org/fpc/ticket/77
