Jiri Denemark [Thu, 4 Aug 2016 11:16:55 +0000 (13:16 +0200)]
testutilsqemu: Helpers for changing host CPU and arch
Changing a host architecture or a CPU is not as easy as assigning a new
value to the appropriate element in virCaps since there is a relation
between the CPU and host architecture (we don't really want to test
anything on an AArch64 host with core2duo CPU). This patch introduces
qemuTestSetHostArch and qemuTestSetHostCPU helpers which will make sure
the host architecture matches the host CPU.
Jiri Denemark [Wed, 3 Aug 2016 10:21:19 +0000 (12:21 +0200)]
qemuxml2argvtest: Update qemuCaps after parsing domain XML
Some parts of qemuCaps depend on guest architecture, machine type, and
possibly other things that we know only once the domain XML has been
parsed. Let's move all these updates into a dedicated function.
qemu: Use virDomainCapsCPUModels for cpuDefinitions
The list of supported CPU models in domain capabilities is stored in
virDomainCapsCPUModels. Let's use the same object for storing CPU models
in QEMU capabilities.
Applications can use it to inspect what CPU configuration modes are
supported for a specific combination of domain type, emulator binary,
guest architecture and machine type.
Jim Fehlig [Mon, 19 Sep 2016 17:34:34 +0000 (11:34 -0600)]
libxl: support VIR_MIGRATE_PERSIST_DEST migration flag
By default, virt-manager (and likely other libvirt-based apps) sets
the VIR_MIGRATE_PERSIST_DEST flag when invoking the migrate API, which
fails in a Xen setup since the libxl driver does not support the flag.
Persisting a domain is a trivial task in the grand scheme of migration,
so be nice to libvirt apps and add support for VIR_MIGRATE_PERSIST_DEST
in the libxl driver.
qemu_process: show shutoff reasons when debug log disabled
We have a few of senarios that libvirtd would invoke qemuProcessStop
and leave a "shutting down" in /var/log/libvirt/qemu/$DOMAIN.log.
The shutoff reason showing in debug log is also very important
for us to know why VM shutting down in domain log,
as we seldom enable debug log of libvirtd.
During offline migration, no storage is copied. Nor disks, nor
NVRAM file, nor anything. We use qemu for that and because domain
is not running there's nobody to copy that for us.
We should document this to avoid confusing users.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 14 Sep 2016 05:37:16 +0000 (07:37 +0200)]
qemu: driver: Don't return automatic NUMA emulator pinning data for persistentDef
Calling virDomainGetEmulatorPinInfo on a live VM with automatic NUMA
pinning and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning
data in some cases which is bogus. Use the autoCpuset property only when
called on a live definition.
Peter Krempa [Wed, 14 Sep 2016 05:37:16 +0000 (07:37 +0200)]
qemu: driver: Don't return automatic NUMA vCPU pinning data for persistentDef
Calling virDomainGetVcpuPinInfo on a live VM with automatic NUMA pinning
and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning data
in some cases which is bogus. Use the autoCpuset property only when
called on a live definition.
Peter Krempa [Wed, 14 Sep 2016 05:28:18 +0000 (07:28 +0200)]
qemu: domain: Add macro to simplify access to vm private data
Sometimes adding a separate variable to access vm->privateData is not
necessary. Add a macro that will do the typecasting rather than having
to add a temp variable to force the compiler to typecast it.
In this mode, QEMU doesn't listen for SPICE connection anywhere and
clients have to use virDomainOpenGraphics* APIs to attach to the domain.
That is, the client has to run on the same host where the domains runs
and it's impossible to tell the client to reconnect to the destination
QEMU during migration (unless there is some kind of proxy on the host).
While current libvirt correctly ignores such graphics devices when
creating graphics migration cookie, old libvirt just sends
in the cookie. After seeing this cookie, we happily would call
client_migrate_info QMP command and wait for SPICE_MIGRATE_COMPLETED
event, which is quite pointless since the doesn't know where to connecti
anyway. We should just ignore such cookies.
qemu: agent: give better error messages whe agent monitor is down
We can receive NULL as sync reply in two situations. First
is garbage sync reply and this situation is handled by
resending sync message. Second is different cases
of rebooting guest, destroing domain etc and we can
give more meaningful error message. Actually we have
this error message in qemuAgentCommand already which checks
for the same sitatuion. AFAIK case with mon->running
is just to be safe on adding some future(?) cases of
returning NULL reply.
We can easily handle receiving garbage on sync. We don't
have to make client deal with this situation. We just
need to resend sync command but this time garbage is
not be possible.
When we wait for sync reply we can receive delayed
reply to syncs or commands that were sent erlier. We can
safely skip them until we receive sync reply with correct id.
There is no much sense report this situation to client.
Actually with a bit of "luck" if we involve client into
this the play can go on forever: send sync 0, receive
sync reply -1, send sync 1, receive reply 0 ...
qemu: agent: ignore garbage while waiting for sync reply
After sync is sent we can receive garbare and this is not error.
Consider next regular case:
1. libvirtd sends sync
2. qga sends partial sync reply and die
3. libvirtd sends sync
4. qga sends sync reply
5. libvirtd receives garbage
(half of first reply and second reply together)
We should handle this situation as it is recoverable.
Next sync can succeed. Let's report reply is NULL,
it will be converted to the VIR_ERR_AGENT_UNSYNCED
which signals client to retry.
Errors in qemuAgentIOProcessLine stop agent IO processing just
like any regular IO error, however some of current errors
that this functions spawns are false positives. Consider
next case for example:
Last IO triggers error because current code ignores
only delayed syncs when unsynced
We should not treat any delayed reply as error in unsynced
state. Until client and qga are not in sync delayed reply to any
command is possible. msg == NULL is the exact criterion
that we are not in sync.
Andrea Bolognani [Tue, 20 Sep 2016 13:22:04 +0000 (15:22 +0200)]
virtlogd: Don't stop or restart along with libvirtd
Commit 839a060 tied the lifecycle of virtlogd more
closely to that of libvirtd. Unfortunately, while starting
virtlogd when libvirtd is started is definitely a good idea,
restarting virtlogd or shutting it down at any time outside
of system poweroff is not.
Revert part of that commit by removing the PartOf= lines,
meaning that only startup requests will be propagated from
libvirtd to virtlogd.
Erik Skultety [Wed, 7 Sep 2016 15:30:48 +0000 (17:30 +0200)]
virt-admin: Tweak command parsing logic so that aliases point to new commands
Change the logic in a way, so that VSH_CMD_FLAG_ALIAS behaves similarly to
how VSH_OT_ALIAS for command options, i.e. there is no need for code duplication
for the alias and the aliased command structures. Along with that change,
switch any existing VSH_CMD_FLAG_ALIAS occurrences to this new format. Also,
since this patch introduces a new command structure element, adjust the
virsh-self-test test to make sure we won't ever miss to specify the '.alias'
member for an aliased command because doing that would lead to an internal
error.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Fri, 16 Sep 2016 14:06:47 +0000 (16:06 +0200)]
virsh: man: Do not document our old deprecated nodedev-dettach command
The command is deprecated due to being grammatically incorrect, but for
backwards compatibility reasons cannot be removed. However, we should not
document such commands.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Fri, 16 Sep 2016 08:17:46 +0000 (10:17 +0200)]
vsh: discard vshCmddefOptFill and move its body to vshCmddefOptParse
Recent changes extracted the command internals validation routine from
vshCmddefOptParse method which now just calls vshCmddefOptFill. Therefore, make
vshCmddefOptFill the new vshCmddefOptParse and drop the unnecessary name.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Fri, 16 Sep 2016 07:58:24 +0000 (09:58 +0200)]
vsh: Extract vshCmddefCheckInternals from vshCmddefOptParse
Originally introduced by commit 2432521e which correctly split
vshCmddefOptParse into command's options validation and options parsing.
However, command's 'internals' are not tied solely to .options, rather it
should be about the overall structure, therefore the validation should be
extracted from vshCmddefOptParse and performed only within our test suite, i.e.
in vshSelfTest.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Thu, 15 Sep 2016 15:52:11 +0000 (17:52 +0200)]
vsh: vshCmddefHelp: Drop the unnecessary 'else' branch
If the initial check is true the function immediately returns so there's no
need to enclose the code following the check within an 'else' block.
Also, by removing the 'else' block, the declarations need to be moved to
beginning of the function block to conform with our guidelines.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Erik Skultety [Mon, 19 Sep 2016 11:10:38 +0000 (13:10 +0200)]
vsh: Enforce checking for missing help string
The intention is to move vshCmddefCheckInternals out of vshCmddefOptParse to
our test suite. First step to do that is to enforce checking for an existing
help string (that also means it's non-empty) in a command because a command
without a help is not much of a use.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This caused libvirt Mingw build to break with the compiler
reporting 100's of definitions of virConnectAuthPtrDefault
./.libs/libvirt_util.a(libvirt_util_la-virarch.o):virarch.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):viralloc.c:(.bss+0x0): first defined here
./.libs/libvirt_util.a(libvirt_util_la-viratomic.o):viratomic.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87: first defined here
./.libs/libvirt_util.a(libvirt_util_la-viraudit.o):viraudit.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87: first defined here
./.libs/libvirt_util.a(libvirt_util_la-virauth.o):virauth.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87: first defined here
./.libs/libvirt_util.a(libvirt_util_la-virauthconfig.o):virauthconfig.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
...snip...
The cause is our VIR_EXPORT_VAR macro which has some
magic on win to add dllexport/dllimport to the variable
declaration. Unfortunately the dllexport branch missed
off the 'extern' keyword, so the header file was in
fact declaring an instance of the variable in every
source file.
Previously the linker would merge all these definitions
into one, but that no longer happens due to -fno-common
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Laine Stump [Mon, 19 Sep 2016 17:44:21 +0000 (13:44 -0400)]
tests: fix use of fixedcontent variable
Commit 8563560026d192c2cf047b550ffd468692245ed6 switched from
hardcoded use of strcontent to hardcoded use of fixedcontent
(fixedcontent is *sometimes* a copy of strcontent with a \n
appended). This was a problem because sometimes fixedcontent is *not*
a copy of strcontent, but is instead NULL, leading to the regenerated
test case output being a 0 length file.
This patch creates a new const char *cmpcontent initialized to
strcontent, but changed to fixedcontent if/when fixedcontent is
created, then always uses cmpcontent instead of (str|fixed)content.
come with a linear framebuffer (sometimes called "VGA compatibility
framebuffer"). This linear framebuffer lives in one of the PCI device's
MMIO BARs, and allows guest code (primarily: firmware drivers, and
non-accelerated OS drivers) to display graphics with direct memory access.
Due to architectural reasons on aarch64/KVM hosts, this kind of
framebuffer doesn't / can't work in
qemu-system-(arm|aarch64) -M virt
machines. Cache coherency issues guarantee a corrupted / unusable display.
The problem has been researched by several people, including kvm-arm
maintainers, and it's been decided that the best way (practically the only
way) to have boot time graphics for such guests is to consolidate on
QEMU's "virtio-gpu-pci" device.
but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga"
device model. (See the qemuBuildDeviceVideoStr() function and the
"qemuDeviceVideo" enum impl.)
According to the above, this is not right for the "virt" machine type; the
qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga"
device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure
virtio device without a compatibility framebuffer, is available, and works
fine.
(The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware
for "virt" -- supports "virtio-gpu-pci", as of upstream commit 3ef3209d3028. See
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.)
Override the default mapping of "virtio", from "virtio-vga" to
"virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true.
Cc: Andrea Bolognani <abologna@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
There is nothing Linux-specific in that function. Also since commit 8c3b5bf48123783b812b97360db7ac51f1889e17 mingw build is broken due to
the fact that this function is not compiled in the library.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Tomáš Ryšavý [Thu, 15 Sep 2016 08:27:03 +0000 (10:27 +0200)]
test_driver: Replace magic constant
In testOpenDefault we create a virtual computer that is later
presented to user. We also pretend to have NUMA cells and
initialize them somehow. But whilst doing so a magical constant
is used. Drop it.
Signed-off-by: Tomáš Ryšavý <tom.rysavy.0@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
virsh: use virConnectGetDomainCapabilities with maxvcpus
virsh maxvcpus --type kvm output is useless on PPC. Also, in
commit e6806d79 we documented not rely on virConnectGetMaxVcpus
output. Fix the maxvcpus to use virConnectGetDomainCapabilities
now to make it useful. The call is made to use the default emulator
binary and to check for the host machine and arch which is what the
command intends to show anyway.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Commit ca32929908bbc94116493ad8915e7cd7ae0f57d5 added function
virTestCompareToFile(), but forgot to use a fixedcontent value for the
actual comparison. That lead to VIR_TEST_DEBUG=1 showing (for some
tests) all the actual output from the first error to the end of the
string due to the difference being an endline in the end.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Peter Krempa [Tue, 13 Sep 2016 15:56:08 +0000 (17:56 +0200)]
qemu: domain: Don't infer vcpu state
Use the state information (online, hotpluggable) provided by the monitor
code rather than trying to infer it. This fixes an issue where on
architectures that require hotplug of multiple threads at once the
sub-cores would get updated as offline on daemon restart thus creating
an invalid configuration.
Peter Krempa [Tue, 13 Sep 2016 15:28:02 +0000 (17:28 +0200)]
qemu: monitor: Use a more obvious iterator name
The algorithm that matches data from query-cpus and
query-hotpluggable-cpus is quite complex. Start using descriptive
iterator names to avoid confusion.
Apparently, some management applications use the following code
pattern when waiting for a block job to finish:
while (1) {
virDomainGetBlockJobInfo(dom, disk, info, flags);
if (info.cur == info.end)
break;
sleep(1);
}
Problem with this approach is in its corner cases. In case of
QEMU, libvirt merely pass what has been reported on the monitor.
However, if the block job hasn't started yet, qemu reports cur ==
end == 0 which tricks mgmt apps into thinking job is complete.
The solution is to mangle cur/end values as described here [1].
qemuDomainGetBlockJobInfo: Move info translation into separate func
Even though we merely just pass to users whatever qemu provided
on the monitor, we still do some translation. For instance we
turn bytes into mebibytes, or fix job type if needed. However, in
the future there is more fixing to be done so this code deserves
its own function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The test qemuxml2argv-serial-tcp-tlsx509-chardev.args
will fail if libvirt is built with a --sysconfdir
arg that is not /etc. Fix this by setting a hardcoded
path in the test code.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Peter Krempa [Tue, 13 Sep 2016 13:55:06 +0000 (15:55 +0200)]
numa: Rename virNumaGetHostNodeset and make it return only nodes with memory
Name it virNumaGetHostMemoryNodeset and return only NUMA nodes which
have memory installed. This is necessary as the kernel is not very happy
to set the memory cgroup setting for nodes which do not have any memory.
This would break vcpu hotplug with following message on such
configruation:
Invalid value '0,8' for 'cpuset.mems': Invalid argument
Michal Privoznik [Tue, 13 Sep 2016 14:23:05 +0000 (16:23 +0200)]
configure: Check for major() more strictly
Thing is, in f3f15cc24 I'm trying to adapt libvirt to the newest
glibc where major()/minor()/makedev() are moved from sys/types.h
to sys/sysmacros.h. However, my commit back then expect autoconf
to be fixed too as we already use AC_HEADER_MAJOR to determine
which header file the functions are in, but because the header
files just trigger a warning and not a compile error, the
autoconf macro detects the bad header file.
This is just a workaround until autoconf macro is fixed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Erik Skultety [Thu, 8 Sep 2016 13:28:07 +0000 (15:28 +0200)]
tests: fix incorrect status handling by virsh-self-test
The virsh-self-test script compared the test's return code with 1 and only if
the return code matched this value then the test was marked as failed. Problem
is that SIGSEGV returns 139 (or 11 to be precise, since shell reserves the MSB
for abnormal exit signaling) which passes the check just fine and test then
appears as successful which it most certainly wasn't.
Therefore, flip the logic to compare against 0 instead and every other result
will be treated as a failed test case.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
In a full domain config, libvirt allows overriding the normal PCI
vs. PCI Express rules when a device address is explicitly provided
(so, e.g., you can force a legacy PCI device to plug into a PCIe port,
although libvirt would never do that on its own). However, due to a
bug libvirt doesn't give this same leeway when hotplugging devices. On
top of that, current libvirt assumes that *all* devices are legacy
PCI. The result of all this is that it's impossible to hotplug a
device into a PCIe port, even if you manually add the PCI address.
This can all be traced to the function
virDomainPCIAddressEnsureAddr(), and the fact that it calls
virDomainPCIaddressReserveSlot() for manually set addresses, and that
function hardcodes the argument "fromConfig" to false (meaning "this
address was auto-assigned, so it should be subject to stricter
validation").
Since virDomainPCIAddressReserveSlot() is just a one line simple
wrapper around virDomainPCIAddressReserveAddr() (adding in a hardcoded
reserveEntireSlot = true and fromConfig = false), all that's needed to
solve the problem with no unwanted side effects is to replace that
call for virDomainPCIAddressReserveSlot() with a direct call to
virDomainPCIAddressReserveAddr(), but with reserveEntireSlot = true,
fromConfig = true. That's what this patch does.
Laine Stump [Mon, 12 Sep 2016 17:21:10 +0000 (13:21 -0400)]
qemu: fix improper initialization of cgroupControllers bitmap
virQEMUDriverConfigNew() always initializes the bitmap in its
cgroupControllers member to -1 (i.e. all 1's).
Prior to commit a9331394, if qemu.conf had a line with
"cgroup_controllers", cgroupControllers would get reset to 0 before
going through a loop setting a bit for each named cgroup controller.
commit a9331394 left out the "reset to 0" part, so cgroupControllers
would always be -1; if you didn't want a controller included, there
was no longer a way to make that happen.
This was discovered by users who were using qemu commandline
passthrough to use the "input-linux" method of directing
keyboard/mouse input to a virtual machine:
Thanks to sL1pKn07 SpinFlo <sl1pkn07@gmail.com> for bringing the
problem up in IRC, and then taking the time to do a git bisect and
find the patch that started the problem.
qemu: Add the ability to hotplug the TLS X.509 environment
added a parameter "bool listen" in some methods. This
unfortunately clashes with the listen() method, causing
compile failures on certain platforms (RHEL-6 for example)
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
John Ferlan [Tue, 6 Sep 2016 21:00:30 +0000 (17:00 -0400)]
storage: Need to properly read the crypt offset value
Commit id 'a48c7141' altered how to determine if a volume was encrypted
by adding a peek at an offset into the file at a specific buffer location.
Unfortunately, all that was compared was the first "char" of the buffer
against the expect "int" value.
Restore the virReadBufInt32BE to get the complete field in order to
compare against the expected value from the qcow2EncryptionInfo or
qcow1EncryptionInfo "modeValue" field.
This restores the capability to create a volume with encryption, then
refresh the pool, and still find the encryption for the volume.
John Ferlan [Tue, 6 Sep 2016 20:52:36 +0000 (16:52 -0400)]
storage: Need to refresh secret for luks volume after volume refresh
A LUKS volume uses the volume secret type just like the QCOW2 secret, so
adjust the loading of the default secrets to handle any volume that the
virStorageFileGetMetadataFromBuf code has deemed to be an encrypted volume
to search for the volume's secret. This lookup is done by volume usage
where the usage is expected to be the path to volume.
projects / libvirt.git / log