Help needed on passthrough of SSD WIN 10 to virt-manager

just watching the vid now, to see where the passthrough is mentioned, and fails.

I presume you can run a VM with just a virtual storage space to see if the rest all works?

Right, what kind of tasks would you like to do with your system once it’s all running?
Like, editing, or developing, or testing, or gaming?
Or just for services or hosting?

looks like there was already a thread about this with a possible soultion:

i am looking to run manjaro for my main work and a windows 10 VM machine(which is also a bare-metal in case i need it) for gaming.

Okay, the reason I ask, is because GPU’s can be finnekey.

The link above briefly describes how to pass through a block device, in Virt-Manager, without having to mess with the cli/virsh.

It also suggests to use the /dev/disk/by-id/ name for the device, rather than the /dev/sda because that letter can change.

so if you did:
ls -la /dev/disk/by-id/ | grep sda

it’d give the ata-OCZVertex4000shdfjhsd name for the drive, which won’t change.
It’ll also list the partition names as -part1 and -part2 etc.

I would say look at the Arch Wiki for info as well, but there is a lot to take in, so take a little time, try a few things, hit some errors, google them and carry on trying the next bit.

Nvidia GPU’s are notorious for troubles in guests, but that is another can of worms…

there are a few guides on this forum for the set up, two of the the most rated are here:

and the Arch Wiki is best reguarded written source for non partisan advice:
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF

1 Like

after running the QUEM/KVM with the /dev/disk/by-id all i get is a error of booting:

Booting from Hard Disk…
No bootable device .

ill read the thread’s you linked and watch the video and try to make it running…

Okay, not so useful. As a trial, I presume that you tried with the /dev/sda just to check?

I saw a few posts about having to delete part of the disk, but that is something you don’t want to do if you can avoid it.

Another test would be to make a virtual storage pool rather than the raw disk, to make sure you can get something runngin, before you chuck the already-configured drive at it?

So just make any machine, and create a new storage space in any old folder, like a 30gb file, just to practice installing windows and stuff?

used both methods, the /dev/sda and the ata name

okay, that’s annoying.

So let’s step back a bit, and try making a VM with the created storage file, make sure that works?

like, paring back a few steps to see which way forward?

so i played with it some more and i noticed that if i add sda sda1 and sda2 and change their boot order the message i get changes as well.
the system itself sits on sda2 and the message are as follow depending on boot order:
sda -

Booting from Hard Disk…
No bootable device.

sda1-

Booting from Hard Disk…
Boot failed: not a bootable disk.
No bootable device.

sda2-
stuck on

Booting from Hard Disk…

for like 15-20 min stright…
and after checking the XML its exactly like you wrote to me under devices so i dont see the problem…

Right, okay, I have a last thought, but must retire for the evening.

In general, when windows is first normally installed, it sets up the boot sequence, right?
It gathers data about the computer, and the drives, and stuff, then sets the order and settings needed to load the OS.
So you have taken an existing drive, with all the boot setup which expects to be looking for a motherboard, hard drive, usb bus, memory channels and chipset and stuff,
but ripped that out, and wrapped it in the VM, confining it and isolating it from all that stuff.
So instead, the boot sector sees all the stuff provided by the VM, like Virtual ram, Virtual USB bus, virtual network card and stuff.

I think the bootloader is just a bit confused.

I would suggest, if you can, to copy the original drive to a temporary drive(hdd or virtual drive image), and play around “fixing” the startup section with a windows10 install ISO attached to the VM, and choosing the “repair computer” option.

If you don’t have another drive to copy, and play with, then you Might potentially be able to try and fix the boot partition with the original drive, but you might not ever be able to boot to windows separate again, and changes will be permanent, and you should really practice first, if you can on a copied drive.
I know it’s a pain, but that would only be if you don’t want to start from scratch.

Anyway, I’m off to bed, and wish you luck!

i installed a windows 10 from iso in the same virt-manager settings just now…
i really don’t know why the /dev/sdb doesn’t work for me it really frustrating…

1 Like

Quick not for people supporting virt0manager here.
It does support editing the XML directly in virt-manager.
virsh would be needed only to change the schema.

Regarding the problem - I believe your Windows installation is using UEFI and it is either not located on the same drive or you have created a VM that does not support UEFI.

Please fill in the following:

  1. Does your PC boot into windows right away and shows the wheel of death? (Rotating dot pattern)
  2. When you created the VM in the virt-manager, did you select that it will be Win10?
  3. In overview of the VM, does it show: Chipset: Q35 and Firmware: UEFI
  4. When you installed Win on your computer did you have any other drives in it?
  5. Is there a small 100MB partion on the SSD you are trying to push?
  1. no, my PC boot order is as follow:
    BIOS, Password from encrepted Manjaro, GRUB menu, Manjaro/Windows 10(selected from the GRUB menu)
    the windows 10 works just fine from GRUB, im writing this message on it right now.
  2. i selected it as windows 10 and as generic, it doesnt do anything.
  3. yes
  4. no.
  5. yes its called /dev/sdb1, the system itself is on /dev/sdb2 but i already tried pushing /dev/sdb, /dev/sdb1 and /dev/sdb2, /dev/sdb and sdb1 and sdb2, /dev/sdb1 only, /dev/sdb2 only
    nothing worked.

EDIT:
ok i just checked and the Firmware was on BIOS, changed it to UEFI and now i get this from running the vm:

Now that is on UEFI it matters how you passed it and what is setup in the boot section of the virt-manager. Try to pass the entire drive as raw using SATA (For sata drive), then make sure it is selected for boot.

it doesn’t matter, even if i pass the entire drive as raw using SATA its still gives me UEFI Shell.
look at the settings:
Imgur
Imgur
Imgur

this is the XML:

> <disk type="block" device="disk">
>   <driver name="qemu" type="raw" cache="none" io="native"/>
>   <source dev="/dev/sdb" index="1"/>
>   <backingStore/>
>   <target dev="sda" bus="sata"/>
>   <alias name="sata0-0-0"/>
>   <address type="drive" controller="0" bus="0" target="0" unit="0"/>
> </disk>

Looks like the efi shell just needs to know where the boot program is.
Looking for BOOTX64.efi or something

You might try entering these in the efi shell, (the bit after the > arrow)

SHELL>cd BLK2
FS1>dir
#(then it lists the directories, we want either efi then boot or boot then efi, not sure which)
FS1>dir efi\boot\  # or dir boot\efi
#lists contents. we need an efi file, if I remember, it's called bootx64.efi
FS1>cd efi\boot\ # might not need to actully load the directory first
FS1\efi\boot>bootx64.efi 

If the bit in front changes from SHELL> that’s fine, even if it changes to BLK2> or FS0>
if the dir commands wirk, but no efi or boot folder, try the other blk device/file system?

if i try to cd or ls it gives me:
Current directory not specified.

Ah, try

BLK2:

first, to select device

or

BLK1: