Bottom line: Approve a host-and-guest GPU allocation map before isolating hardware. Keep the intended host device available, review any application dependency and schedule the documented reboot before checking the final assignment.
\nThe TrueNAS GPU isolation guide requires at least two GPUs: one for host functions and another available for VM isolation. An isolated GPU is unavailable to the host OS and applications, and one isolated device can be used by a single VM. After allocation to a VM, the GPU is unavailable for other allocations. The system must be rebooted after adding or removing a GPU from isolation to fully update its isolation status.
\nThis is the versioned TrueNAS isolation procedure, not a GPU compatibility list or a performance qualification for a guest workload. It does not establish driver support, application eligibility or migration behavior for any proposed device.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends an allocation sheet with separate host, application and VM rows. Record device identities rather than relying only on identical model names. Have the host and workload owners agree which device will remain available to the host before saving an isolation change.
\nReview existing application use and planned VM demand together. If two owners request the same device, resolve the allocation decision before the change window. Do not treat an isolated-device selection as a capacity plan for several simultaneous consumers.
\nSchedule the documented reboot as part of the same approved change. Preserve the original allocation and the method of returning the device to its prior role. Name the console or recovery access needed if the system does not return to the expected management state.
\nChoose a proposed harmless guest workload and a separate host-function check. Establish the required observations without assuming an application’s throughput or feature support. Keep any later driver installation or tuning in a separately reviewed step so the isolation result remains interpretable.
\nProposed verification: after the approved reboot, reconcile the effective isolation list and VM configuration with the allocation sheet. Confirm the intended host device remains assigned as planned, then exercise the agreed guest workload. Record the physical identities and actual observations from both sides.
\nReview the previously dependent applications through their approved checks, particularly any that were intentionally moved to another device. Preserve an unexpected missing allocation as a finding rather than assigning a second consumer experimentally. Accept the demonstrated device assignment separately from workload compatibility or sustained performance.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Approve a host-and-guest GPU allocation map before isolating hardware. Keep the intended host device available, review any application dependency and schedule the documented reboot before checking the final assignment.\nSource fact: what the authority says\nThe TrueNAS GPU isolation guide requires at least two GPUs: one for host functions and another available for VM isolation. An isolated GPU is unavailable to the host OS and applications, and one isolated device can be used by a single VM. After allocation to a VM, the GPU is unavailable for other allocations. The system must be rebooted after adding or removing a GPU from isolation to fully update its isolation status.\nWhat the source does not establish\nThis is the versioned TrueNAS isolation procedure, not a GPU compatibility list or a performance qualification for a guest workload. It does not establish driver support, application eligibility or migration behavior for any proposed device.\nApplicability questions\n\nWhich physical GPU remains assigned to host functions?\nWhich device is proposed for one VM, identified by its actual hardware identity?\nDoes an application currently rely on the proposed device?\nWho approves the reboot, workload checks and recovery assignment?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends an allocation sheet with separate host, application and VM rows. Record device identities rather than relying only on identical model names. Have the host and workload owners agree which device will remain available to the host before saving an isolation change.\nReview existing application use and planned VM demand together. If two owners request the same device, resolve the allocation decision before the change window. Do not treat an isolated-device selection as a capacity plan for several simultaneous consumers.\nSchedule the documented reboot as part of the same approved change. Preserve the original allocation and the method of returning the device to its prior role. Name the console or recovery access needed if the system does not return to the expected management state.\nChoose a proposed harmless guest workload and a separate host-function check. Establish the required observations without assuming an application’s throughput or feature support. Keep any later driver installation or tuning in a separately reviewed step so the isolation result remains interpretable.\nVerification and evidence\nProposed verification: after the approved reboot, reconcile the effective isolation list and VM configuration with the allocation sheet. Confirm the intended host device remains assigned as planned, then exercise the agreed guest workload. Record the physical identities and actual observations from both sides.\nReview the previously dependent applications through their approved checks, particularly any that were intentionally moved to another device. Preserve an unexpected missing allocation as a finding rather than assigning a second consumer experimentally. Accept the demonstrated device assignment separately from workload compatibility or sustained performance.\nOfficial references\n\nTrueNAS — Isolating GPU for VMs — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Approve a host-and-guest GPU allocation map before isolating hardware. Keep the intended host device available, review any application dependency and schedule the documented reboot before checking the final assignment.\n\n## Source fact: what the authority says\n\nThe [TrueNAS GPU isolation guide](https://www.truenas.com/docs/scale/25.10/scaletutorials/systemsettings/advanced/managegpuscale/) requires at least two GPUs: one for host functions and another available for VM isolation. An isolated GPU is unavailable to the host OS and applications, and one isolated device can be used by a single VM. After allocation to a VM, the GPU is unavailable for other allocations. The system must be rebooted after adding or removing a GPU from isolation to fully update its isolation status.\n\n## What the source does not establish\n\nThis is the versioned TrueNAS isolation procedure, not a GPU compatibility list or a performance qualification for a guest workload. It does not establish driver support, application eligibility or migration behavior for any proposed device.\n\n## Applicability questions\n\n- Which physical GPU remains assigned to host functions?\n\n- Which device is proposed for one VM, identified by its actual hardware identity?\n\n- Does an application currently rely on the proposed device?\n\n- Who approves the reboot, workload checks and recovery assignment?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends an allocation sheet with separate host, application and VM rows. Record device identities rather than relying only on identical model names. Have the host and workload owners agree which device will remain available to the host before saving an isolation change.\n\nReview existing application use and planned VM demand together. If two owners request the same device, resolve the allocation decision before the change window. Do not treat an isolated-device selection as a capacity plan for several simultaneous consumers.\n\nSchedule the documented reboot as part of the same approved change. Preserve the original allocation and the method of returning the device to its prior role. Name the console or recovery access needed if the system does not return to the expected management state.\n\nChoose a proposed harmless guest workload and a separate host-function check. Establish the required observations without assuming an application’s throughput or feature support. Keep any later driver installation or tuning in a separately reviewed step so the isolation result remains interpretable.\n\n## Verification and evidence\n\nProposed verification: after the approved reboot, reconcile the effective isolation list and VM configuration with the allocation sheet. Confirm the intended host device remains assigned as planned, then exercise the agreed guest workload. Record the physical identities and actual observations from both sides.\n\nReview the previously dependent applications through their approved checks, particularly any that were intentionally moved to another device. Preserve an unexpected missing allocation as a finding rather than assigning a second consumer experimentally. Accept the demonstrated device assignment separately from workload compatibility or sustained performance.\n\n## Official references\n\n- [TrueNAS — Isolating GPU for VMs](https://www.truenas.com/docs/scale/25.10/scaletutorials/systemsettings/advanced/managegpuscale/) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/", "url": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Keep a TrueNAS host GPU when isolating devices for a VM", "item": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/#article", "identifier": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/", "url": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/", "headline": "Keep a TrueNAS host GPU when isolating devices for a VM", "description": "Inventory host, VM and application GPU use before isolating a device under the TrueNAS 25.10 procedure.", "abstract": "Inventory host, VM and application GPU use before isolating a device under the TrueNAS 25.10 procedure.", "articleBody": "Bottom line: Approve a host-and-guest GPU allocation map before isolating hardware. Keep the intended host device available, review any application dependency and schedule the documented reboot before checking the final assignment.\nSource fact: what the authority says\nThe TrueNAS GPU isolation guide requires at least two GPUs: one for host functions and another available for VM isolation. An isolated GPU is unavailable to the host OS and applications, and one isolated device can be used by a single VM. After allocation to a VM, the GPU is unavailable for other allocations. The system must be rebooted after adding or removing a GPU from isolation to fully update its isolation status.\nWhat the source does not establish\nThis is the versioned TrueNAS isolation procedure, not a GPU compatibility list or a performance qualification for a guest workload. It does not establish driver support, application eligibility or migration behavior for any proposed device.\nApplicability questions\n\nWhich physical GPU remains assigned to host functions?\nWhich device is proposed for one VM, identified by its actual hardware identity?\nDoes an application currently rely on the proposed device?\nWho approves the reboot, workload checks and recovery assignment?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends an allocation sheet with separate host, application and VM rows. Record device identities rather than relying only on identical model names. Have the host and workload owners agree which device will remain available to the host before saving an isolation change.\nReview existing application use and planned VM demand together. If two owners request the same device, resolve the allocation decision before the change window. Do not treat an isolated-device selection as a capacity plan for several simultaneous consumers.\nSchedule the documented reboot as part of the same approved change. Preserve the original allocation and the method of returning the device to its prior role. Name the console or recovery access needed if the system does not return to the expected management state.\nChoose a proposed harmless guest workload and a separate host-function check. Establish the required observations without assuming an application’s throughput or feature support. Keep any later driver installation or tuning in a separately reviewed step so the isolation result remains interpretable.\nVerification and evidence\nProposed verification: after the approved reboot, reconcile the effective isolation list and VM configuration with the allocation sheet. Confirm the intended host device remains assigned as planned, then exercise the agreed guest workload. Record the physical identities and actual observations from both sides.\nReview the previously dependent applications through their approved checks, particularly any that were intentionally moved to another device. Preserve an unexpected missing allocation as a finding rather than assigning a second consumer experimentally. Accept the demonstrated device assignment separately from workload compatibility or sustained performance.\nOfficial references\n\nTrueNAS — Isolating GPU for VMs — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:41:04+00:00", "dateModified": "2026-10-29T17:41:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/keep-a-truenas-host-gpu-when-isolating-devices-for-a-vm/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Keep a TrueNAS host GPU when isolating devices for a VM" }, "articleSection": [ "Networks & Infrastructure" ], "keywords": [ "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 497, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "TrueNAS — Isolating GPU for VMs", "url": "https://www.truenas.com/docs/scale/25.10/scaletutorials/systemsettings/advanced/managegpuscale/" } } ] } }