Re: hdd kills vm

> Sent: Thursday, November 02, 2023 at 2:34 PM > From: "Martin Kletzander" <mkletzan(a)redhat.com&gt; > To: "daggs" <daggs(a)gmx.com&gt; > Cc: users(a)lists.libvirt.org > Subject: Re: hdd kills vm > > On Wed, Nov 01, 2023 at 10:24:05PM +0100, daggs wrote: > >> Sent: Wednesday, November 01, 2023 at 10:06 AM > >> From: "Martin Kletzander" <mkletzan(a)redhat.com&gt; > >> To: "daggs" <daggs(a)gmx.com&gt; > >> Cc: users(a)lists.libvirt.org > >> Subject: Re: hdd kills vm > >>

> >> >so bottom line, you suggest the following: > >> >1. remove the manual cpu pin, let qemu sort that out. > >> > >> You might try it, of course pinning it is in the end the better option. > >> > >> >2. add a virtio scsi controller and connect the os hdd to it > >> >3. pass the hss via scsi pt and not dev node > >> >4. if I able to do #3, no need to add device='lun' as it won't use the disk option > >> > > >> > >> First try (3), then you don't need to do anything else and if that > >> succeeds you have the superior configuration. If you can pass through > >> something that will not remove anything from your host system. > >> > >> >Dagg. > >> > > >> > > > >I've decided to first try #3 as yo suggested, based on this output: > >$ lsscsi > >[0:0:0:0] disk ATA WDC WD1003FZEX-0 1A01 /dev/sda > >[1:0:0:0] disk ATA WDC WD10EZEX-08W 1A02 /dev/sdb > >[2:0:0:0] disk ATA SAMSUNG HD103SJ 0001 /dev/sdc > >[3:0:0:0] disk ATA SAMSUNG HD103SJ 0001 /dev/sdd > >[4:0:0:0] disk ATA ST1000DM005 HD10 00E5 /dev/sde > >[5:0:0:0] disk ATA WDC WD10EZEX-08W 1A02 /dev/sdf > >[6:0:0:0] disk Kingston DataTraveler 3.0 0000 /dev/sdg > >[7:0:0:0] cd/dvd TS8XDVDS TRANSCEND 1.02 /dev/sr0 > > > >I deduced my data is 0:0:0:0, so I've added this to the file: > > I have to trust you here, the link to the XML does not lead anywhere at the moment. > used this tutorial: https://github.com/stevenewbs/blog/blob/master/libvirtd%20qemu%20Blu%20Ra... new link is here: https://bpa.st/SU4Q > ><controller type='scsi' index='0' model='virtio-scsi'> > > <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> > ></controller> > ><hostdev mode='subsystem' type='scsi' managed='no'> > > With managed='no' you are responsible for detaching and re-attaching the device > for it to be accessible to QEMU. With managed='yes' libvirt can do that for > you. But be really really sure that it is the device you want to plug to the > guest domain. so it should work if I set managed to 'yes'?

> > > <source> > > <adapter name='scsi_host0'/> > > <address bus='0' target='0' unit='0'/> > > </source> > > <address type='drive' controller='0' bus='0' target='0' unit='0'/> > ></hostdev> > >removed the previous config and tried to boot, the vm didn't booted, the qemu log shows this: > >char device redirected to /dev/pts/0 (label charserial0) > >2023-11-01T05:00:27.949977Z qemu-system-x86_64: vfio: Cannot reset device 0000:07:00.4, depends on group 16 which is not owned. > >2023-11-01T05:00:28.113089Z qemu-system-x86_64: vfio: Cannot reset device 0000:07:00.4, depends on group 16 which is not owned. > >2023-11-01T05:01:04.511969Z qemu-system-x86_64: libusb_release_interface: -99 [OTHER] > >2023-11-01T05:01:04.511993Z qemu-system-x86_64: libusb_release_interface: -99 [OTHER] > >2023-11-01T17:22:48.200982Z qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] > >2023-11-01T17:22:48.201015Z qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] > >2023-11-01T17:22:48.201025Z qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] > >2023-11-01T17:22:48.201035Z qemu-system-x86_64: libusb_release_interface: -4 [NO_DEVICE] > >libusb_release_interface: -4 [NO_DEVICE] > >libusb_release_interface: -4 [NO_DEVICE] > >libusb_release_interface: -4 [NO_DEVICE] > >libusb_release_interface: -4 [NO_DEVICE] > >2023-11-01T20:37:31.246043Z qemu-system-x86_64: vfio: Cannot reset device 0000:07:00.4, depends on group 16 which is not owned. > >2023-11-01T20:37:31.465993Z qemu-system-x86_64: vfio: Cannot reset device 0000:07:00.4, depends on group 16 which is not owned. > >2023-11-01T20:38:07.049875Z qemu-system-x86_64: libusb_release_interface: -99 [OTHER] > >2023-11-01T20:38:07.049910Z qemu-system-x86_64: libusb_release_interface: -99 [OTHER] > >2023-11-01T20:38:07.050063Z qemu-system-x86_64: libusb_set_interface_alt_setting: -99 [OTHER] > >2023-11-01T20:47:47.400781Z qemu-system-x86_64: libusb_release_interface: -99 [OTHER] > >2023-11-01T20:47:47.400804Z qemu-system-x86_64: libusb_release_interface: -99 [OTHER] > >2023-11-01 20:47:57.096+0000: shutting down, reason=shutdown > >2023-11-01 20:57:37.514+0000: shutting down, reason=failed > > > >if I keep the scsi part but restore the previous device pt, it boots. > >any idea why it failed booting? > > > >Dagg. > > >