Re: hdd kills vm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
To: "daggs" <daggs@xxxxxxx>
Cc: users@xxxxxxxxxxxxxxxxx
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@xxxxxxxxxx>
>> To: "daggs" <daggs@xxxxxxx>
>> Cc: users@xxxxxxxxxxxxxxxxx
>> 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%20Ray%20passthrough.md

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.


>  <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.
>


Attachment: signature.asc
Description: PGP signature

_______________________________________________
Users mailing list -- users@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxx

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux