Fron c3bd0019c0e on instead of creating the following path for
cgroups:
/sys/fs/cgroupX/$name.libvirt-$driver
we generate rather more verbose one:
/sys/fs/cgroupX/$driver-$id-$name.libvirt-$driver
where $name is optional and included iff contains allowed chars.
See original commit for more reasoning. Now, problem with the
original commit is that we are unable to start any LXC domain
after it. Because when starting LXC container, the CGroup layout
is created by our lxc_controller process and then detected and
validated by libvirtd. The validation is done by trying to match
detected layout against all the possible patterns for cgroup
paths that we've ever had. And the commit in question forgot to
update this part of the code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
(cherry picked from commit fb377701f253559268e903377707ed3d265823cd)
Fedora now ships edk2 firmware in its official repos, so adapt
the nvram path list to match. Eventually we can remove the nightly
links as well once some integration kinks have been worked out,
and documentation updated.
Move the macro building into the %build target, which lets us
build up a shell variable and make things a bit more readable
https://bugzilla.redhat.com/show_bug.cgi?id=1335395
(cherry picked from commit e9ef4dfac88806d02bd2f31eeb3f3bbafe505888)
Use the detected tray presence flag to trigger the tray waiting code
only if the given storage device in qemu reports to have a tray.
This is necessary as the floppy device lost it's tray as of qemu commit:
commit abb3e55b5b718d6392441f56ba0729a62105ac56
Author: Max Reitz <mreitz@redhat.com>
Date: Fri Jan 29 20:49:12 2016 +0100
Revert "hw/block/fdc: Implement tray status"
(cherry picked from commit 72a7ff6b507bcf389cc493ac0ba07d32de266d6e)
Commit 1fad65d49aae364576bd91352a001249510f8d4e used a really big hammer
and overwrote the error message that might be reported by qemu if the
tray is locked. Fix it by reporting the error only if no error is
currently set.
Error after commit mentioned above:
error: internal error: timed out waiting for disk tray status update
New error:
error: internal error: unable to execute QEMU command 'eject': Tray of
device 'drive-ide0-0-0' is not open
(cherry picked from commit 2e75da42e41af0cd48ca6f75d0606b40a366cc54)
If we exceed the timeout waiting for the tray status to change,
we don't report an error. Fix it
(cherry picked from commit 1fad65d49aae364576bd91352a001249510f8d4e)
If qemu doesn't support DEVICE_TRAY_MOVED event the code that attempts
to change media would attempt to re-eject the tray even if it wouldn't
be notified when the tray opened. Add a capability bit and skip retrying
for old qemus.
(cherry picked from commit 833ae6b4356934e7b779c4be01bd2bf051930dde)
Extract information for all disks and update tray state and source only
for removable drives. Additionally store whether a drive is removable
and whether it has a tray.
(cherry picked from commit 894dc85fd1ebcd63d8c897b355c550e68a5f432d)
Extract whether a given drive has a tray and whether there is no image
inserted.
Negative logic for the image insertion is chosen so that the flag is set
only if we are certain of the fact.
(cherry picked from commit f1690dc3d7934bf70f4fbc84d55bf210276c6f27)
Empty floppy drives start with tray in "open" state and libvirt did not
refresh it after startup. The code that inserts media into the tray then
waited until the tray was open before inserting the media and thus
floppies could not be inserted.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326660
(cherry picked from commit a34faf33011c5c0d7b47ee0849bf1e11635e17c5)
https://bugzilla.redhat.com/show_bug.cgi?id=1331552
Instead of disabling auto-login of all scsi targets (even those
that do not "belong" to libvirt), use iscsiadm's "--op nonpersistent"
during discovery of iSCSI targets (e.g. "iscsiadm --mode discovery
--type sendtargets") in order to avoid the node database being altered
which led to the need for the "large hammer" approach taken by
commit id '3c12b654'.
This commit removes the virISCSITargetAutologin adjustment (eg. the setting
of node.startup to "manual"). The iscsiadm command has supported this mode
of operation as of commit id 'ad873767' to open-iscsi.
(cherry picked from commit 56057900dc53df490d953d56de1195ebfa025bdd)
Utilize the exit status parameter for virCommandRunRegex in order to
check the return error from the 'iscsiadm --mode session' command.
Without this enabled, if there are no sessions running then virCommandRun
would have displayed an error such as:
2016-05-13 15:17:15.165+0000: 10920: error : virCommandWait:2553 :
internal error: Child process (iscsiadm --mode session)
unexpected exit status 21: iscsiadm: No active sessions.
It is possible that for certain paths (when probe is true) we only care
whether it's running or not to make certain decisions. Spitting out
the error for those paths is unnecessary.
If we do have a situation where probe = false and there's an error,
then display the error from iscsiadm if it's there.
(cherry picked from commit 8f54e0d6328eb593c2226459a03afed0da23043d)
Rather than have virCommandRun just spit out the error, allow callers
to decide to pass the exitstatus so the caller can make intelligent
decisions based on the error.
(cherry picked from commit 8b1049473317c09d34b3ce9671d0f9e91dd4f1c0)
Some of the test configuration files in tests/xlconfigdata
use the old qemu-dm as the emulator. Many of the configuration
features tested (spice, rbd, multi-usb) are not even usable with
the old qemu. Change these files to use the new qemu-xen (also
known as qemu upstream) emulator.
Note: This change fixes xlconfigtest failures when the old
qemu is actually installed on the system. During device post
parse, the libxl driver attempts to invoke the emulator to
determine if it is the old or new qemu so it can properly set
video RAM defaults. With the old qemu installed, the default
video RAM was set differently than the expected value.
Changing all the test data files to use qemu-xen ensures
predictable results wrt default video RAM size.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
(cherry picked from commit b90c4b5f505698d600303c5b4f03f5d229b329dd)
When probing the <emulator> with '-help' to determine if
it is the old qemu, errors are reported if the emulator
doesn't exist
libvirt: error : internal error: Child process
(/usr/lib/xen/bin/qemu-dm -help) unexpected exit status 127:
libvirt: error : cannot execute binary /usr/lib/xen/bin/qemu-dm:
No such file or directory
Avoid the probe if the specified emulator doesn't exist,
squelching the error. There is no behavior change since
libxlDomainGetEmulatorType() would return
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN if the probe failed
via virCommandRun().
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
(cherry picked from commit 400e716d7d8371fa718c27bb4f05b9a68929e64a)
My commit 3e42867 started filling out the video size in post-parse,
but did not adjust the tests.
(cherry picked from commit 96b21fb0ecf8242ceb298607da61b5718511a388)
Move filling out the default video (v)ram to DeviceDefPostParse.
This means it can be removed from virDomainVideoDefParseXML
and qemuParseCommandLine. Also, we no longer need to special case
VIR_DOMAIN_VIRT_XEN, since the per-driver callback gets called
before the generic one.
(cherry picked from commit 538012c8a30230065d1bfe09892279dd8b89193f)
Commit 6879be48 moved adding of an implicit video device after XML
parsing. As a result, libxlDomainDeviceDefPostParse() is no longer
called to set the default vram when adding an implicit device.
Commit 6879be48 assumes virDomainVideoDefaultRAM() will set the
default vram, but it returns 0 if the domain virtType is
VIR_DOMAIN_VIRT_XEN. Attempting to start an HVM domain with vram=0
results in
error: unsupported configuration: videoram must be at least 4MB for CIRRUS
The default vram setting for Xen HVM domains depends on the device
model used (qemu-xen vs qemu-traditional), hence setting the
default is deferred to libxlDomainDeviceDefPostParse().
Call the device post-parse callback even for implicit video,
to fill out the default vram even for VIR_DOMAIN_VIRT_XEN.
https://bugzilla.redhat.com/show_bug.cgi?id=1334557
Most-of-commit-message-by: Jim Fehlig <jfehlig@suse.com>
(cherry picked from commit 3e4286703273b06a21ae07f3e76a66f9661199dc)
Future commit will call DeviceDefPostParse on a device auto-added
in DomainDefPostParse.
(cherry picked from commit e4d131b8cb12679814b6fda159281f472b615524)
Commin 36785c7e refactored the code for input devices but introduced a
bug where we removed all keyboard from migratable XML. We have to
remove only implicit keyboards like PS2 or XEN.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Commit 1d4400082a02 added some code that was not indented properly
and broke syntax-check. Fix it.
(cherry picked from commit a528ae7fb7e24e448d2636012218109ae3ef82b6)
Previous commit moved some lists out of the -devel package
and into the -docs package
commit feffcc03a0d3690dcffd860682dcbaa61d726b39
Author: Cole Robinson <crobinso@redhat.com>
Date: Wed Apr 13 10:37:42 2016 -0400
spec: Only pull in API docs with -devel package
What was not realized is that the rule 'libvirt-docs/*'
and ' docs/*.html docs/html docs/*.gif' actually point
to the exact same content. ie, we had previously included
the website HTML in *both* the -docs and -devel packages.
So this change ended up listing the files twice, which
caused RPM to print a load of warnings:
warning: File listed twice: /usr/share/doc/libvirt-docs/html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/32favicon.png
warning: File listed twice: /usr/share/doc/libvirt-docs/html/404.html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/acl.html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/aclpolkit.html
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d6c25c34ef682a69f73f6ec200129e61b2932088)
We will segfault of a daemon reload picks up a new network config
that needs to be autostarted. We shouldn't be passing NULL for
network_driver here. This seems like it was missed in the larger
rework in commit 1009a61e
(cherry picked from commit 26af7e4e932d72e7ead88e2e687b3ee0ca4718bb)
The default USB controller is not sent to destination as the older versions
of libvirt(0.9.4 or earlier as I see in commit log of 409b5f54) didn't
support them. For some archs where the support started much later can
safely send the USB controllers without this worry. So, send the controller
to destination for all archs except x86. Moreover this is not very applicable
to x86 as the USB controller has model ich9_ehci1 on q35 and for pc-i440fx,
there cant be any slots before USB as it is fixed on slot 1.
The patch fixes a bug that, if the USB controller happens to occupy
a slot after disks/interfaces and one of them is hot-unplugged, then
the default USB controller added on destination takes the smallest slot
number and that would lead to savestate mismatch and migration
failure. Seen and verified on PPC64.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
(cherry picked from commit 192a53e07c5fefd9dad2f310886209b76dcc5d83)
Add ULL suffix to all related operands of << or shift will give
all zeros instead of correct mask.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
(cherry picked from commit 4d28d0931f87177a762f6a78cfdbcc2e30d6d4af)
Similarly to what commit 714080791778 did with some internal paths,
clear vnc socket paths that were generated by us. Having such path in
the definition can cause trouble when restoring the domain. The path is
generated to the per-domain directory that contains the domain ID.
However, that ID will be different upon restoration, so qemu won't be
able to create that socket because the directory will not be prepared.
To be able to migrate to older libvirt, skip formatting the socket path
in migratable XML if it was autogenerated. And mark it as autogenerated
if it already exists and we're parsing live XML.
Best viewed with '-C'.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326270
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 55320c23dd163e75eb61ed6bea2f339ccfeff4f9)
Instead of setting the default qemu stdio logging approach in
virQEMUDriverConfigLoadFile set it in virQEMUDriverConfigNew so that
it's properly set even when the config is not present.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325075
(cherry picked from commit 63e2b766a5a704eb19b8bdaeb1cf0fa91f990cb8)
Introduced by commit 15ad2ecf114d.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
(cherry picked from commit d3d4fb4b187e88d470d37867cdaff3f32e01efef)
If libvirt-daemon-config-network is installed while libvirtd is already
running, the daemon doesn't notice the network. Users then have to
manually restart libvirtd (or reboot) to pick up the network.
Instead let's trigger a daemon restart when the package is first installed.
Then the default network is available immediately if libvirtd was already
running.
https://bugzilla.redhat.com/show_bug.cgi?id=867546
(cherry picked from commit 1d4400082a02c41b152cc9ab7b4cfc428cc527ee)
This error message was too specific, based on the incorrect assumption
that any error was cause by auto-added bridges:
failed to create PCI bridge on bus 2: too many devices
with fixed addresses
In practice you can't know if a bridge with an index <= the bus it's
connecting to was added automatically, or if it was a mistake in
explicit config, and the auto-add problem is going to be dealt with in
a different way in an upcoming patch. The new message is this:
PCI Controller at index 1 (0x01) has "
bus='0x02', but bus must be <= index
(note that index is given in both decimal and hex because it is
formatted as decimal in the XML, but bus is formatted as hex, and
displaying the hex value of index makes it easier to see the problem
when index > 9 (which will often be the case with PCIe, since most
controllers only have a single port, not 32 slots as with standard
PCI)).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004593
(cherry picked from commit ff2126225df019566e4e580d92e69e9df3ca96c0)
QEMU_BLOCK_IOTUNE_MAX is the maximum inclusively, so let's modify the
message so it makes sense.
https://bugzilla.redhat.com/show_bug.cgi?id=1329041
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 72c313bce9043a181cc951871f38a37f6cbeb785)
Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45
However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:
http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html
Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely
https://bugzilla.redhat.com/show_bug.cgi?id=1074464
(cherry picked from commit 67f2b72723c242969c5282fcb9acf00cc01f2a54)
We presently don't give any indication if the VirtualBox version
isn't in our support whitelist.
(cherry picked from commit 18644491de68f9a654061f2748486f1c69900d17)
The values are currently limited to LLONG_MAX which causes some
problems. QEMU conveniently changed their maximum to 1e15 (1 PB) which
is enough for some time and we need to adapt to that so that we don't
throw "Unknown error" messages. Strictly limiting these values actually
fixes some corner case values (off-by-one checks in QEMU probably).
Since values out of the new specified range do not overflow anything,
change the type of error as well.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 2d04f6de77d437fa60361950e5f18fac8c1c922d)
$ echo -n 'log_level=1' > ~/.config/libvirt/libvirtd.conf
$ libvirtd --timeout=10
2014-10-10 10:30:56.394+0000: 6626: info : libvirt version: 1.1.3.6, package: 1.fc20 (Fedora Project, 2014-09-08-17:50:42, buildvm-05.phx2.fedoraproject.org)
2014-10-10 10:30:56.394+0000: 6626: error : main:1261 : Can't load config file: configuration file syntax error: /home/rjones/.config/libvirt/libvirtd.conf:1: expecting a value: /home/rjones/.config/libvirt/libvirtd.conf
Rather than try to fix this in the depths of the parser, just catch
the case when a config file doesn't end in a newline, and manually
append a newline to the content before parsing
https://bugzilla.redhat.com/show_bug.cgi?id=1151409
(cherry picked from commit 3cc2a9e0d412776a07780b090cf286cc603cea84)
According to the dnsmasq manpage, the netmask for IPv4 address ranges
will be auto-deteremined from the interface dnsmasq is listening on,
but it can't do this for IPv6 for some reason - it instead assumes a
network prefix of 64 for all IPv6 address ranges. If this is
incorrect, dnsmasq will refuse to give out an address to clients,
instead logging this message:
dnsmasq-dhcp[2380]: no address range available for DHCPv6 request via virbr0
The solution is for libvirt to add ",$prefix" to all IPv6 dhcp-range
arguments when building the dnsmasq.conf file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1033739
(cherry picked from commit bf3d9f305ebad9d8abd68e4600d2db996b860e68)
FD passing APIs like CreateXMLWithFiles or OpenGraphicsFD will leak
file descriptors. The user passes in an fd, which is dup()'d in
virNetClientProgramCall. The new fd is what is transfered to the
server virNetClientIOWriteMessage.
Once all the fds have been written though, the parent msg->fds list
is immediately free'd, so the individual fds are never closed.
This closes each FD as its send to the server, so all fds have been
closed by the time msg->fds is free'd.
https://bugzilla.redhat.com/show_bug.cgi?id=1159766
(cherry picked from commit 5ba48584fbc5079c0ddbc9e9a52c96d7bcef0761)
My commit 0d1579572 crashes on a URI without a scheme, like via
'virsh --connect frob'
Add a check on uri->server too while we are at it, and centralize
them all
(cherry picked from commit f1bae376b71ecc712e5d8359382290db1120e13e)
My commit 6879be4 moved the addition of the implicit video device
from the XML parser to the PostParse function, but did not regenerate
all the tests.
(cherry picked from commit 4b35a7155ad6b4346591dd54f03abead2f8c6e1f)
virsh vol-clone is expected to clone a volume within a single
pool; it doesn't work for cloning across pools. Clarify the docs
https://bugzilla.redhat.com/show_bug.cgi?id=1103714
(cherry picked from commit 2f1dc3de4672f4d7aa42bb4984618d382388e0d2)
VIR_ERR_NO_SUPPORT maps to the error string
this function is not supported by the connection driver
and is largely only used for when a driver doesn't have any
implementation for a public API. So its usage with invalid
net-update requests is a bit out of place. Instead use
VIR_ERR_OPERATION_UNSUPPORTED which maps to:
Operation not supported
And is what qemu's hotplug routines use in similar scenarios
(cherry picked from commit cdb4caac81606b8c1bb6ed6f3c0e5d06e4b8b3d6)
This reverts commit 1e9808d3a1e00a7121bae8b163d9c42d441d2ca8.
We shouldn't advertise libvirtd.socket activation, since currently
it means VM/network/... autostart won't work as expected.
We tried to find a middle ground by installing the config file without
an [Install] section, since systemd won't allow .socket to be enabled
without one... or at least it did do that; presently on f24 it allows
activating the socket quite happily. This also caused user confusion[1]
Just remove the socket file. I've filed a new RFE to track coming up
with a solution to the autostart problem[2], we can point users at that
if there's more confusion:
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1279348
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1326136
(cherry picked from commit 3b9100a4d255fdb5f731fcfa49326746d371894a)
