When a user provides the backing chain, we will not need to re-detect
all the backing stores again, but should move to the end of the user
specified chain. Additionally if a user provides a full terminated chain
we should not attempt any further detection.
Separate it so that it deals only with single virStorageSource, so that
it can later be reused for full backing chain support.
Two aliases are passed since authentication is more relevant to the
'storage backend' whereas encryption is more relevant to the protocol
layer. When using node names, the aliases will be different.
qemuDomainGetImageIds and qemuDomainStorageFileInit are helpful when
trying to access a virStorageSource from the qemu driver since they
figure out the correct uid and gid for the image.
When accessing members of a backing chain the permissions for the top
level would be used. To allow using specific permissions per backing
chain level but still allow inheritance from the parent of the chain we
need to add a new parameter to the image ID APIs.
Until now we ignored user-provided backing chains and while detecting
the code inherited labels of the parent device. With user provided
chains we should keep this functionality, so label of the parent image
in the backing chain will be applied if an image-specific label is not
present.
Until now we ignored user-provided backing chains and while detecting
the code inherited labels of the parent device. With user provided
chains we should keep this functionality, so label of the parent image
in the backing chain will be applied if an image-specific label is not
present.
virSecuritySELinuxSetImageLabelInternal assigns different labels to
backing chain members than to the parent image. This was done via the
'first' flag. Convert it to passing in pointer to the parent
virStorageSource. This will allow us to use the parent virStorageSource
in further changes.
When the user provides backing chain, we don't need the full support for
traversing the backing chain. This patch adds a feature check for the
virStorageSourceAccess API.
The 'file access' module of the storage driver has few feature checks to
determine whether libvirt supports given storage driver method. The code
to retrieve the driver struct needed for the check is the same so it can
be extracted.
For multipath disks it might be useful to have the same WWN for multiple
disks. It's the users choice to do so. Since we dropped the check that
disallows using duplicate WWNs drop the docs as well.
https://bugzilla.redhat.com/show_bug.cgi?id=1464975
Commit fdeac7a05f tried to fix the output
of 'virsh domxml-to-native --help' by switching types around. One of the
changes broke the option parser. VSH_OT_ARGV should be used only for
variable argument count, not to make the help generator look pretty.
The correct option type in this case is VSH_OT_STRING as it's not
mandatory now since it can be substituted by using --domain.
This makes --help for this command look incorrect, but the parser works
as it should.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1494400
When formatting an inactive or migratable XML we will need to suppress
backing chain members which were detected from the disk to keep
semantics straight. This means we need to record, whether a
virStorageSource originates from autodetection.
The file object is needed when formatting the command line, but it makes
nesting of the objects less easy for use with blockdev. Separate the
wrapping into the 'file' object into a helper used specifically for disk
sources in the old code path.
Express a properly terminated backing chain by putting a
virStorageSource of type VIR_STORAGE_TYPE_NONE in the chain. The newly
used helpers simplify this greatly.
The change fixes a bug as formatting an incomplete backing chain and
parsing it back would end up in expressing a terminated chain since
src->backingStoreRaw was not populated. By relying on the terminator
object this can be now processed appropriately.
Add helpers that will simplify checking if a backing file is valid or
whether it has backing store. The helper virStorageSourceIsBacking
returns true if the given virStorageSource is a valid backing store
member. virStorageSourceHasBacking returns true if the virStorageSource
has a backing store child.
Adding these functions creates a central points for further refactors.
Storage driver uses virStorageSource only partially to store it's
configuration but fully when parsing backing files of storage volumes.
This patch sets the 'type' field to a value other than
VIR_STORAGE_TYPE_NONE so that further patches can add a terminator
element to backing chains without breaking iteration.
The backing store indexes were not bound to the storage sources in any
way. To allow us to bind a given alias to a given storage source we need
to save the index in virStorageSource. The backing store ids are now
generated when detecting the backing chain.
Since we don't re-detect the backing chain after snapshots, the
numbering needs to be fixed there.
Index will remain an internal property even if we allow backing store
parsing from the XML, so we need to allow backing store without it in
the schema.
Skip purging the backing chain and redetecting it when it was not going
to change during the time we were not present.
The decision is based on the new flag which records whether there were
blockjobs running to the status XML.
Unindent the static XML block and move around the autoindent calls so
that further additions don't have to add more of them.
Also rename the string holding the static XML section.
For VMs with persistent config the config may change upon successful
completion of a job. Save it always if a persistent VM finishes a
blockjob. This will simplify further additions.
The status XML would be saved only for the copy job (in case of success)
or on failure even for other jobs. As the status contains the backing
chain data, which change after success we should always save it on
block job completion.
Checking of disk presence accesses storage on the host so it should be
done from the host setup function. Move the code to new function called
qemuProcessPrepareHostStorage and remove qemuDomainCheckDiskPresence.
Introduce a new function to prepare domain disks which will also do the
volume source to actual disk source translation.
The 'pretend' condition is not transferred to the new location since it
does not help in writing tests and also no tests abuse it.
Pass flags to the function rather than just whether we have incoming
migration. This also enforces correct startup policy for USB devices
when reverting from a snapshot.
qemuMigrationPrepareAny called multiple of the functions starting the
qemu process for incoming migration by adding the flags explicitly.
Extract them to a variable so that they can be easily used for other
calls or changed in the future.
virDomainDiskSourceParse got to the point of being an ugly spaghetti
mess by adding more and more stuff into it. Split out parsing of network
disk information into a separate function so that it stays contained.
VM private data is cleared when the VM is turned off and also when the
VM object is being freed. Some of the clearing code was duplicated.
Extract it to a separate function.
This also removes the now unnecessary function
qemuDomainClearPrivatePaths.
Some values we read from the qemu monitor may be changed with the actual
state by the incoming migration. This means that we should refresh
certain things only after the migration has finished.
This is mostly visible in the cdrom tray state, which is by default
closed but may be opened by the guest OS. This would be refreshed before
qemu transferred the actual state and thus libvirt would think that the
tray is closed.
Note that this patch moves only a few obvious query commands. Others may
be moved later after individual assessment.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463168
When the vcpu is successfully removed libvirt would remove the cgroup.
In cases when removal of the cgroup fails libvirt would report an error.
This does not make much sense, since the vcpu was removed and we can't
really do anything with the cgroup. This patch silences the errors from
cgroup removal.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1462092
The alias recorded in disk->info.alias is the alias for the frontend
device but we are interested in the backend drive. This messed up the
disk node name extraction code as qemu reports the drive alias in the
block query commands. This was broken in the node name detector
refactoring done in commit 0175dc6ea0
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1494327
Some distros (see diff) chose to backport QMP support rather than rebase
to newer version of qemu. As a hack they added the string 'libvirt' to
the qemu -help output. Remove this as downstream-only hacks should be
carried by downstream and not litter upstream.
This effectively reverts commit ff88cd5905
Documentation states:
"'offset' and 'size' represent an area which must lie entirely within
the device or file." Enforce the that the buffer lies within fully.
Commit 3956af495e broke the blockPeek API since virStorageFileRead
allocates a return buffer and fills it with the data, while the API
fills a user-provided buffer. This did not get caught by the compiler
since the API prototype uses a 'void *'.
Fix it by transferring the data from the allocated buffer to the user
provided buffer.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1491217
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
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.
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: Eric Blake <eblake@redhat.com>
Commit 703abf1d7 changed the logic so that we don't attempt to re-create
the image if it's a block device. This was done by modifying the
'reuse' variable. Unfortunately after modifying it one of the uses was
to infer whether we should probe the disk format. After changes in the
commit mentioned above we would attempt the probe if the target of the
copy is a block device and the format was not provided explicitly rather
than using the format of the disk.
Fix it by explicitly checking whether the user requested a reuse of the
disk rather than the modified boolean flag.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490826
Use the new facility which allows to ignore failures in post parse
callbacks if they are not fatal so that VM configs are not lost if the
emulator binary is missing.
If qemuCaps can't be populated on daemon restart skip certain portions
of the post parse callbacks during config reload and re-run the callback
during VM startup.
This fixes VMs vanishing if the emulator binary was broken or
uninstalled and libvirtd was restarted.
qemuDomainControllerDefPostParse assigns the default USB controller
model when it was not specified by the user. Skip this step if @qemuCaps
is missing so that we don't fill wrong data. This will then be fixes by
re-running the post parse callback.
Report the given GIC version as unsupported if @qemuCapsi is NULL. This
will be helpful to run post parse callbacks even if qemu is not
currently installed.
If qemuCaps are not present, just return the original machine type name.
This will help in situations when qemuCaps is not available in the post
parse callback.
Some failures of the post parse callback can be tolerated. This is
specifically desired when loading the configs of existing VMs. In such
case the post parse callback should not really be modifying anything
in the definition.
This patch adds a parse flag VIR_DOMAIN_DEF_PARSE_ALLOW_POST_PARSE_FAIL
which will allow the callbacks to report non-fatal failures by returning
a positive return value. In such case the field 'postParseFailed' in the
domain definition is set to true, to notify the drivers that the
callback failed and possibly needs to be re-run.
Post parse callbacks will need to be able to signal that they failed
non-fatally. This means that we need to return the value returned by the
callback without modification.
The domain post parse callback, domain address callback and the domain
device callback (for every single device) would each grab qemuCaps for
the current emulator. This is quite wasteful. Use the new callback to do
this just once.
Some drivers use def-specific private data across callbacks (e.g.
qemuCaps in the qemu driver). Currently it's mostly allocated in every
single callback. This is rather wasteful, given that every single call
to the device callback allocates it.
The new callback will allocate the data (if not provided externally) and
then use it for the VM, address and device post parse callbacks.
Add yet another post parse callback, which is executed prior the real
one without @parseOpaque. This is meant to set basics before
@parseOpaque (in case of the qemu driver qemuCaps) can be allocated.
This callback will allow to optimize passing of custom parseOpaque
through the callbacks.
The helper returns true if a string contains any of the given chars.
virStringHasControlChars can be reimplemented using that helper.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
It turns out that our implementation of the hashing function is
endian-dependent and thus if used on various architectures the testsuite
may have different results. Work this around by mocking virHashCodeGen
to something which does not use bit operations instead of just setting a
deterministic seed.
Prior to qemu 2.5 the node names would not be generated, thus would be
missing from 'query-blockstats' and 'query-named-block-nodes'. Test that
the code correctly detects nothing.
Additionally make sure that a VM without disks does not cause problems.
The test case change is necessary as our test file checker does not play
well with empty files.
Treat an NULL string equivalent to an empty string in
virTestCompareToFile so that callers don't need to add additional logic
in case when a test produces no output.
'virt-aa-helper' is compiled when both WITH_LIBVIRTD and
WITH_SECDRIVER_APPARMOR are defined. The test was run only when
WITH_SECDRIVER_APPARMOR was defined thus causing a build failure when
building without the daemon.
In commit 5e515b542d I've attempted to fix the inability to access
storage from the apparmor helper program by linking with the storage
driver. By linking with the .so the linker complains that it's not
portable. Fix this by loading the module dynamically as we are supposed
to do.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Driver modules proved to be reliable for a long time. Since support for
not building modules complicates the code and makefiles drop it.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
qemu 2.9 returns an extra layer in the backing data if a block job is
active. Add a test case to see whether our code properly detects and
ignores such layer.
The test data was prepared by creating a backing chain of qcow2 images
(with qemu-img and with libvirt's snapshot feature).
One of the layers was then merged back by doing a block-commit:
virsh blockcommit VM hda --top /var/lib/libvirt/images/b
and then a block-copy job was started and kept in synchronized phase:
virsh blockcopy VM hda /tmp/tgt.img --transient job
Reviewed-by: Eric Blake <eblake@redhat.com>
Add the blockstats data and fix the expected output.
Test data was created as:
qemu-img create -f qcow2 img0 10M
qemu-img create -f qcow2 -o "backing_fmt=qcow2,backing_file=img0" img1
qemu-img create -f qcow2 -o "backing_fmt=qcow2,backing_file=img1" img2
...
Reviewed-by: Eric Blake <eblake@redhat.com>
With the new approach we are actually able to correctly detect node
names for the two instances of the same backing file.
Test images were created as:
qemu-img create -f qcow2 /var/lib/libvirt/images/base.qcow2 10M
qemu-img create -f qcow2 \
-o "backing_fmt=qcow2,backing_file=/var/lib/libvirt/images/base.qcow2 \
/var/lib/libvirt/images/a.qcow2
qemu-img create -f qcow2 \
-o "backing_fmt=qcow2,backing_file=/var/lib/libvirt/images/base.qcow2 \
/var/lib/libvirt/images/b.qcow2
and then used for two separate disks.
Reviewed-by: Eric Blake <eblake@redhat.com>
We can now iterate the hash table and print all detected backing chains.
This simplifies calling of the test cases.
Reviewed-by: Eric Blake <eblake@redhat.com>
virHashNew calls virRandomBits to initialize seed for the hashing
function. If a test uses iteration through the hash table to produce
results they may/will be non-deterministic. Extract the mock library
which was used for mac address mapping to be universal.
Reviewed-by: Eric Blake <eblake@redhat.com>
Remove the complex and unreliable code which inferred the node name
hierarchy only from data returned by 'query-named-block-nodes'. It turns
out that query-blockstats contain the full hierarchy of nodes as
perceived by qemu so the inference code is not necessary.
In query blockstats, the 'parent' object corresponds to the storage
behind a storage volume and 'backing' corresponds to the lower level of
backing chain. Since all have node names this data can be really easily
used to detect node names.
In addition to the code refactoring the one remaining test case needed
to be fixed along.
Reviewed-by: Eric Blake <eblake@redhat.com>
Peter Krempa