Skip to content

Add disk device usable for mounting ISO files in Windows installer #1688

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
foxtrotcz opened this issue Feb 23, 2025 · 1 comment
Closed

Comments

@foxtrotcz
Copy link
Contributor

foxtrotcz commented Feb 23, 2025

Currently to install Windows you need to repack it with Distrobuilder.

I propose adding method similar to how Proxmox does it. This means allowing user to mount ISO via device supported in Windows installer. User then installs vioscsi drivers from ISO and can continue installation on virtio-scsi disk. https://pve.proxmox.com/wiki/Windows_10_guest_best_practices

This would mean adding support for IDE or AHCI device. These are not hotpluggable so they would likely need separate handling from already established options. On the other hand these devices could be used for mounting Virtio ISO directly into Windows installer.

I tried to find any other method that would be hotpluggable and also work in Windows installer, but no luck.
Maybe XHCI controller with usb-bot or usb-uas devices that attach to SCSI device (scsi-hd, scsi-cd). But I am not sure if this works without virtio drivers.
https://qemu-project.gitlab.io/qemu/system/devices/usb.html

Thanks.

@stgraber
Copy link
Member

We're not going to be doing that, sorry. If you absolutely must, it can be done using a scriptlet which could be written in a way that's distributable to other folks (similar to what's being done to run MacOS or ESXi).

But we're not interested in having a completely different storage handling path inside of Incus (one without hotplug support) just to make it possible to start the Windows installer.

I think we'd be quite happy to have some high quality raw.qemu.scriptlet examples ship in our documentation though, which as mentioned could be used to handle those less supported situations.
As the use of any raw.* config keys makes the instance unsupported on our end and also limits it to full admin (can't be used in restricted projects), that's a method that comes without maintenance or support cost and without officially exposing attack surface we're uncomfortable with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants