Re: hdd kills vm

Sent: Friday, November 03, 2023 at 1:15 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 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&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'? > 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.