3:13 p.m.
On Sat, Nov 04, 2023 at 11:18:10AM +0100, daggs wrote:
> Sent: Friday, November 03, 2023 at 2:43 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 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?
took a step back to look at it and tried with an linux vm.
the original config (with managed='no') works, other wise it fails.
the error was because of my vm booting framework.
in general, the performance is way better but it seems that windows cannot handle the two
instances of the same
hdd... this caused the system to go nuts so now I'm backing up the installation image
to an external device and reinstall the os again.
not sure what two instances of the same hdd you mean, but that would
certainly make a big mess
this time with the proper config.
I also removed the hardcoded cpu placement and let libvirt decide.
well, that'll be up to the kernel. You can keep it in and it will
provide some boost if it's correct.
thanks for all the help
I'm glad you figured something out, I was a bit unsure about what is
happening on you end, so it's good to know there's progress.
>
> >
> >
> > >
> > > >>
> > > >> > <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
> >
> _______________________________________________
> Users mailing list -- users(a)lists.libvirt.org
> To unsubscribe send an email to users-leave(a)lists.libvirt.org
>