Sent: Friday, November 03, 2023 at 2:04 PM
From: "daggs via Users" <users(a)lists.libvirt.org>
To: "Martin Kletzander" <mkletzan(a)redhat.com>
Cc: users(a)lists.libvirt.org
Subject: Re: hdd kills vm
> Sent: Friday, November 03, 2023 at 1:15 PM
> From: "Martin Kletzander" <mkletzan(a)redhat.com>
> To: "daggs" <daggs(a)gmx.com>
> Cc: users(a)lists.libvirt.org
> Subject: Re: hdd kills vm
>
> On Thu, Nov 02, 2023 at 06:06:24PM +0100, daggs wrote:
> >
> >
> >> Sent: Thursday, November 02, 2023 at 2:34 PM
> >> From: "Martin Kletzander" <mkletzan(a)redhat.com>
> >> To: "daggs" <daggs(a)gmx.com>
> >> 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>
> >> >> To: "daggs" <daggs(a)gmx.com>
> >> >> 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'?
> >
>
> I think so, make sure it is the right disk. You could also pass through the
> whole HBA with type='scsi_host' since it looks like there is nothing else
on
> that one IIUC.
I'll try with managed=yes
tried that, didn't booted. any idea what am I
doing wrong?
>
>
> >
> > >>
> > >> > <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.
> > >> >
> > >>
> > >
> >
> _______________________________________________
> Users mailing list -- users(a)lists.libvirt.org
> To unsubscribe send an email to users-leave(a)lists.libvirt.org
>