Failed to get udev device for syspath '/sys/devices/virtual/dmi/id'
by Mathieu Tarral
Hi,
I'm facing an issue with libvirt and the LIBXL driver, failing when searching for DMI data in /sys.
info : libvirt version: 5.0.0, package: 4+deb10u1 (Guido Günther <agx(a)sigxcpu.org> Thu, 05 Dec 2019 00:22:14 +0100)
error : udevGetDMIData:1719 : internal error: Failed to get udev device for syspath '/sys/devices/virtual/dmi/id' or '/sys/class/dmi/id'
error : libxlDriverConfigNew:1803 : Unable to configure libxl's memory management parameters
error : virStateInitialize:662 : Initialization of LIBXL state driver failed: internal error: Failed to get udev device for syspath '/sys/devices/virtual/dmi/id' or '/sys/class/dmi/id'
error : daemonRunStateInit:799 : Driver state initialization failed
The relevant function udevGetDMIData in libvirt:
https://github.com/libvirt/libvirt/blob/cb09344a2cccc0cc9bcefa3cb53d7af45...
I don't understand what's happening, as this initialization failure only happens when I boot on the Xen kernel.
Also, the /sys/class/dmi* paths are not exposed on Xen.
Note: Running on Xen 4.12.1
Any ideas ?
Thanks !
4 years
Encrypting boot partition Libvirt not showing the OS booting up
by john doe
Hi,
I have installed Debian Buster with encrypted LVM so apon installation
my root partition is encrypted.
So far so good but as soon as I encrypt the boot partition, after reboot
the OS won't start.
If I start the drive directly with qemu, it works but it looks like
Libvirt is somehow not able to deel with it.
What am I missing?
--
John Doe
4 years
Building libvirt library without libvirtd or virsh
by Román González
Hello there,
I'm trying to play with musl and libvirt to see if I'm able to build a
libvirt client binary without dynamic lib dependencies. I have two
questions:
1) to your knowledge, is this exercise futile?
2) Do you know if there is a way to *only* compile the library bits?
I want to reduce the number of dependencies in the build, and only
construct the libvirt libraries, not libvirtd nor virsh.
Thanks in advance for any help you can provide.
Roman.-
4 years
Is it possible that "virsh destroy" does not stop a domain ?
by Lentes, Bernd
Hi,
Is it possible that "virsh destroy" does not stop a domain ?
I'm asking because i have some domains running in a two-node HA-Cluster (pacemaker).
And sometimes one node get fenced (killed) because it couldn't stop a domain.
That's very ugly.
This is also the reason why i asked before what "virsh destroy" really does ?
IIRC a kill -9 can't terminate a process which is in "D" state (uninterruptible sleep).
So if the process of the domain is in "D" state, it can't be finished. Right ?
Pacemaker tries to shutdown or destroy a domain with a resource agent, which is a shell script, similar
to an init script.
Here is an excerp from the resource agent for virtual domains:
force_stop()
{
local out ex translate
local status=0
ocf_log info "Issuing forced shutdown (destroy) request for domain ${DOMAIN_NAME}."
out=$(LANG=C virsh $VIRSH_OPTIONS destroy ${DOMAIN_NAME} 2>&1) # hier wird die domain destroyed
ex=$?
translate=$(echo $out|tr 'A-Z' 'a-z')
echo >&2 "$translate"
case $ex$translate in
*"error:"*"domain is not running"*|*"error:"*"domain not found"*|\
*"error:"*"failed to get domain"*)
: ;; # unexpected path to the intended outcome, all is well sucess
[!0]*)
ocf_exit_reason "forced stop failed" # <============ fail of destroy seems to be possible
return $OCF_ERR_GENERIC ;;
0*)
while [ $status != $OCF_NOT_RUNNING ]; do
VirtualDomain_status
status=$?
done ;;
esac
return $OCF_SUCCESS
}
The function force_stop is responsible for stop/destroy the domain.
And it cares about a non-working "virsh destroy".
Is there a developer who can explain what "virsh destroy" really does ?
Or is there another ML for the developers ?
Bernd
--
Bernd Lentes
Systemadministration
Institute for Metabolism and Cell Death (MCD)
Building 25 - office 122
HelmholtzZentrum München
bernd.lentes(a)helmholtz-muenchen.de
phone: +49 89 3187 1241
phone: +49 89 3187 3827
fax: +49 89 3187 2294
http://www.helmholtz-muenchen.de/mcd
stay healthy
Helmholtz Zentrum München
Helmholtz Zentrum München
4 years
PCI Passthrough and Surprise Hotplug
by Marc Smith
Hi,
I'm using QEMU/KVM on RHEL (CentOS) 7.8.2003:
# cat /etc/redhat-release
CentOS Linux release 7.8.2003
I'm passing an NVMe drive into a Linux KVM virtual machine (<type
arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>) which has the
following 'hostdev' entry:
<hostdev mode='subsystem' type='pci' managed='yes'>
<driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x42' slot='0x00' function='0x0'/>
</source>
<alias name='hostdev5'/>
<rom bar='off'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x0f'
function='0x0'/>
</hostdev>
This all works fine during normal operation, but I noticed when we
remove the NVMe drive (surprise hotplug event), the PCIe EP then seems
"stuck"... here we see the link-down event on the host (when the drive
is removed):
[67720.177959] pciehp 0000:40:01.2:pcie004: Slot(238-1): Link Down
[67720.178027] vfio-pci 0000:42:00.0: Relaying device request to user (#0)
And naturally, inside of the Linux VM, we see the NVMe controller drop:
[ 1203.491536] nvme nvme1: controller is down; will reset:
CSTS=0xffffffff, PCI_STATUS=0xffff
[ 1203.522759] blk_update_request: I/O error, dev nvme1n2, sector
33554304 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 1203.560505] nvme 0000:01:0f.0: Refused to change power state, currently in D3
[ 1203.561104] nvme nvme1: Removing after probe failure status: -19
[ 1203.583506] Buffer I/O error on dev nvme1n2, logical block 4194288,
async page read
[ 1203.583514] blk_update_request: I/O error, dev nvme1n1, sector
33554304 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
We see this EP is found at IOMMU group '76':
# readlink /sys/bus/pci/devices/0000\:42\:00.0/iommu_group
../../../../kernel/iommu_groups/76
And it is no longer bound to the 'vfio-pci' driver (expected) on the
host. I was expecting to see all of the FD's to the /dev/vfio/NN
character devices closed, but it seems they are still open:
# lsof | grep "vfio/76"
qemu-kvm 242364 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242502 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242511 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242518 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242531 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242533 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242542 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242550 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
qemu-kvm 242364 242554 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
SPICE 242364 242559 qemu 70u CHR 235,4
0t0 3925324 /dev/vfio/76
After the NVMe drive was removed for 100 seconds, we see the following
kernel messages on the host:
[67820.179749] vfio-pci 0000:42:00.0: Relaying device request to user (#10)
[67900.272468] vfio_bar_restore: 0000:42:00.0 reset recovery - restoring bars
[67900.272652] vfio_bar_restore: 0000:42:00.0 reset recovery - restoring bars
[67900.319284] vfio_bar_restore: 0000:42:00.0 reset recovery - restoring bars
I also noticed these messages related to the EP that is down currently
that seem to continue indefinitely on the host (every 100 seconds):
[67920.181882] vfio-pci 0000:42:00.0: Relaying device request to user (#20)
[68020.184945] vfio-pci 0000:42:00.0: Relaying device request to user (#30)
[68120.188209] vfio-pci 0000:42:00.0: Relaying device request to user (#40)
[68220.190397] vfio-pci 0000:42:00.0: Relaying device request to user (#50)
[68320.192575] vfio-pci 0000:42:00.0: Relaying device request to user (#60)
But perhaps that is expected behavior. In any case, the problem comes
when I re-insert the NVMe drive into the system... on the host, we see
the link-up event:
[68418.595101] pciehp 0000:40:01.2:pcie004: Slot(238-1): Link Up
But the device is not bound to the 'vfio-pci' driver:
# ls -ltr /sys/bus/pci/devices/0000\:42\:00.0/driver
ls: cannot access /sys/bus/pci/devices/0000:42:00.0/driver: No such
file or directory
And appears to fail when attempting to bind to it manually:
# echo "0000:42:00.0" > /sys/bus/pci/drivers/vfio-pci/bind
-bash: echo: write error: No such device
Device is enabled:
# cat /sys/bus/pci/devices/0000\:42\:00.0/enable
1
So, wondering if this is expected behavior? Stopping the VM and
starting it (virsh destroy/start) allows the device to work in the VM
again, but for my particular use case, this is not an option. Need the
surprise hotplug functionality to work with the PCIe EP passed into
the VM. And perhaps this is an issue elsewhere (eg, vfio-pci). Any
tips/suggestions on where to dig more would be appreciated.
Thanks for your time.
--Marc
4 years
time in domain very unstable
by Lentes, Bernd
Hi,
i have a domain (SLES 10 SP4) running with KVM.
Time is very wrong when booting unless ntp synchronizes.
What can i do ?
Bernd
--
Bernd Lentes
Systemadministration
Institute for Metabolism and Cell Death (MCD)
Building 25 - office 122
HelmholtzZentrum München
bernd.lentes(a)helmholtz-muenchen.de
phone: +49 89 3187 1241
phone: +49 89 3187 3827
fax: +49 89 3187 2294
http://www.helmholtz-muenchen.de/mcd
stay healthy
Helmholtz Zentrum München
Helmholtz Zentrum München
4 years
what does "virsh destroy" really ?
by Lentes, Bernd
Hi,
what does "virsh destroy" with the domain ? Send a kill -9 to the process ?
Bernd
--
Bernd Lentes
Systemadministration
Institute for Metabolism and Cell Death (MCD)
Building 25 - office 122
HelmholtzZentrum München
bernd.lentes(a)helmholtz-muenchen.de
phone: +49 89 3187 1241
phone: +49 89 3187 3827
fax: +49 89 3187 2294
http://www.helmholtz-muenchen.de/mcd
stay healthy
Helmholtz Zentrum München
Helmholtz Zentrum München
4 years
Any way to persistently edit a single VM's AppArmor profile?
by Brian Turek
In order to test a patch I submitted I've been experimenting with
"qemu:commandline" to use some newer features for a QEMU host/guest file
share. I quickly ran into issues with AppArmor as virt-aa-helper
understandably doesn't parse "qemu:commandline" for directories to add to
the dynamically generated AppArmor profile.
After reading a bunch of documentation, I cannot find a way to persistently
edit a single VM's AppArmor profile. virt-aa-helper will respect a
pre-existing "/etc/apparmor.d/libvirt/libvirt-<uuid>" file but then delete
it when the VM shuts down. virt-aa-helper does not respect pre-existing
"/etc/apparmor.d/libvirt/libvirt-<uuid>.files" and will just overwrite it.
The best I came up with was to edit
"/etc/apparmor.d/abstractions/libvirt-qemu" but that affects ALL QEMU-based
VMs whereas I really only need to tweak one profile.
I'm an AppArmor novice so I'm hoping there might be some other way to do
what I need. Anyone have any ideas?
Thank you
4 years
