The generated output is dependent on perl hashtable ordering, which
gives different results for i686 and x86_64. Fix this by sorting
the hash keys before iterating over them
https://bugzilla.redhat.com/show_bug.cgi?id=1173641
Even though the Makefile has WITH_WIRESHARK guards, the _SOURCES
variables are still processed when adding bits to the dist archive.
plugin.c is a generated file that is only built when wireshark is
enabled and it shouldn't be distributed, so use 'nodist'
On every socket connect(2) attempt we were re-launching session
libvirtd, up to 100 times in 5 seconds.
This understandably caused some weird load races and intermittent
qemu:///session startup failures
https://bugzilla.redhat.com/show_bug.cgi?id=1271183
When we autolaunch libvirtd for session URIs, we spin in a retry
loop waiting for the daemon to start and the connect(2) to succeed.
However if we exceed the retry count, we don't explicitly raise an
error, which can yield a slew of different error messages elsewhere
in the code.
Explicitly raise the last connect(2) failure if we run out of retries.
- Add some debugging
- Make the loop dependent only on retries
- Make it explicit that connect(2) success exits the loop
- Invert the error checking logic
If the q35 specific disable s3/s4 setting isn't supported, fallback to
specifying the PIIX setting, which is the previous behavior. It doesn't
have any effect, but qemu will just warn about it rather than error:
qemu-system-x86_64: Warning: global PIIX4_PM.disable_s3=1 not used
qemu-system-x86_64: Warning: global PIIX4_PM.disable_s4=1 not used
Since it doesn't error, I don't think we should either, since there
may be configs in the wild that already have q35 + disable_s3/4 (via
virt-manager)
Using one Makefile per example subdirectory essentially serializes 'make'
calls. Convert to one example/Makefile that builds and distributes
all the subdir files. This reduces example/ rebuild time from about 5.8
seconds to 1.5 seconds on my machine.
One slight difference is that we no longer ship Makefile.am with the
examples in the rpm. This was virtually useless anyways since the Makefile
was very specific to libvirt infrastructure, so wasn't generically
reusable anyways.
Tested with 'make distcheck' and 'make rpm'
Future changes will make some of these tests dependent on specific
QEMUCaps flags, so wire up the basic handling. Flags will be added
in future patches.
For the standard active/inactive XML testing, if we leave the file loading
up to the generic XML2XML infrastructure, we get the benefit of
VIR_TEST_REGENERATE_OUTPUT, at the price of a few more disk reads. Seems
worth it.
Since test files are formatted predictably nowadays, we can make
VIR_TEST_REGENERATE_OUTPUT handle most cases for us with a simple
replacement. test-wrap-argv.pl is still canon, but this bit makes
it easier to confirm test output changes during active development.
I'm hitting this little annoyance in fedora's package repo:
$ fedpkg prep
Downloading libvirt-1.2.20.tar.gz
...
+ /usr/bin/gzip -dc /home/crobinso/src/fedora/libvirt/libvirt-1.2.20.tar.gz
$ git clean -xdf
Removing libvirt-1.2.20.tar.gz
Skipping repository libvirt-1.2.20/
We git-ify the libvirt directory as part of applying patches in the spec
file, but 'git clean' will ignore subfolders that appear to be standalone
git repos.
Let's just delete the .git directory after we're done with it.
- qemuxml2argv-aarch64-mmio-default-pci: Verify that we still default
to virtio-mmio even if qemu is new enough to support PCI
- qemuxml2argv-aarch64-virtio-pci: Check generated arm virtio PCI args
The example pvspinlock XML is:
<pvspinlock/>
While this is accepted by libvirt and works correctly, it's currently
always output as a tristate like
<pvspinlock state='on'/>
So document that format instead
virtTestResult is suboptimal for a few reasons:
- It poorly duplicates virtTestRun pass/fail reporting logic
- It doesn't have virtTestRun's alloc testing support
- It only reports the test name _after_ the test has run.
- It doesn't follow the standard virtTestRun pattern that most other
tests use.
There's no users left, so drop it. If any other async tests like eventtest
spring up that don't cleanly fit the virtTestRun pattern, I suggest they
just open code the support for it around virtTestRun
These event tests aren't run synchronously, so there isn't an obvious
function to pass to virtTestRun. Instead, open code roughly what
virtTestResult did before: printing an error message if a test failed.
Commit 307fb904 (Sep 10) added a 'privileged' variable when creating
the DAC driver:
@@ -153,6 +157,7 @@ virSecurityManagerNewDAC(const char *virtDriver,
bool defaultConfined,
bool requireConfined,
bool dynamicOwnership,
+ bool privileged,
virSecurityManagerDACChownCallback chownCallback)
But argument order is mixed up at the caller, swapping dynamicOwnership
and privileged values. This corrects the argument order
https://bugzilla.redhat.com/show_bug.cgi?id=1266628
$ rpmbuild -ba libvirt.spec
warning: Macro expanded in comment on line 5: # If neither fedora nor rhel was defined, try to guess them from %{dist}
warning: Macro %enable_autotools defined but not used within scope
warning: Macro %client_only defined but not used within scope
...
There's a couple reports of things failing in this area (bug 1259070),
but it's tough to tell what's going wrong without stderr from
qemu-bridge-helper. So let's report stderr in the error message
Couple new examples:
virbr0 is inactive:
internal error: /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=21: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=failed to get mtu of bridge `virbr0': No such device
bridge isn't on the ACL:
internal error: /usr/libexec/qemu-bridge-helper --use-vnet --br=br0 --fd=21: failed to communicate with bridge helper: Transport endpoint is not connected
stderr=access denied by acl file
If you pass <disk><serial> XML to UpdateDevice, and the original device
didn't have a <serial> block, libvirtd crashes trying to read the original
NULL serial string.
Use _NULLABLE string comparisons to avoid the crash. A couple other
properties needed the change too.
As of fedora polkit-0.113-2, polkit-devel only pulls in polkit-libs, not
full polkit, but we need the latter for pkcheck otherwise our configure
test fails.
qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using
qemu-system-aarch64 KVM to run armv7l VMs.
Add a capabilities check for it, wire it up in qemu_command, and test
the command line generation.
Only set directory permissions at pool build time, if:
- User explicitly requested a mode via the XML
- The directory needs to be created
- We need to do the crazy NFS root-squash workaround
This allows qemu:///session to call build on an existing directory
like /tmp.
The XML parser sets a default <mode> if none is explicitly passed in.
This is then used at pool/vol creation time, and unconditionally reported
in the XML.
The problem with this approach is that it's impossible for other code
to determine if the user explicitly requested a storage mode. There
are some cases where we want to make this distinction, but we currently
can't.
Handle <mode> parsing like we handle <owner>/<group>: if no value is
passed in, set it to -1, and adjust the internal consumers to handle
it.
- Don't redocument the permissions fields for backingstore, just point to
the volume docs.
- Clarify that owner/group are inherited from the parent directory at
volume create/pool build time.
- Clarify that <permissions> fields report runtime values too
My commit 747761a79 (v1.2.15 only) dropped this bit of logic when filling
in a default arch in the XML:
- /* First try to find one matching host arch */
- for (i = 0; i < caps->nguests; i++) {
- if (caps->guests[i]->ostype == ostype) {
- for (j = 0; j < caps->guests[i]->arch.ndomains; j++) {
- if (caps->guests[i]->arch.domains[j]->type == domain &&
- caps->guests[i]->arch.id == caps->host.arch)
- return caps->guests[i]->arch.id;
- }
- }
- }
That attempt to match host.arch is important, otherwise we end up
defaulting to i686 on x86_64 host for KVM, which is not intended.
Duplicate it in the centralized CapsLookup function.
Additionally add some testcases that would have caught this.
https://bugzilla.redhat.com/show_bug.cgi?id=1219191
My commit 7b9de914 added some aarch64 CPU test cases. I wanted to test
two different code paths but inadvertently added two of the same test
cases.
The second code path (using <cpu><model>host</model</cpu>) isn't easily
exercised via the qemu tests anyways, I'll need to look elsewhere.
Regardless, remove the redundant tests for now
Many users, who admin their own machines, want to be able to access
system libvirtd via tools like virt-manager without having to enter
a root password. Just google 'virt-manager without password' and
you'll find many hits. I've read at least 5 blog posts over the years
describing slightly different ways of achieving this goal.
Let's finally add official support for this.
Install a polkit-1 rules file granting password-less auth for any user
in the new 'libvirt' group. Create the group on RPM install
https://bugzilla.redhat.com/show_bug.cgi?id=957300
Currently we try to chown any directory passed to virDirCreate,
even if the user didn't request any explicit owner/group via the
pool/vol XML.
This causes issues with qemu:///session: try to build a pool of
a root owned directory like /tmp, and it fails trying to chown the
directory to the session user. Instead it should just leave things
as they are, unless the user requests changing permissions via
the pool XML.
Similarly this is annoying if creating a storage pool via system
libvirtd of an existing directory in user $HOME, it's now owned
by root.
The virDirCreate function is pretty convoluted, since it needs to
fork off in certain specific cases. Try to document that, to make
it clear where exactly we are changing behavior.
The current code attempts to handle this, but it only catches mkdir
failing with EEXIST. However if say trying to build /tmp for an
unprivileged qemu:///session, mkdir will fail with EPERM.
Rather than catch any errors, just don't attempt mkdir if the directory
already exists.
The phyp driver stuffed it into a DomainDefPtr during its attachdevice
routine, but the value is never advertised via capabilities so it should
be safe to drop.
Have the phyp driver use OSTYPE_LINUX, which is what it advertises via
capabilities.
Trying to use qemu:///session to create a storage pool pointing at
/tmp will usually fail with something like:
$ virsh pool-start tmp
error: Failed to start pool tmp
error: cannot open volume '/tmp/systemd-private-c38cf0418d7a4734a66a8175996c384f-colord.service-kEyiTA': Permission denied
If any volume in an FS pool can't be opened by the daemon, the refresh
fails, and the pool can't be used.
This causes pain for virt-install/virt-manager though. Imaging a user
downloads a disk image to /tmp. virt-manager wants to import /tmp as
a storage pool, so we can detect what disk format it is, and set the
XML correctly. However this case will likely fail as explained above.
Change the logic here to skip volumes that fail to open. This could
conceivably cause user complaints along the lines of 'why doesn't
libvirt show $ROOT-OWNED-VOLUME-FOO', but figuring that currently
the pool won't even startup, I don't think there are any current
users that care about that case.
https://bugzilla.redhat.com/show_bug.cgi?id=1103308
If you end up with a state file for a pool that no longer starts up
or refreshes correctly, the state file is never removed and adds
noise to the logs everytime libvirtd is started.
If the initial state syncing fails, delete the statefile.
After pool startup we call refreshPool(). If that fails, we leave
a stale pool state file hanging around.
Hit this trying to create a pool with qemu:///session containing
root owned files.
- Make sure aarch64 host-passthrough works correctly
- Make sure libvirt doesn't choke on cpu model=host, which is what
virt-install/virt-manager were incorrectly specifying up until recently.
If this enviroment variable is set, the virTestCompareToFile helper
will overwrite the file content we are comparing against, if the
file doesn't exist or it doesn't match the expected input.
This is useful when adding new test cases, or making changes that
generate a lot of output churn.
Fedora doesn't ship OVMF/AAVMF builds in its repos due to licensing
issues, so the recommended way to consume these bits is via Gerd's
nightly repo: https://www.kraxel.org/repos
Let's teach fedora builds about the loader/nvram pairs these packages
installed, so users don't need to edit qemu.conf to get virt-manager
UEFI support.
- Remove all qemu emulators
- Restart libvirtd
- Install qemu emulators
- Call 'virsh version' -> errors
The only thing that will force the qemu driver to refresh it's cached
capablities info is an explict API call to GetCapabilities.
However in the case when the initial caps lookup at driver connect didn't
find a single qemu emulator to poll, the driver is effectively useless
and really can't do anything until it's populated some qemu capabilities
info.
With the above steps, the user would have to either know about the
magic refresh capabilities call, or restart libvirtd to pick up the
changes.
Instead, this patch changes things so that every time a part of th
driver requests access to capabilities info, check to see if
we've previously seen any emulators. If not, force a refresh.
In the case of 'still no emulators found', this is still very quick, so
I can't think of a downside.
https://bugzilla.redhat.com/show_bug.cgi?id=1000116
This needs to specified in way too many places for a simple validation
check. The ostype/arch/virttype validation checks later in
DomainDefParseXML should catch most of the cases that this was covering.
This revealed that GuestDefaultEmulator was a bit buggy, capable
of returning an emulator that didn't match the passed domain type. Fix
up the test suite input to continue to pass.
This is a helper function to look up all capabilities data for all
the OS bits that are relevant to <domain>. This is
- os type
- arch
- domain type
- emulator
- machine type
This will be used to replace several functions in later commits.
But the internal API stays the same, and we just convert the value as
needed. Not useful yet, but this is the beginning step of using an enum
for ostype throughout the code.
When parsing XML, we validate the passed ostype + arch combo against
the detected hypervisor capabilities. This has led to the following
problem:
- Define x86 qemu guest
- qemu is inadvertently removed from the host
- libvirtd is restarted. fails to parse VM config since arch is removed
- 'virsh list --all' is now empty, user is wondering where their VMs went
Add a new internal flag VIR_DOMAIN_DEF_PARSE_SKIP_OSTYPE_CHECKS. Use
it when loading VM and snapshot configs from disk.
https://bugzilla.redhat.com/show_bug.cgi?id=1043572
If no <os><type> was specified:
before: unknown OS type no OS type
after : xml error: an os <type> must be specified
If an <os><type> is specified that's not in our capabiliities data:
before: unknown OS type: $type
after : unsupported configuration: no support found for os <type> '$type'
VIR_ERR_OS_TYPE is now unused (as it should be frankly) so drop its strings
as well to save our translators some effort.
$ sudo virsh change-media f19 hdc /mnt/data/devel/media/Fedora-16-x86_64-Live-KDE.iso
succeeded to complete action update on media
Change the message to:
Successfully {inserted,ejected,changed} media.
https://bugzilla.redhat.com/show_bug.cgi?id=967946
Right now when building the qemu command line, we try to do various
unconditional validations of the guest CPU against the host CPU. However
this checks are overly applied. The only time we should use the checks
are:
- The user requests host-model/host-passthrough, or
- When KVM is requsted. CPU features requested in TCG mode are always
emulated by qemu and are independent of the host CPU, so no host CPU
checks should be performed.
Right now if trying to specify a CPU for arm on an x86 host, it attempts
to do non-sensical validation and falls over.
Switch all the test cases that were intending to test CPU validation to
use KVM, so they continue to test the intended code.
Amend some aarch64 XML tests with a CPU model, to ensure things work
correctly.
The check for ISCSI devices was missing a check of subsys type, which
meant we could skip labelling of other host devices as well. This fixes
USB hotplug on F21
https://bugzilla.redhat.com/show_bug.cgi?id=1145968
Cole Robinson