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>
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>
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.
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.
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>
SDK handles empty cdroms all right. We just need to
pass "" instead of NULL (not setting is good too).
However we can get problems here. Disk detaching treats source
as ids. Fortunately disk detaching is not supported for cdroms
yet and for hard disks we can not get empty source - this is prohibitited
by xml parsing code.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
Current version of the function does not check format of cdroms at all.
At the same time prlsdkGetDiskInfo give hints that cdroms always
have format VIR_STORAGE_FILE_RAW. So fix vzCheckUnsupportedDisks.
About structure of checks. As we don't have means to store format
in SDK we always have only one format in every situation. So instead
of setting boolean let's get allowed format instead and finally compare
it to the requested. This structure of checks seems stable to me
because we have only one format in every situation.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
VIR_STORAGE_FILE_AUTO can not be set from xml description.
At the same time we don't set disks format to this value
as for example qemu does. Thus this we can never get this
value in format.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
We support omitting listen attribute of graphics element so we should
also support omitting address attribute of listen element. This patch
also updates libvirt to always add a listen element into domain XML
except for VNC graphics if socket attribute is specified.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Move the compatibility code out of virDomainGraphicsListensParseXML()
into virDomainGraphicsListenDefParseXML(). This also fixes a small
inconsistency between the code and error message itself.
Before this patch we would search first listen element that is
type='address' to validate listen and address attributes. After this
patch we always take the first listen element regardless of the type.
This shouldn't break anything since all drivers supports only one
listen.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If socket attribute is present we start VNC that listens only on that
unix socket. This makes the parser behave the same way as we actually
use the socket attribute.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Commit 82ba41108a made possible to use direct mapped iSCSI
volumes in qemu as disk sources but didn't remove the define time check.
Rework the check by simplifying the condition and allow any volumes to
be used with disk type='lun'.
The only QEMU versions that don't have such capability are <0.12,
which we no longer support anyway.
Additionally, this solves the issue of some QEMU binaries being
reported as not having such capability just because they lacked
the {kvm-}pci-assign QMP object.
Commit id 'f9edcfa4' added cookie manipulation for libxl; however, some
cookie crumb cleanup was missed. Found by Coverity.
In libxlDomainMigrationBegin, the cookie is allocated and baked; however,
the mig ingredients weren't cleaned up.
In libxlDomainMigrationPrepare, when the 'mig' cookie is added to the
args, set the 'mig = NULL'; otherwise, other failure paths between when
the code ate the cookie data and when it was added to args would fail
to clean up the crumbs.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Recent adjustments to the code produced a litany of coverity false
positives, but only because the "standard" procedure of setting a
variable to NULL after it was assigned to something else and keeping
the *Free/*FREE call in the cleanup path wasn't kept. So this patch
makes those adjustments (assign variable to NULL and remove the if
'ret < 0' condition to clean it up).
Signed-off-by: John Ferlan <jferlan@redhat.com>
When searching for the best CPU model for CPUID data we can easily
ignore models with non-matching vendor before spending time on CPUID
data to virCPUDef conversion.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Splitting the comparison into a separate function makes the code cleaner
and easier to update in the future.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Rather than returning a "char *" indicating perhaps some sized set of
characters that is NUL terminated, alter the function to return 0 or -1
for success/failure and add two parameters to handle returning the
buffer and it's size.
The function no longer encodes the returned secret, rather it returns
the unencoded secret forcing callers to make the necessary adjustments.
Alter the callers to handle the adjusted model.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Call the internal driver callbacks rather than the public APIs to avoid
calling unnecessarily the error dispatching code and don't overwrite
the error messages provided by the APIs. They are good enough to
describe which secret is missing either by UUID or the usage (basically
name).
For a few cases where we handle secret information it's good to clear
the buffers containing sensitive data before freeing them.
Introduce VIR_DISPOSE, VIR_DISPOSE_N and VIR_DISPOSE_STRING that allow
simple clearing fo the buffers holding sensitive information on cleanup
paths.
When -cpu host is supported by a QEMU binary, a user can use
<cpu mode='host-passthrough'/> in domain XML even when libvirtd failed
to find a matching model for the host CPU. Let's make it obvious by
advertising <cpuselection/> guest capability whenever -cpu host is
supported.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
When probing the <emulator> with '-help' to determine if
it is the old qemu, errors are reported if the emulator
doesn't exist
libvirt: error : internal error: Child process
(/usr/lib/xen/bin/qemu-dm -help) unexpected exit status 127:
libvirt: error : cannot execute binary /usr/lib/xen/bin/qemu-dm:
No such file or directory
Avoid the probe if the specified emulator doesn't exist,
squelching the error. There is no behavior change since
libxlDomainGetEmulatorType() would return
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN if the probe failed
via virCommandRun().
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Move some parts of virStorageFileRemoveLastPathComponent
into a separate function so they can be reused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Further followup discussions in list on commit 192a53e concluded
that we should be leaving out the USB controller only for
i440fx machines as default USB can be used by someone on q35
at random slots.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Move filling out the default video (v)ram to DeviceDefPostParse.
This means it can be removed from virDomainVideoDefParseXML
and qemuParseCommandLine. Also, we no longer need to special case
VIR_DOMAIN_VIRT_XEN, since the per-driver callback gets called
before the generic one.
Commit 6879be48 moved adding of an implicit video device after XML
parsing. As a result, libxlDomainDeviceDefPostParse() is no longer
called to set the default vram when adding an implicit device.
Commit 6879be48 assumes virDomainVideoDefaultRAM() will set the
default vram, but it returns 0 if the domain virtType is
VIR_DOMAIN_VIRT_XEN. Attempting to start an HVM domain with vram=0
results in
error: unsupported configuration: videoram must be at least 4MB for CIRRUS
The default vram setting for Xen HVM domains depends on the device
model used (qemu-xen vs qemu-traditional), hence setting the
default is deferred to libxlDomainDeviceDefPostParse().
Call the device post-parse callback even for implicit video,
to fill out the default vram even for VIR_DOMAIN_VIRT_XEN.
https://bugzilla.redhat.com/show_bug.cgi?id=1334557
Most-of-commit-message-by: Jim Fehlig <jfehlig@suse.com>
Both virGetLastError and virGetLastErrorMessage call virLastErrorObject method
that returns a thread-local error object. However, if a direct call to malloc
or pthread_setspecific (probably also due to malloc, since it sets ENOMEM)
fail, virLastErrorObject returns NULL which, although incorrectly interpreted
by virGetLastError as no error, still requires the caller to check for NULL
pointer. This isn't the case with virGetLastErrorMessage that also treated it
incorrectly as no error, but returned the literal "no error".
This patch tweaks the checks in the virGetLastErrorMessage function, so that
if virLastErrorObject failed, it returned "unknown error" which is equivalent
to the current approach with virGetLastError and if it returned NULL,
"unknown error" was set.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commit id 'df1011ca8' modified virStorageBackendDiskDeleteVol to use
"dmsetup remove --force" to remove the volume, but left things in an
inconsistent state since the partition still existed on the disk and
only the device mapper device (/dev/dm-#) was removed.
Prior to commit '1895b421' (or '1ffd82bb' and '471e1c4e'), this could
go unnoticed since virStorageBackendDiskRefreshPool wasn't called.
However, the pool would be unusable since the /dev/dm-# device would
be removed even though the partition was not removed unless a multipathd
restart reset the link. That would of course make the volume appear again
in the pool after a refresh or pool start after libvirt reload.
This patch removes the 'dmsetup' logic and re-implements the partition
deletion logic for device mapper devices. The removal of the partition
via 'parted rm --script #' will cause udev device change logic to allow
multipathd to handle removing the dm-* device associated with the partition.
https://bugzilla.redhat.com/show_bug.cgi?id=1265694
Commit id '020135dc' didn't quite get the algorithm correct when a
device mapper source ended with a non numeric value (e.g. ends with
an alphabet value).
This patch modifies the 'part_separator' logic to add the "p" separator
to the attempted target path name only when specified as part_separator='yes'.
For a source name that already ends with a number, the logic doesn't change
as the part separator would need to be there.
For a source name that ends with something other than a number, this allows
the possibility that a "p" separator can be added. The default for one of
these source devices is to not add the separator.
The key for device mapper and the need for a partition separator "p" is
the presence of a number in the last character of the device name link
in /dev/mapper. A name such as "/dev/mapper/mpatha1" would generate
a "/dev/mapper/mpatha1p1" partition, while "/dev/mapper/mpatha" would
generate partition "/dev/mapper/mpatha1". Similarly for a device
mapper entry not using friendly names or an alias, a device such as
"/dev/mapper/3600a0b80005b10ca00005ad656fd8d93" would generate a
paritition "/dev/mapper/3600a0b80005b10ca00005ad656fd8d93p1", while
a device such as "/dev/mapper/3600a0b80005b10ca00005e115729093f" would
generate a partition "/dev/mapper/3600a0b80005b10ca00005e115729093f1".
The long number is the WWID of the device. It's also possible to assign
an alias for a device mapper entry, that alias follows the same rules
with respect to ending with a number or not when adding a "p" to create
the target device path.
Prior to calling the 'refreshPool' during CreatePool or UploadPool
operations, we need to clear the pool; otherwise, the pool will
have duplicated entries.
https://bugzilla.redhat.com/show_bug.cgi?id=1318993
Commit id 'dd519a294' caused a regression cloning a volume into a
logical pool by removing just the 'allocation' adjustment during
storageVolCreateXMLFrom. Combined with the change to not require the
new volume input XML to have a capacity listed (commit id 'e3f1d2a8')
left the possibility that a zero allocation value (e.g., not provided)
would create a thin/sparse logical volume. When a thin lv becomes fully
populated, then LVM sets the partition 'inactive' and the subsequent
fdatasync() fails.
Add a new 'has_allocation' flag to be set at XML parse time to indicate
that allocation was provided. This is done so that if it's not provided
the create-from code uses the capacity value since we document that if
omitted, the volume will be fully allocated at time of creation.
For a logical backend, that creation time is 'createVol', while for a
file backend, creation doesn't set the size, but the 'createRaw' called
during buildVolFrom will decide whether the file is sparse or not based
on the provided capacity and allocation value.
For volume clones that provide different allocation and capacity values
to allow for sparse files, there is no change.
Usage of this keyword in front of function declaration that is exported via a
header file is unnecessary, since internally, this has been the default for most
compilers for quite some time.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
libvirt may automatically add a pci-root or pcie-root controller to a
domain, depending on the arch/machinetype, and it hopefully always
makes the right decision about which to add (since in all cases these
controllers are an implicit part of the virtual machine).
But it's always possible that someone will create a config that
explicitly supplies the wrong type of PCI controller for the selected
machinetype. In the past that would lead to an error later when
libvirt was trying to assign addresses to other devices, for example:
XML error: PCI bus is not compatible with the device at
0000:00:02.0. Device requires a PCI Express slot, which is not
provided by bus 0000:00
(that's the error message that appears if you replace the pcie-root
controller in a Q35 domain with a pci-root controller).
This patch adds a check at the same place that the implicit
controllers are added (to ensure that the same logic is used to check
which type of pci root is correct). If a pci controller with index='0'
is already present, we verify that it is of the model that we would
have otherwise added automatically; if not, an error is logged:
The PCI controller with index='0' must be " model='pcie-root' for
this machine type, " but model='pci-root' was found instead.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004602
