Now that we have strong PRNG generator implemented in
virRandomBytes() let's use that instead of gnulib's random_r.
Problem with the latter is in way we seed it: current UNIX time
and libvirtd's PID are not that random as one might think.
Imagine two hosts booting at the same time. There's a fair chance
that those hosts spawn libvirtds at the same time and with the
same PID. This will result in both daemons generating the same
sequence of say MAC addresses [1].
1: https://www.redhat.com/archives/libvirt-users/2018-May/msg00097.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
While /dev/urandom is not terrible source of random data
gnutls_rnd is better. Prefer that one.
Also, since nearly every platform we build on already has gnutls
(if not all of them) this is going to be used by default.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Instead of having each caller report error move it into the
function. This way we can produce more accurate error messages
too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
To unify our vir*Random() functions we need to make
virCryptoGenerateRandom NOT allocate return buffer. It should
just fill given buffer with random data.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When generating random stream using gnults fails an error is
reported. However, the error is not helpful as it contains only
an integer error code (a negative number). Use gnutls_strerror()
to turn the error code into a string explaining what went wrong.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function allocates a buffer, fills it in with random bytes
and then returns it. However, the buffer is held in @buf
variable, therefore having @ret variable which does not hold
return value of the function is misleading.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
In libvirt when a function wants to return an error code it
should be a negative value. Returning a positive value (or zero)
means success. But virRandomBytes() does not follow this rule.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
When parsing domain XML the virCapsDomainData lookup is performed
in order to fill in missing def->os.arch and def->os.machine
strings. Well, when doing copy of already existing virDomainDef
we don't want any automagic fill in of defaults (and those two
strings are going to be provided at this point anyway by first
parse of the domain XML).
What is even worse is that we do not look up capabilities for
parsed emulator path rather some generic capabilities for parsed
arch. Therefore, if emulator points to qemu under non-default
path (say $HOME/qemu-system-arm) but there's no such qemu under
the default path (say /usr/bin/qemu-system-arm) the capabilities
lookup fails and creating the copy is denied.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The first feature is SCSI persistent reservation, the other is
support for multihead screenshots.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When preparing qemuCaps for test cases the following is
happening:
qemuTestParseCapabilitiesArch() is called, which calls
virQEMUCapsLoadCache() which in turn calls
virQEMUCapsInitHostCPUModel() which sets qemuCaps->kvmCPU and
qemuCaps->tcgCPU.
But then the code tries to update the capabilities:
testCompareXMLToArgv() calls testUpdateQEMUCaps() which calls
virQEMUCapsInitHostCPUModel() again overwriting previously
allocated memory. The solution is to free host cpuData in
testUpdateQEMUCaps().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
There's no point in calling testInitQEMUCaps() (which sets
info.qemuCaps) only to overwrite (and leak) it on the very next
line.
==12962== 296 (208 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 265 of 331
==12962== at 0x4C2CF26: calloc (vg_replace_malloc.c:711)
==12962== by 0x5D28D9F: virAllocVar (viralloc.c:560)
==12962== by 0x5D96AB4: virObjectNew (virobject.c:239)
==12962== by 0x56DB7C7: virQEMUCapsNew (qemu_capabilities.c:1480)
==12962== by 0x112A5B: testInitQEMUCaps (qemuxml2argvtest.c:361)
==12962== by 0x1371C8: mymain (qemuxml2argvtest.c:2871)
==12962== by 0x13AD0B: virTestMain (testutils.c:1120)
==12962== by 0x1372FD: main (qemuxml2argvtest.c:2883)
Removing the function call renders @gic argument unused therefore
it's removed from the macro (and all its callers).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We need to free return value of virXPathString().
==12962== 37 bytes in 1 blocks are definitely lost in loss record 156 of 331
==12962== at 0x4C2AF0F: malloc (vg_replace_malloc.c:299)
==12962== by 0x91E8439: strdup (in /lib64/libc-2.25.so)
==12962== by 0x5DBD551: virStrdup (virstring.c:977)
==12962== by 0x5DD3E5E: virXPathString (virxml.c:84)
==12962== by 0x5E178AB: virDomainDefParseXML (domain_conf.c:19110)
==12962== by 0x5E1E985: virDomainDefParseNode (domain_conf.c:20885)
==12962== by 0x5E1E7CB: virDomainDefParse (domain_conf.c:20827)
==12962== by 0x5E1E871: virDomainDefParseFile (domain_conf.c:20853)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Trying to set any cache for <disk device='lun'/> makes no sense.
Such disk translates into -device scsi-block on the command line
and the device lacks any cache setting because it's merely a
middle man between qemu and real SCSI device.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The virDomainDetachDeviceAlias API is designed so that it only
sends detach request to qemu. It's user's responsibility to wait
for DEVICE_DELETED event, not libvirt's. Add @async flag to
qemuDomainDetach*Device() functions so that caller can chose if
detach is semi-synchronous (old virDomainDetachDeviceFlags()) or
fully asynchronous (new virDomainDetachDeviceFlags()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The fact that we are overwriting @ret multiple times makes it
difficult to see what is actually happening here. Follow our
traditional pattern where @ret is initialized to -1, and set to 0
only in case we know we succeeded.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Funny, we obtain driver caps at the beginning of the function,
but then for unknown reason access driver->caps directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We are overwriting @ret a lot. It makes hard to see what is
actually going on. Use more gotos. Two functions are fixed here:
qemuDomainDetachShmemDevice() and qemuDomainDetachWatchdog().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On watchdog unplug, when qemu doesn't support DEVICE_DELETED event
(or couple of other reasons) we do two things:
1) release watchdog device address,
2) call qemuDomainRemoveWatchdog() which does 1) again.
This is potentially dangerous.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On shmem unplug, when qemu doesn't support DEVICE_DELETED event
(or couple of other reasons) we do two things:
1) release shmem device address,
2) call qemuDomainRemoveShmemDevice() which does 1) again.
This is potentially dangerous.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Instead of releasing address only sometimes in
qemuDomainDetachChrDevice() let's release it whenever the device
is actually removed from the domain definition.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When detaching a device it can be uniquely identified by its
alias. Instead of misusing virDomainDetachDeviceFlags which has
the same signature introduce new function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1534418
Just like ec982f6d92 denies hugepages for non-existent
guest NUMA nodes in case there are some nodes configured.
Unfortunately, when there are none, qemuBuildNumaArgStr() is not
called and thus we have to have check in qemuBuildMemPathStr()
too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
According to virDomainScreenshot() documentation, screens are
numbered sequentially. e.g. having two graphics cards, both with
four heads, screen ID 5 addresses the second head on the second
card.
But apart from that, there's nothing special happening here.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
As of v2.12.0-rc0~32^2 QEMU is capable specifying which display
device and head should the screendump be taken from. Track this
capability so that we can use it later in our virDomainScreenshot
API.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
==1589== 7 bytes in 2 blocks are definitely lost in loss record 34 of 261
==1589== at 0x4C2AF0F: malloc (vg_replace_malloc.c:299)
==1589== by 0x8A82794: xmlStrndup (in /usr/lib64/libxml2.so.2.9.8)
==1589== by 0x5DD8392: virXMLPropString (virxml.c:510)
==1589== by 0x5E12427: virDomainMemoryDefParseXML (domain_conf.c:15704)
==1589== by 0x5E207DE: virDomainDefParseXML (domain_conf.c:20351)
==1589== by 0x5E2184F: virDomainDefParseNode (domain_conf.c:20636)
==1589== by 0x5E216A1: virDomainDefParse (domain_conf.c:20580)
==1589== by 0x5E21747: virDomainDefParseFile (domain_conf.c:20606)
==1589== by 0x112F5F: testCompareXMLToArgv (qemuxml2argvtest.c:493)
==1589== by 0x138780: virTestRun (testutils.c:180)
==1589== by 0x117129: mymain (qemuxml2argvtest.c:937)
==1589== by 0x13A83C: virTestMain (testutils.c:1120)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
In a lot of our mocks (if not all of them) we use our internal
APIs (e.g. VIR_ALLOC). So far, we're relying on test binary that
links with the mock to drag in libvirt.so. Well, this works only
partially. Firstly, whatever binary we execute from tests will
fail (e.g. as Martin reported on the list ./qemucapsprobe fails
to execute qemu). Secondly, if there's a program that tries to
validate linking (like valgrind is doing) it fails because of
unresolved symbols.
Because of that we have to link our mocks with libvirt.so.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1480668
QEMU has this new feature memory-backend-file.discard-data=yes
which is a nifty optimization. Basically, when qemu is quitting
or on memory hotplug it calls munmap() and close() on the file
that is backing the memory. However, this does not mean kernel
won't stop touching that part of memory. It still might. With
this feature enabled we tell kernel: "we don't need this memory
nor data stored in it". This makes kernel drop the memory
immediately without trying to sync memory with the mapped file.
Unfortunately, this cannot be turned on by default because we
can't be sure when users really don't care about what happens to
data after qemu dies. So it has to be opt-in. As usual, there are
three places where one can configure memory attributes. This
patch adds the feature to all of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU has possibility to call madvise(.., MADV_REMOVE) in some
cases. Expose this feature to users by new element/attribute
discard.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At the same time convert the code to use virXMLFormatElement.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks if memory-backend-file has discard-data
attribute or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks if qemu has "qom-list-properties" monitor
command.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we've gotten rid of misleading names we can introduce
qemuMonitorGetObjectProps() function which queries -object
properties. Again, some parts of code can be reused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code that processes list of device properties is going to be
reused. Therefore put it into a separate function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's this macro virBufferSetChildIndent which sets offset of
child buffer from given parent buffer. However, it is calling
virBufferAdjustIndent() which only adds adjustment instead of
calling virBufferSetIndent() which clears out any adjustment
previously set.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If we are the last one to use pr-manager object we need to remove
it and also kill the qemu-pr-helper process.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When attaching a disk that requires pr-manager we might need to
plug the pr-manager object and start the pr-helper process.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Before we exec() qemu we have to spawn pr-helper processes for
all managed reservations (well, technically there can only one).
The only caveat there is that we should place the process into
the same namespace and cgroup as qemu (so that it shares the same
view of the system). But we can do that only after we've forked.
That means calling the setup function between fork() and exec().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Just like we allow users overriding path to bridge-helper
detected at compile time we can allow them to override path to
qemu-pr-helper.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Just like in previous commit, qemu-pr-helper might want to open
/dev/mapper/control under certain circumstances. Therefore we
have to allow it in cgroups.
The change virdevmapper.c might look spurious but it isn't. After
6dd84f6850 any path that we're allowing in deivces CGroup is
subject to virDevMapperGetTargets() inspection. And libdevmapper
returns ENXIO for the path from subject.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If qemu-pr-helper is compiled with multipath support the first
thing it does is open /dev/mapper/control. Since we're going
to be running it inside qemu namespace we need to create it
there. Unfortunately, we don't know if it was compiled with or
without multipath so we have to create it anyway.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
For command line we need two things:
1) -object pr-manager-helper,id=$alias,path=$socketPath
2) -drive file.pr-manager=$alias
In -object pr-manager-helper we tell qemu which socket to connect
to, then in -drive file-pr-manager we just reference the object
the drive in question should use.
For managed PR helper the alias is always "pr-helper0" and socket
path "${vm->priv->libDir}/pr-helper0.sock".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The capability tracks if qemu has pr-manager-helper object. At
this time don't actually detect if qemu has the capability. Not
just yet. Only after the code is written the feature will be
enabled.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Couple of reasons for that:
a) there's no monitor command to change path where the pr-helper
connects to, or
b) there's no monitor command to introduce a new pr-helper for a
disk that already exists.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This is a definition that holds information on SCSI persistent
reservation settings. The XML part looks like this:
<reservations enabled='yes' managed='no'>
<source type='unix' path='/path/to/qemu-pr-helper.sock' mode='client'/>
</reservations>
If @managed is set to 'yes' then the <source/> is not parsed.
This design was agreed on here:
https://www.redhat.com/archives/libvir-list/2017-November/msg01005.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1569678
On some large systems (with ~400GB of RAM) it is possible for
unsigned int to overflow in which case we report invalid number
of 4K pages pool size. Switch to unsigned long long.
We hit overflow in virNumaGetPages when doing:
huge_page_sum += 1024 * page_size * page_avail;
because although 'huge_page_sum' is an unsigned long long, the
page_size and page_avail are both unsigned int, so the promotion
to unsigned long long doesn't happen until the sum has been
calculated, by which time we've already overflowed.
Turning page_avail into a unsigned long long is not strictly
needed until we need ability to represent more than 2^32
4k pages, which equates to 16 TB of RAM. That's not
outside the realm of possibility, so makes sense that we
change it to unsigned long long to avoid future problems.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The code is generic enough to be reused. Move it into a
separate function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far all the properties we are trying to fetch are device
properties, i.e. -device $dev on qemu command line. Change
misleading variable names to express what's queried for better.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allocated in qemuMigrationParamsNew() we need to free
priv->job.migParams when no longer needed.
==8061== 234 (192 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 112 of 123
==8061== at 0x4C2CF26: calloc (vg_replace_malloc.c:711)
==8061== by 0x5325D05: virAlloc (viralloc.c:144)
==8061== by 0x1984F9: qemuMigrationParamsNew (qemu_migration_params.c:218)
==8061== by 0x19A352: qemuMigrationParamsParse (qemu_migration_params.c:1185)
==8061== by 0x1604D8: qemuDomainObjPrivateXMLParseJob (qemu_domain.c:2390)
==8061== by 0x160AE9: qemuDomainObjPrivateXMLParse (qemu_domain.c:2517)
==8061== by 0x5419EAE: virDomainObjParseXML (domain_conf.c:20442)
==8061== by 0x541A25E: virDomainObjParseNode (domain_conf.c:20555)
==8061== by 0x541A2FC: virDomainObjParseFile (domain_conf.c:20574)
==8061== by 0x13607D: testCompareStatusXMLToXMLFiles (qemuxml2xmltest.c:75)
==8061== by 0x14F3E8: virTestRun (testutils.c:180)
==8061== by 0x14DCD0: mymain (qemuxml2xmltest.c:1200)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we have macro that does some checks lets forbid raw
usage of virClassNew() in favor of VIR_CLASS_NEW().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Our virObject code relies heavily on the fact that the first
member of the class struct is type of virObject (or some
derivation of if). Let's check for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
So far we are repeating the following lines over and over:
if (!(virSomeObjectClass = virClassNew(virClassForObject(),
"virSomeObject",
sizeof(virSomeObject),
virSomeObjectDispose)))
return -1;
While this works, it is impossible to do some checking. Firstly,
the class name (the 2nd argument) doesn't match the name in the
code in all cases (the 3rd argument). Secondly, the current style
is needlessly verbose. This commit turns example into following:
if (!(VIR_CLASS_NEW(virSomeObject,
virClassForObject)))
return -1;
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Whenever we declare a new object the first member of the struct
has to be virObject (or any other member of that family). Now, up
until now we did not care about the name of the struct member.
But lets unify it so that we can do some checks at compile time
later.
The unified name is 'parent'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In next patches this name will be needed for a different memeber.
Also, it makes sense to rename the variable because it does not
contain reference to parent device, just its name.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Firstly, this isn't supposed to be in angle brackets because it's
not a system header file (not that gcc distinguishes these two,
it's just guide for us developers).
Secondly, no need to use util/ path prefix because CFLAGS already
contain -I$(srcdir)/util.
The include is needed because virmocklibxl is mocking
virFileMakePath() and even when VIR_MOCK_IMPL_RET_ARGS() does
forward declaration to shut up compiler we need real
virFileMakePath() declaration so that when it changes compiler
catches mismatching declarations.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function is indeed getting -device properties and not
-object properties. The current name is misleading.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Future commits rely on the presence of this callback.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
If a function is disposing virSomething it should be called
virSomethingDispose(). There are two offenders:
virCapabilitiesDispose(virCapsPtr) and
virDomainXMLOptionClassDispose(virDomainXMLOptionPtr).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Introduced in d3db304d2e. Instead of returning immediately we
need to jump onto cleanup label where @paths is freed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In 2ada9ef146 we've tried to turn virDomainChrSourceDef into
virObject. Well, this requires 'virObject' member to be stored on
the first position of the struct. This adjustment is missing in
the original commit leading to all sorts of funny memleaks and
data corruptions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
The array of strings we are building is indeed array of const
strings. We are not STRDUP()-ing them nor FREE()-ing them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1557769
Problem with device mapper targets is that there can be several
other devices 'hidden' behind them. For instance, /dev/dm-1 can
consist of /dev/sda, /dev/sdb and /dev/sdc. Therefore, when
setting up devices CGroup and namespaces we have to take this
into account.
This bug was exposed after Linux kernel was fixed. Initially,
kernel used different functions for getting block device in
open() and ioctl(). While CGroup permissions were checked in the
former case, due to a bug in kernel they were not checked in the
latter case. This changed with the upstream commit of
519049afead4f7c3e6446028c41e99fde958cc04 (v4.16-rc5~11^2~4).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This helper fetches dependencies for given device mapper target.
At the same time, we need to provide a dummy log function because
by default libdevmapper prints out error messages to stderr which
we need to suppress.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1560976
For historical reasons we've used 32 bytes long static buffer for
storing PTY aliases. This breaks users scenario where they try to
start a machine with user alias consisting of "ua-$uuid".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The set of arguments was changed a long time ago (040d996342
which dates back to July 2013) but the corresponding
documentation was not updated.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
The flags passed to virCommandPassFD() are unnamed and
documentation to this function doesn't list them either.
Give them name and mention it in documentation to functions
using them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
https://bugzilla.redhat.com/show_bug.cgi?id=1556828
When defining a domain that has <interface type='hostdev'/> our
parser creates two entries in virDomainDef: one for <interface/>
and one for <hostdev/>. However, some info is shared between the
two which makes user alias validation fail because alias belongs
to the set of shared info.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
==16451== 32,768 bytes in 2 blocks are definitely lost in loss record 1,007 of 1,013
==16451== at 0x4C2AF0F: malloc (vg_replace_malloc.c:299)
==16451== by 0x7CADB40: nl_recv (in /usr/lib64/libnl-3.so.200.23.0)
==16451== by 0x532DFAC: virNetlinkDumpCommand (virnetlink.c:363)
==16451== by 0x53236AE: virNetDevIPCheckIPv6Forwarding (virnetdevip.c:641)
==16451== by 0xE3E4A1A: networkStartNetworkVirtual (bridge_driver.c:2490)
==16451== by 0xE3E55F5: networkStartNetwork (bridge_driver.c:2832)
==16451== by 0xE3DFFE5: networkAutostartConfig (bridge_driver.c:531)
==16451== by 0x53F47E0: virNetworkObjListForEachHelper (virnetworkobj.c:1412)
==16451== by 0x52FE69F: virHashForEach (virhash.c:606)
==16451== by 0x53F4857: virNetworkObjListForEach (virnetworkobj.c:1439)
==16451== by 0xE3E0BF4: networkStateAutoStart (bridge_driver.c:808)
==16451== by 0x55689CE: virStateInitialize (libvirt.c:758)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1552127
When building command line for USB controllers we have to do more
than just put controller's alias onto the command line. QEMU has
concept of these joined USB controllers. For instance ehci and
uhci controllers need to create the same USB bus. To achieve that
the slave controller needs to refer the master controller. This
worked until we've introduced user aliases because both master
and slave had the same alias. With user aliases slave can have
different alias than master. Therefore, when generating command
line for slave we need to look up the master's alias.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We have to use VIR_WARNINGS_NO_CAST_ALIGN to avoid clang warning
about increased required alignment caused by some netlink macros.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The setuid-rpc-client.la is intended to be small and contain only
bare minimum of source files. virarptable.c is not one of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Chen Hanxiao<chenhanxiao@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The daemonStreamHandleWriteData() function is called whenever
server side of stream is able to receive some data. Nevertheless,
it calls virStreamSend() (to pass data down to virFDStream) and
depending on its return value it may abort the stream. However,
the functions it called when doing so are public APIs and as such
reset any error set previously. Therefore, if there was any error
in writing data to stream (i.e. repored in virStreamSend) it is
reset before virNetServerProgramSendReplyError() can get to it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Some fields reported by dmidecode have plenty of useless spaces
(in fact some have nothing but spaces). To deal with this we have
introduced virSkipSpacesBackwards() and use it in
virSysinfoParseX86Processor() and virSysinfoParseX86Memory().
However, other functions (e.g. virSysinfoParseX86Chassis()) don't
use it at all and thus we are reporting nonsense:
<sysinfo type='smbios'>
<chassis>
<entry name='manufacturer'>FUJITSU</entry>
<entry name='version'> </entry>
<entry name='serial'> </entry>
<entry name='asset'> </entry>
<entry name='sku'>Default string</entry>
</chassis>
</sysinfo>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We're freeing individual items in it but not the array itself.
==19200== 40 bytes in 1 blocks are definitely lost in loss record 847 of 1,059
==19200== at 0x4C2D12F: realloc (vg_replace_malloc.c:785)
==19200== by 0x52C5532: virReallocN (viralloc.c:245)
==19200== by 0x52C5628: virExpandN (viralloc.c:294)
==19200== by 0x52C58FC: virInsertElementsN (viralloc.c:436)
==19200== by 0x542856B: virSecurityDACChownListAppend (security_dac.c:115)
==19200== by 0x54286B4: virSecurityDACTransactionAppend (security_dac.c:167)
==19200== by 0x542902F: virSecurityDACSetOwnershipInternal (security_dac.c:560)
==19200== by 0x54295D6: virSecurityDACSetOwnership (security_dac.c:650)
==19200== by 0x542AEE0: virSecurityDACSetInputLabel (security_dac.c:1472)
==19200== by 0x542B61D: virSecurityDACSetAllLabel (security_dac.c:1693)
==19200== by 0x542DD67: virSecurityManagerSetAllLabel (security_manager.c:869)
==19200== by 0x54279C2: virSecurityStackSetAllLabel (security_stack.c:361)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Probably due to copy-paste error we're storing asset tag into
def->sku which we even use in the next step to store SKU number
and thus the asset tag leaks.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1553162
When validating a device XML config we check if user provided
alias is unique. We do this by maintaining a hash table of device
aliases as we iterated over all devices defined for the domain.
However, it may happen that what appears as two devices in domain
XML is in fact just one interface in hypervisor. We can assume
libvirt generated aliases to be unique and thus really check user
provided ones only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1553075
For some weird reason this function is getting live and
persistent def for domain but then accesses vm->def and
vm->newDef directly. This is rather unsafe as we can be
accessing NULL pointer.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When trying to destroy a domain (e.g. because we've seen EOF on
the monitor) we try to acquire QEMU_JOB_DESTROY. However, if
max_queued is set in qemu.conf this may fail and since our code
doesn't count on that we will still report domain as active even
though the qemu process is long gone. More specifically, if we've
seen EOF on the monitor, qemuProcessHandleMonitorEOF() is called
which sends MONITOR_EOF job to the event worker pool and
unregisters monitor from the event loop. The worker pool calls
processMonitorEOFEvent() which tries to set job which may fail
due to the limit as described above.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Currently if cmd->skipChecks is set (done only from completers)
some basic checks are skipped because we're working over
partially parsed command. See a26ff63ae4 for more detailed
explanation. Anyway, the referenced commit was too aggressive in
disabling checks and effectively returned success even in clear
case of failure. For instance:
# domif-getlink --interface <TAB><TAB>
causes virshDomainInterfaceCompleter() to be called, which calls
virshDomainGetXML() which eventually calls
vshCommandOptStringReq(.., name = "domain"); The --domain
argument is required for the command and if not present -1 should
be returned to tell the caller the argument was not found. Well,
zero is returned meaning the argument was not found but it's not
required either.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This partially reverts 82592551cb.
When migrating a domain, qemuMigrationDstPrepareAny() is called
which eventually calls qemuProcessLaunch(conn = NULL, flags =
VIR_QEMU_PROCESS_START_AUTODESTROY); But the very first thing
that qemuProcessLaunch does is check if AUTODESTROY flag is set
and @conn is not NULL. Well, it is.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik