Use virAppendElement instead of virInsertElementsN to implement
VIR_APPEND_ELEMENT_COPY which allows us to remove error handling as the
only relevant errors were removed when switching to aborting memory
allocation functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If the attempt to attach a device failed, we erased the
unattached device from the namespace. This resulted in erasing an
already attached device in case of a duplicate. We need to check
for existing file in the namespace in order to determine erasing
it in case of a failure.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1780508
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When qos is set or delete, we have to check if the port is an ovs managed
port. If true, call the virNetDevOpenvswitchInterfaceSetQos function when qos
is set, and call the virNetDevOpenvswitchInterfaceClearQos function when
the interface is to be destroyed.
Signed-off-by: Jinsheng Zhang <zhangjl02@inspur.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Originally qemuDomainAttachNetDevice() would wait until the cleanup at
the very end of the function to add newly hotplugged interfaces to the
domain's nets list. commit 7b8bec4560 modified it to add the new
interface to the nets list earlier (but not all the way at the
beginning of the function either, because there are some operations
(PCI address assignment in particular) that need the new device to not
yet be visible in the domaindef).
But hostdev interfaces short-circuit past most of the body of
qemuDomainAttachNetDevice() (since none of it applies to hostdev
interfaces). In the past that was okay, but since the line that adds
the new interface to the domaindef's nets list is in that "most of the
body", after that commit hotplugged hostdev interfaces are no longer
being properly added to the domaindef nets list, so they don't show up
in the status XML or the virsh domiflist output.
It really *is* important to add interfaces to the nets list earlier,
so we can't revert commit 7b8bec4560, and we also can't move the
insert to common code *earlier* in the function, so instead this patch
duplicates the VIR_APPEND_ELEMENT_COPY() just before the code path for
hostdev interfaces jumps to cleanup.
Resolves: https://bugzilla.redhat.com/1972468
Fixes: 7b8bec4560
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
126db34a81 had previously switched various
flows over to this from VIR_ERR_OPERATION_FAILED.
This change simply does the same for qemuDomainDetachPrepDisk,
qemuDomainDetachPrepInput and qemuDomainDetachPrepVsock to allow
management apps to centralise their error handling on just
VIR_ERR_DEVICE_MISSING for missing devices during a detach.
Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For validation of explicitly configured addresses we already ported the
same style of checks to qemuValidateDomainDeviceDefAddress and implicit
address assignment should do the right thing in the first place, thus
the function is redundant and can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modify the code in the last two instances in the code to behave as if
the flag is not asserted.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When <transient shareBacking='yes'> is set to a disk and the overlay
disk already exists because of something abnormal, libvirt is terminated
by Segmentation fault.
# virsh start Test0
error: Disconnected from qemu:///system due to end of file
error: Failed to start domain 'Test0'
error: End of file while reading data: Input/output error
Add NULL check for snapdiskdef so that the rollback can work correctly.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Fixes: 2e94002d2a
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
and re-adjust if the hotplug fails.
This fixes a bug found during testing of
https://bugzilla.redhat.com/1939776, which was supposed to be resolved
by commit 98e22ff749, but failed to account for the case of device
hotplug.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
An upcoming patch will be checking if the addition of a new net device
requires adjusting the domain locked memory limit, which must be done
prior to sending the command to qemu to add the new device. But
qemuDomainAdjustMaxMemLock() checks all (and only) the devices that
are currently in the domain definition, and currently we are adding
new net devices to the domain definition only at the very end of the
hotplug operation, after qemu has already executed the device_add
command.
In order for the upcoming patch to work, this patch changes
qemuDomainAttachNetDevice() to add the device to the domain nets list
at an earlier time. It can't be added until after PCI address and
alias name have been determined (because both of those examine
existing devices in the domain to figure out a unique value for the
new device), but must be done before making the qemu monitor call.
Since the device has been added to the list earlier, we need to
potentially remove it on failure. This is done by replacing the
existing call to virDomainNetRemoveHostdev() (which checks if this is
a hostdev net device, and if so removes it from the hostdevs list,
since it could have already been added to that list) with a call to
the new virDomainNetRemoveByObj(), which looks for the device on both
nets and hostdevs lists, and removes it where it finds it.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We have many places where the earliest error returns from a function
skip any cleanup label at the bottom (the assumption being that it is
so early in the function that there isn't yet anything that needs to
be explicitly undone on failure). But in general it is a bad sign if
there are any direct "return" statements in a function at any time
after there has been a "goto cleanup" - that indicates someone thought
that an earlier point in the code had done something needing cleanup,
so we shouldn't be skipping it.
There were two occurences of a "return -1" after "goto cleanup" in
qemuDomainAttachDeviceNet(). The first of these has been around for a
very long time (since 2013) and my assumption is that the earlier
"goto cleanup" didn't exist at that time (so it was proper), and when
the code further up in the function was added, the this return -1 was
missed. The second was added during a mass change to check the return
from qemuInterfacePrepareSlirp() in several places (commit
99a1cfc438); in this case it was erroneous from the start.
Change both of these "return -1"s to "goto cleanup". Since we already
have code paths earlier in the function that goto cleanup, this should
not cause any new problem.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The qemuDomainAttachDiskGeneric will also be used on startup for
transient disks which share the overlay. The VM startup code passes the
asyncJob around so we need to pass it into qemuDomainAttachDiskGeneric.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add code which creates the transient overlay after hotplugging the disk
backend before attaching the disk frontend.
The state of the topmost image is modified to be already read-only to
prevent the need to open the image in read-write mode.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Split up the monitor contexts to attach the backend of the disk and the
frontend device in preparation for hotplugging transient disks where
we'll need to add the code for adding the transient overlay between
these two steps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Modify the rollback section to use its own monitor context so that we
can later split up the hotplug into multiple steps and move the
detachment of the extension device into the rollback section rather than
doing it inline.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Similarly to previous refactors we want to move all hotplug related
setup which isn't strictly relevant to attaching the disk into
qemuDomainAttachDeviceDiskLiveInternal.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Remove the 'ret' variable and 'cleanup' label in favor of directly
returning the value since we don't have anything under the 'cleanup:'
label.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Remove two empty lines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move the auditing entry and insertion into the disk definition from the
function which deals with qemu to 'qemuDomainAttachDeviceDiskLiveInternal'
which deals with the hotplug related specifics.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
qemuDomainAttachDeviceDiskLiveInternal already sets up certain pieces of
the disk definition so it's better suited to move the setup of the
virStorageSource structs, granting access to the storage and allocation
of the alias from qemuDomainAttachDiskGeneric which will be just
handling the qemu interaction.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We can call it in one place as all per-device-type subcases use the same
code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move the validation of the SCSI device address and the attachment of the
controller into qemuDomainAttachDeviceDiskLiveInternal as there's no
specific need for a special helper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move the specific device setup and address reservation code into the
main hotplug helper as it's just one extra function call.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move the specific device setup and address reservation code into the
main hotplug helper as it's just one extra function call.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Unify the handling of the copy-on-read filter by changing the handling
to use qemuBlockStorageSourceChainData.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Fill in the required fields in qemuBlockStorageSourceChainData to handle
the hotplug so that we can simplify the cleanup code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Pre-extending the disk array size is pointless nowadays since we've
switched to memory APIs which don't return failure.
Switch all uses of reallocation of the array followed by
'virDomainDiskInsertPreAlloced' with direct virDomainDiskInsert.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We can skip the formatting of the bootindex for floppies directly at the
place where it's being formatted.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add a disk bus value represending no selected bus. This will help split
up the XML parser.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Note that the wrong "VIR_TRISTATE_*_ABSENT" was used in qemuDomainChangeNet.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Historically, we declared pointer type to our types:
typedef struct _virXXX virXXX;
typedef virXXX *virXXXPtr;
But usefulness of such declaration is questionable, at best.
Unfortunately, we can't drop every such declaration - we have to
carry some over, because they are part of public API (e.g.
virDomainPtr). But for internal types - we can do drop them and
use what every other C project uses 'virXXX *'.
This change was generated by a very ugly shell script that
generated sed script which was then called over each file in the
repository. For the shell script refer to the cover letter:
https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In one of my previous commits I've made an attempt to restore the
noqueue qdisc on a TAP corresponding to domain's <interface/> if
QoS is cleared out. The commit consisted of two almost identical
hunks. In both the pointer is dereferenced. But in one of them,
the pointer to new bandwidth can't be NULL while in the other it
can leading to a crash.
Fixes: d53b092353
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1919619
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
In commit 88957116c9 I've adapted
libvirt to QEMU's deprecation of -mem-path and -mem-prealloc and
switched to memory-backend-* even for system memory. My claim was
that that's what QEMU does under the hood anyway. And indeed it
was: see QEMU commit 900c0ba373aada4c13d47d95330aa72ec4067ba5 and
look at function create_default_memdev().
However, then commit d96c4d5f193e0e45beec80a6277728b32875bddb was
merged into QEMU. While it was fixing a bug, it also changed the
create_default_memdev() function in which it started turning off
use of canonical path (by setting
"x-use-canonical-path-for-ramblock-id" attribute to false). This
wasn't documented until QEMU commit
8db0b20415c129cf5e577a593a4a0372d90b7cc9. The path affects
migration - the same path has to be used on the source and on the
destination. Therefore, if there is old guest started with '-m X'
it has "pc.ram" block which doesn't use canonical path and thus
when migrating to newer QEMU which uses memory-backend-* we have
to turn off the canonical path explicitly. Otherwise,
"/objects/pc.ram" path would be expected by QEMU which doesn't
match the source.
Ideally, we would need to set it only for some machine types
(4.0 and older) because newer machine types already do what we
are doing. However, we treat machine types as opaque strings and
therefore we don't want to parse nor inspect their versions. But
then again, newer machine types already do what we are doing in
this commit, so when old machine types are deprecated and removed
we can remove our hack and forget it ever happened.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1912201
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
A few commits back I've introduced new 'virtio-pmem' <memory/>
device. Since it's virtio it goes onto PCI bus. Therefore, on
hotplug new PCI address is generated (or provided one is
reserved). However, if hotplug fails (for whatever reason) the
address needs to be released. This is different to 'dimm' type of
address because for that type we don't keep a map of used slots
rather generate one on each address assign request. The map is
then thrown away. But for PCI addresses we keep internal state
and thus has to keep it updated. Therefore, this new
qemuDomainReleaseMemoryDeviceSlot() function is NOP for those
models which use 'dimm' address type ('dimm' and 'nvdimm').
While I'm at it, let's release the address in case of hot unplug.
Not that is supported (any such attempt fails with the following
error:
"virtio based memory devices cannot be unplugged"
But if QEMU ever implements hot unplug then we don't have to
remember to fix our code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Get rid of the 'need_release' variable. The code can be rewritten
so that it is not needed.
Signed-off-by: Yi Li <yili@winhong.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Implements QEMU support for vhost-user-blk together with live
hotplug/unplug.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The code handles XML bits and internal definition and should be
in conf directory.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Up until now we had a runtime code and XML related code in the same
source file inside util directory.
This patch takes the runtime part and extracts it into the new
storage_file directory.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The virtio-pmem is a virtio variant of NVDIMM and just like
NVDIMM virtio-pmem also allows accessing host pages bypassing
guest page cache. The difference is that if a regular file is
used to back guest's NVDIMM (model='nvdimm') the persistence of
guest writes might not be guaranteed while with virtio-pmem it
is.
To express this new model at domain XML level, I've chosen the
following:
<memory model='virtio-pmem' access='shared'>
<source>
<path>/tmp/virtio_pmem</path>
</source>
<target>
<size unit='KiB'>524288</size>
</target>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</memory>
Another difference between NVDIMM and virtio-pmem is that while
the former supports NUMA node locality the latter doesn't. And
also, the latter goes onto PCI bus and not into a DIMM module.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
managed='no' on an <interface> allows an unprivileged libvirt to use a
pre-created tap/macvtap device that libvirt has permission to
open/read/write, but no permission to modify (i.e. set the MTU or MAC
address). But when the XML had an <mtu size='blah'/> setting (which
was put there in order to tell the *guest* OS what MTU to set for the
emulated device at the other end of the tap) we were attempting to set
the MTU of the tap device on the host, paying no attention to the
setting of 'managed'. That would of course end in failure.
This patch only sets the MTU if managed='no' is *not* set (so, if it
is 'yes', or just not set at all).
Note that MTU of the tap is also set when connecting the tap to a
bridge device, but managed='no' is only allowed for <interface
type='ethernet'>, which would never attach to a bridge anyway, so we
don't need the check there.
Resolves: https://bugzilla.redhat.com/1905929
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Changes to a virtio network device such as
<interface type="network">
<model type="virtio"/>
<driver iommu="on" ats="on"/> <!-- this line added -->
...
</interface>
were quietly dismissed by `virsh update-device ... --live`.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When an interface has some bandwidth limitation set (it's root
qdisc is htb in that case) but this gets cleared out via public
API call (virDomainSetInterfaceParameters() or
virDomainUpdateDeviceFlags()) then virNetDevBandwidthSet() clears
out whatever qdiscs were set on the interface and kernel places
the default qdisc at the root. What we need to do next is to
replace the root qdisc with the one we want.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1329644
Fixes: 0b66196d86
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
While the code that's setting default qdisc is clever enough to
not overwrite any bandwidth (potentially) set by
virNetDevBandwidthSet() (and thus the root qdisc htb is not
replaced with noqueue), it does print a debug message when that's
the case. It's needless. We can set the root qdisc beforehand and
let virNetDevBandwidthSet() overwrite it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When starting a VM with an empty cdrom which has <iotune> configured the
startup fails as qemu is not happy about setting tuning for an empty
drive:
error: internal error: unable to execute 'block_set_io_throttle', unexpected error: 'Device has no medium'
Resolve this by skipping the setting of throttling for empty drives and
updating the throttling when new medium is inserted into the drive.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/111
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
