A Beginners Guide to PROXMOX

[Bendy_BSD]

7 minutes ago, Windows7ge said:

Part of the problem here is NTFS is not a well Linux supported File System. With some Googling things are telling me that PROXMOX does not support the mounting of NTFS volumes. At least not off of the default included packages. It looks like if you install this package:

ntfs-3g

It may enable you to mount a NTFS volume.

 

You can use virtio or iscsi for HDD pass-through, I haven't seen a real difference in terms of which is better but the command would be:

qm set #(VM) -scsi /dev/disk/by-id/disk-id

So if you wanted to pass a particular HDD through to VM 102:

qm set 102 -scsi /dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F41BLC

If you had multiple of them:

qm set 102 -scsi /dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F41BLC
qm set 102 -scsi2 /dev/disk/by-id/ata-WDC_WD2005FBYZ-01YCBB2_WD-WMC6N0H9RHJ1
qm set 102 -scsi3 /dev/disk/by-id/ata-WDC_WD2005FBYZ-01YCBB2_WD-WMC6N0H11HCD

etc. The drives would then appear in the VM properties under the Hardware tab. I've never had a problem with directly passing through HDDs but if you can spare a controller it makes things easier.

 

With regards to mounting the sata drive, the the WDC drive, is it by the mount point or the UUID of the drive?  Just making sure.

 

 

[Windows7ge]

2 minutes ago, Bendy_BSD said:

 

With regards to mounting the sata drive, the the WDC drive, is it by the mount point or the UUID of the drive?  Just making sure.

 

 

No idea. I normally don't manually mount drives. Never find myself needing to.

[Bendy_BSD]

26 minutes ago, Windows7ge said:

No idea. I normally don't manually mount drives. Never find myself needing to.

I tried passing the disk to the vm by Disk identifier and by /path/to/disk* (*= 1-9 or any number) and it didn't work.

[Windows7ge]

5 minutes ago, Bendy_BSD said:

I tried passing the disk to the vm by Disk identifier and by /path/to/disk* (*= 1-9 or any number) and it didn't work.

...are we talking about mounting that NTFS disk or we talking about disk pass-through cause now I'm confused.

[Bendy_BSD]

1 minute ago, Windows7ge said:

...are we talking about mounting that NTFS disk or we talking about disk pass-through cause now I'm confused.

the NTFS disk my bad. >.<

[Windows7ge]

2 minutes ago, Bendy_BSD said:

the NTFS disk my bad. >.<

Wait are you trying to mount it to the host or are you trying to mount it to a VM? First you have to lookup the disk id with:

ls -l /dev/disk/by-id/

find the disk then append it to the qm set command.

[Bendy_BSD]

10 hours ago, Windows7ge said:

Wait are you trying to mount it to the host or are you trying to mount it to a VM? First you have to lookup the disk id with:

ls -l /dev/disk/by-id/

find the disk then append it to the qm set command.

cool.  

Also, I'm trying to pass through my onboard Marvell sata controller to the windows vm and I used the blacklist driver by device address but I think it's not working.  should I just try it anyway without blacklisting the driver?

[Windows7ge]

1 hour ago, Bendy_BSD said:

cool.  

Also, I'm trying to pass through my onboard Marvell sata controller to the windows vm and I used the blacklist driver by device address but I think it's not working.  should I just try it anyway without blacklisting the driver?

Since I have your motherboard can you tell me the Device Address of that Marvel Controller?

 

USB controllers I haven't seen them care having their driver interrupted. SATA controllers...I don't know. It could crash the host.

[Bendy_BSD]

58 minutes ago, Windows7ge said:

Since I have your motherboard can you tell me the Device Address of that Marvel Controller?

 

USB controllers I haven't seen them care having their driver interrupted. SATA controllers...I don't know. It could crash the host.

Sata controllers will be a problem if you don't pass them through by device address, I made the mistake of blacklisting the ahci driver ohhh boy did I f*** up badly. >.<

the address by device is: 0000:0d:00.0 (if I'm not mistaken.)

[Windows7ge]

27 minutes ago, Bendy_BSD said:

Sata controllers will be a problem if you don't pass them through by device address, I made the mistake of blacklisting the ahci driver ohhh boy did I f*** up badly. >.<

the address by device is: 0000:0d:00.0 (if I'm not mistaken.)

Yeah you have to make sure no other devices rely on the drivers you blacklist. Like if you're booting from SATA and the controller it's on uses the same driver. Use grep in the lspci command to see how many devices rely on the driver before you go blacklisting them.

 

You must be 0d:00.0 is the Ethernet Controller.

[Bendy_BSD]

Just now, Windows7ge said:

Yeah you have to make sure no other devices rely on the drivers you blacklist. Like if you're booting from SATA and the controller it's on uses the same driver. Use grep in the lspci command to see how many devices rely on the driver before you go blacklisting them.

 

You must be 0d:00.0 is the Ethernet Controller.

Oh crap my bad man.   I copied that bus device because I first tried to snap shot my windows vm and long story short it spat out an error saying that it won't start or stop properly because of the ethernet controller even though I never passed through the ethernet controller to ANY vm.  

here's the marvell id: 0000:00:1c.4

[Windows7ge]

1 hour ago, Bendy_BSD said:

Oh crap my bad man.   I copied that bus device because I first tried to snap shot my windows vm and long story short it spat out an error saying that it won't start or stop properly because of the ethernet controller even though I never passed through the ethernet controller to ANY vm.  

here's the marvell id: 0000:00:1c.4

It's in its own IOMMU group but it shares its driver with 12 other devices so yes you definitely have to go by Device Address but it should be possible to pass-through provided no host drives are connected to it.

[Bendy_BSD]

1 hour ago, Windows7ge said:

It's in its own IOMMU group but it shares its driver with 12 other devices so yes you definitely have to go by Device Address but it should be possible to pass-through provided no host drives are connected to it.

would I be able to pass through the controller as long as there aren't any drive partitions mounted?  Drives connected but no partitions mounted i mean.

[Windows7ge]

7 minutes ago, Bendy_BSD said:

would I be able to pass through the controller as long as there aren't any drive partitions mounted?  Drives connected but no partitions mounted i mean.

If the drives mount as ZFS pools the pool will either become degraded or disconnect entirely. Since you have to restart the system to unload the driver it won't cause any harm to the system. Just make sure drives connected to that controller are designated for the VM using it. Existing data can be cleared or imported to the VM depending on the OS. Doesn't matter if the disks are currently mounted unless they host the VMs.

[Bendy_BSD]

12 minutes ago, Windows7ge said:

If the drives mount as ZFS pools the pool will either become degraded or disconnect entirely. Since you have to restart the system to unload the driver it won't cause any harm to the system. Just make sure drives connected to that controller are designated for the VM using it. Existing data can be cleared or imported to the VM depending on the OS. Doesn't matter if the disks are currently mounted unless they host the VMs.

when passing through the raid controller, it's just only the device address right or do I have to add the ven:dev ids in the vfio driver override in /etc/modprobe.d/ ?

[Windows7ge]

26 minutes ago, Bendy_BSD said:

when passing through the raid controller, it's just only the device address right or do I have to add the ven:dev ids in the vfio driver override in /etc/modprobe.d/ ?

I forgot my own tutorial. You can't blacklist the driver but 00:1c.4 does have a unique Device ID. So you have a choice. You can block the driver by Device ID or Device Address. IMO Device ID is faster/easier: [8086:1d18]

[Bendy_BSD]

18 hours ago, Windows7ge said:

I forgot my own tutorial. You can't blacklist the driver but 00:1c.4 does have a unique Device ID. So you have a choice. You can block the driver by Device ID or Device Address. IMO Device ID is faster/easier: [8086:1d18]

Gotcha.

Also, I had passed through my Logitech G633 headset and I have a bunch of crackling.

I had this issue before somewhat when I used my usb cable and when I switched it out, it worked just fine (baremetal install from a long time ago)

but, I decided to test the headset to see if it was the vm or the headset that is causing the issue.  So I connected my headset to my laptop and it works just fine; no crackling in audio output to speakers.

 

But on windows 10 (pci passthrough with my headset passed through) it was crackling anytime audio gets transmitted.

[Windows7ge]

3 minutes ago, Bendy_BSD said:

Gotcha.

Also, I had passed through my Logitech G633 headset and I have a bunch of crackling.

I had this issue before somewhat when I used my usb cable and when I switched it out, it worked just fine (baremetal install from a long time ago)

but, I decided to test the headset to see if it was the vm or the headset that is causing the issue.  So I connected my headset to my laptop and it works just fine; no crackling in audio output to speakers.

 

But on windows 10 (pci passthrough with my headset passed through) it was crackling anytime audio gets transmitted.

Virtualization can come with challenges like this. Did you pass the device itself through or did you pass a USB controller through and connected the headset to that?

[Bendy_BSD]

2 minutes ago, Windows7ge said:

Virtualization can come with challenges like this. Did you pass the device itself through or did you pass a USB controller through and connected the headset to that?

the headset only, not the usb controller with the headset attached.

[Windows7ge]

11 minutes ago, Bendy_BSD said:

the headset only, not the usb controller with the headset attached.

Definitely try the USB controller. Challenges like this come with the territory. I don't fully understand what caused this type of audio issue it might be from a audio sampling delay where proxmox has to act as an intermediary between the VM and your headset causing distortion. If you pass a USB controller through it gives the VM direct access to the headset which may yield better results.

[Bendy_BSD]

1 minute ago, Windows7ge said:

Definitely try the USB controller. Challenges like this come with the territory. I don't fully understand what caused this type of audio issue it might be from a audio sampling delay where proxmox has to act as an intermediary between the VM and your headset causing distortion. If you pass a USB controller through it gives the VM direct access to the headset which may yield better results.

Gotcha.

 

Also, I noticed that there are two USB controllers.  Not sure which one's which because I do intend to use one controller for the vm and the other for just proxmox itself (things like backing up to a USB flashdrive or if worst-case scenario a usb harddrive.)

[Windows7ge]

37 minutes ago, Bendy_BSD said:

Gotcha.

 

Also, I noticed that there are two USB controllers.  Not sure which one's which because I do intend to use one controller for the vm and the other for just proxmox itself (things like backing up to a USB flashdrive or if worst-case scenario a usb harddrive.)

Yeah that can be a little tricky. If you don't have any USB devices plugged in you can try passing through both one at a time and see which controller is which ports.

 

USB devices are usually also denoted by the address of the controller they're connected. Say USB controller at 00:10.0 (I didn't look that up it's not accurate) devices connected to it should me marked as 10.1, 10.2, 10.3, etc. Find this pattern when running lspci and you'll know which controller controls which physical ports.

 

Don't forget though it needs to be in its own IOMMU group so it cannot be part of the chipset.

[Bendy_BSD]

44 minutes ago, Windows7ge said:

Yeah that can be a little tricky. If you don't have any USB devices plugged in you can try passing through both one at a time and see which controller is which ports.

 

USB devices are usually also denoted by the address of the controller they're connected. Say USB controller at 00:10.0 (I didn't look that up it's not accurate) devices connected to it should me marked as 10.1, 10.2, 10.3, etc. Find this pattern when running lspci and you'll know which controller controls which physical ports.

 

Don't forget though it needs to be in its own IOMMU group so it cannot be part of the chipset.

note: for the mobo we have, Controller #2 is the front panel USB ports, and the 1st Controller is the built-in usb ports.
(For those who stumble on this response this is in regards to the mobo: Asrock EP2C602-4L/D16)

[Windows7ge]

1 hour ago, Bendy_BSD said:

note: for the mobo we have, Controller #2 is the front panel USB ports, and the 1st Controller is the built-in usb ports.
(For those who stumble on this response this is in regards to the mobo: Asrock EP2C602-4L/D16)

As I said from past experiments with QEMU/KVM it didn't seem to care when I interrupted the USB driver. That might be because of the hot swap nature of USB so you can give that a whirl. Let me know if it improves your audio.

[Bendy_BSD]

On 8/12/2020 at 9:49 AM, Windows7ge said:

As I said from past experiments with QEMU/KVM it didn't seem to care when I interrupted the USB driver. That might be because of the hot swap nature of USB so you can give that a whirl. Let me know if it improves your audio.

So far it's awesome and it's exactly as you described it with the usb driver i mean. ^u^

are xeon processors capable of nested virtualization?