This post is part of a homelab series I'll be rolling out through the next few weeks. I have two custom servers I've built for my homelab, one of which has a Nvidia P2000 that I would like to use inside a Ubuntu VM.

In order to use a PCIe device inside your VM, you need do a little magic inside your Proxmox host.

---

### Host Config (Proxmox)

1. To start, we need to enable **IOMMU** on the Promxox host. With your editor of choice, open up `/etc/default/grub`, and comment out the `#GRUB_CMDLINE_LINUX_DEFAULT="quiet"`, replace with `GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on"`. If you are using an intel cpu, then use `intel_iommu=on` instead.

```
# /etc/default/grub
...
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Proxmox Virtual Environment"
#GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on pcie_acs_override=downstream,multifunction video=efifb:eek:ff"
GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/pve-1 boot=zfs"
...
```
Save the file and then run `update grub`

Verify that IOMMU is enabled, reboot then run:
`dmesg | grep -e DMAR -e IOMMU`

2. Add the following lines to `/etc/modules`, save then exit.

```
# /etc/modules

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

```

3. This next step assumes you have created a VM inside proxmox already. If you haven't done so yet, go ahead. Default bios is fine for linux, if you are setting up a windows virtual machine, set the bios to `ovmf`. Once finished, shut down the vm and edit it's conf file. I'm adding `q35` as the machine type, and some cpu configurations.

```
# /etc/pve/qemu-server/100.conf
# Replace 100.conf with the ID of your VM.

...
cpu: host,hidden=1,flags=+pcid
machine: q35
...
```

4. This next step is little bit of a pain, but basically it allows us to properly identify our GPU so that we can add it in the VM GUI config area.

`lspci -v` to print out a list of hardware. It will be lengthy, but identify your GPU. Somewhere in that list, you should find your GPU. Here's what my output looks like:

```
...
2d:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1)
        Subsystem: NVIDIA Corporation GP106 High Definition Audio Controller
        Flags: bus master, fast devsel, latency 0, IRQ 155
        Memory at f7080000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Kernel driver in use: vfio-pci
        Kernel modules: snd_hda_intel
...
```

Now that we've found it, lets get more info on it by running `lspci -n -s 2d:00`

```
2d:00.0 0300: 10de:1c30 (rev a1)
2d:00.1 0403: 10de:10f1 (rev a1)
```

Great, so now we just want to add the pci ID's to the vfio.conf file. The ID's in my case are `10de:1c30` and `10de:10f1`.

Now let's just add it to the vfio.conf file:
`echo "options vfio-pci ids=10de:1c30,10de:10f1" > /etc/modprobe.d/vfio.conf` 

5. We need to add some lines to the proxmox's blacklist conf file.

```
# /etc/modprobe.d/pve-blacklist.conf

blacklist nvidiafb
blacklist nvidia
blacklist radeon
blacklist nouveau
```

Save then exit. This would also be a good time to restart your proxmox host.

6. Now we can finally add our GPU to our virtual machine. Under the hardware settings area, add a new PCI device:
![proxmox-1](//images.ctfassets.net/soglt180o4mt/6rPoHbQCiMD84RTB8lJq5U/45ca6285874c18be638251d25a0494f7/proxmox-1.png)

A list will appear, find and select your GPU from the list:
![proxmox-2](//images.ctfassets.net/soglt180o4mt/55WXiX60jOlVo4B9WTvC7J/fd13526194fa01ddda6084cc0b39da58/proxmox-2.png)

Be sure to enable All Functions, Rom-Bar, and PCI-Express:
![proxmox-3](//images.ctfassets.net/soglt180o4mt/27apBYP83OsVIJoQSJxXa2/647adf1d824b3e8d984d94d1558ddb60/proxmox-3.png)
If you Also turn on Primary GPU, then you won't be able to console into the virtual machine through the proxmox host (you can still ssh into it!). Click 'ok' and then start up your VM!

The last step is to ssh into the virtual machine, and check that our GPU is being recognized.

Run the following command. If all things went well, then you should be able to identify your GPU in the list:

`lshw -c video`

```
 *-display
       description: VGA compatible controller
       product: GP106GL [Quadro P2000]
       vendor: NVIDIA Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vga_controller bus_master cap_list rom

```

If you see your graphics card in the output, congrats! The next step would be installing drivers, but I'll save that for another post.

Cheers!

---

### References
- [Official Promox](https://pve.proxmox.com/wiki/PCI(e)_Passthrough)
- [manjaro.site](https://manjaro.site/how-to-enable-gpu-passthrough-on-proxmox-6-2/)
- [Beginners Guide to GPU passthrough](https://www.reddit.com/r/homelab/comments/b5xpua/the_ultimate_beginners_guide_to_gpu_passthrough/)


proxmox-pcie-passthrough

PCIe Passthrough on Proxmox v6.3-3

When first learning React, you are introduced to the concept of components. I first learned React though the official docs, and therefore started crafting my functional components the way it taught. After spending some time in other OSS projects, as well was watching quite a few online courses and guides on React, I noticed other ways of writing these functional components.

So a couple months ago, I asked [how do you write your functional components?](https://spectrum.chat/users/jonlprd?thread=91f98b74-a6b0-44ea-807f-372695da6926) over at [spectrum.chat](https://spectrum.chat/). The question also gained some traction over on [twitter](https://twitter.com/mxstbr/status/996653187481460736). People have a lot to say when it comes to how they write their functional components!

This was very educational and exposed me to a couple different ways to write React components. This also inspired me to write a short post on what the differences are between them. This is hardly an exhaustive blog post on the subject! I am writing this to help engrain the concepts into my head. 

With that said, how you choose to write your React components is simply a matter of taste and/or whatever convention(s) your team has decided on. We'll keep it simple and only discuss functional, or (dumb) components today.

---

### Normal Functions

As the [React documentation](https://reactjs.org/docs/components-and-props.html#functional-and-class-components) states:
> "The simplest way to define a component is to write a JavaScript function."

```jsx

function Welcome(props) {
 return <h1>Hello, {props.name}</h1>;
}

```

> "This function is a valid React component because it accepts a single “props” (which stands for properties) object argument with data and returns a React element. We call such components “functional” because they are literally JavaScript functions."

Whats really great about React is that it makes you a better Javascript developer. Components are simply Javascript functions, there is no abstraction going on here. Lets create a simple component that we'll transform throughout this blog post:

```jsx
export default function NormalFunction(props) {
 return (
 
 Greetings, {props.name}. I am {props.age} years old.
 
 );
}
```

If you are writing your component in a separate file, then you'll need to export it so that you can import it wherever you intend to use it. If you are writing a normal function declaration, you can either do this directly inline, like in the example above, or you can export at the bottom of your file like so:

```jsx
function NormalFunction(props) {
 return (
 
 Greetings, {props.name}. I am {props.age} years old.
 
 );
}

export default NormalFunction;
```

When reading the React documentation, I was curious why no components were written with arrow functions (I see so many out in the wild!). Dan Abramov helped clear my curiosity:

> In the docs we tend to prefer function declarations because people are more familiar with them. Hoisting is also helpful when you have many components in one file and want to define them in top-to-bottom order.

Curious what hoisting is? Here's an excerpt from the [MDN docs](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting):

> Conceptually, for example, a strict definition of hoisting suggests that variable and function declarations are physically moved to the top of your code, but this is not in fact what happens. Instead, the variable and function declarations are put into memory during the compile phase, but stay exactly where you typed them in your code.

Again, another great example of how React helps you become a better Javascript developer.

---

### Arrow Functions
We can also write React components by using [ES6 Arrow Functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions). For this example, we'll just do the same as the function above and write `props` as our single parameter. I'll explain prop destructuring in more detail in the next section.

```javascript
const ArrowFunction = ( props ) => {
 return (
 
 Greetings, {props.name}. I am {props.age} years old.
 
 );
};

export default ArrowFunction;
```

We could also omit the curly braces, and remove the return statement (unique to arrow functions):
```jsx
const ArrowFunction = props => (
 
 Greetings, {props.name}. I am {props.age} years old.
 
);

export default ArrowFunction;
```

Unlike our normal function, we cannot `export default` directly inline, so we'll have to do so at the bottom. It's also important to note that arrow function definitions are not hoisted like normal function declarations. 

Another topic we should explore is [function name inference](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name). In section [7.1](https://github.com/airbnb/javascript#functions--declarations) of AirBNB's style guide, they suggest to use named function expressions instead of function declarations.
>Why? Function declarations are hoisted, which means that it’s easy - too easy - to reference the function before it is defined in the file. This harms readability and maintainability. If you find that a function’s definition is large or complex enough that it is interfering with understanding the rest of the file, then perhaps it’s time to extract it to its own module! Don’t forget to explicitly name the expression, regardless of whether or not the name is inferred from the containing variable (which is often the case in modern browsers or when using compilers such as Babel). This eliminates any assumptions made about the Error's call stack.

If you are using [@babel/preset-env](https://github.com/babel/babel/tree/master/packages/babel-preset-env) to transpile your code, then `const foo = () => {}` will be transpiled to `var foo = function foo () {}`. So if thats the case, you don't have to worry much about this. However, its still good to be aware of. You can read about this in more detail [here](https://github.com/airbnb/javascript/issues/794).

---

### Prop Destructuring

In the above examples, we just simply wrote `props` as our function parameter which allowed us to go pass in props like `props.name`. [Destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) is an ES6 feature and pairs nicely with stateless functional components. So, rather than declare props as our function parameter, lets destructure some props!

```jsx
export default function NormalFunction({ name, age }) {
 return (
 
 Greetings, {name}. I am {age} years old.
 
 );
}
```

Of course, we can do the same with arrow functions:

```jsx
const DestructuredArrow = ({ name, age }) => (
 
 Greetings, {name}. I am {age} years old
 
);

export default ArrowFunction;
```

This is great as it self documents the component and makes it clear as to what the component is expecting. The only caveat to this is that it can become ugly if you have a lot of props.

---

### Proptypes and Flow

A way to improve your components is by adding proptypes. With React, we can add types to our components to reduce errors and make sure our props are receiving the correct type of data.

Since React v15.5, [prop-types](https://github.com/facebook/prop-types) comes as a separate package that you'll need to install via yarn or npm. Implementing it is very simple, but make sure to check out the [documentation](https://reactjs.org/docs/typechecking-with-proptypes.html). 

[Flow](https://flow.org/en/) is another great tool which builds upon prop-types and adds additional power by informing you if you are misusing a component without actually running your code! 

+1 for Flow!

### prop-types
Here's how prop-types would look with our basic component:
```jsx
import PropTypes from 'prop-types';

export default function PropTypesExample({ name, age }) {
 return (
 
 Greetings, {name}. I am {age} years old.
 
 );
}

PropTypesExample.propTypes = {
 // You can chain `isRequired` to make sure a warning
 // is shown if the prop isn't provided.
 name: PropTypes.string.isRequired,
 age: PropTypes.string,
}
```

### Flow
Here's what Flow would look like, you can see its pretty similar to prop-types. The only downside to Flow is that it requires some additional set up to get running. Be sure to check out the [documentation](https://flow.org/en/docs/react/components/)!

```jsx
type Props = {
 name: string,
 age: string,
};

export default function FlowExample({ name, age }) {
 return (
 
 Greetings, {name}. I am {age} years old.
 
 );
}

```

---

### fin
So that about wraps up what I've discovered thus far with crafting stateless functional components. I'll be implementing a [codesandbox ](https://codesandbox.io) so that readers can play around with the examples I provided, so stay tuned for that. I am still learning quite a bit. If I made any errors, please mention them below in the comments! 

Thanks for reading!