mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-12-15 07:53:07 -05:00
Rename External subsections to avoid name collision
QubesOS/qubes-issues#4693
This commit is contained in:
Andrew David Wong
parent
d31c786942
commit
9ee193896b
14 changed files with 2 additions and 2 deletions
158
external/os-guides/windows/windows-tools.md
vendored
Normal file
158
external/os-guides/windows/windows-tools.md
vendored
Normal file
|
|
@ -0,0 +1,158 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Qubes Windows Tools
|
||||
permalink: /doc/windows-tools/
|
||||
redirect_from:
|
||||
- /doc/windows-appvms/
|
||||
- /en/doc/windows-appvms/
|
||||
- /doc/WindowsAppVms/
|
||||
- /wiki/WindowsAppVms/
|
||||
---
|
||||
|
||||
Qubes Windows Tools
|
||||
===================
|
||||
|
||||
Qubes Windows Tools are a set of programs and drivers that provide integration of Windows AppVMs with the rest of the Qubes system. Currently the following features are available for Windows VMs after installation of those tools:
|
||||
|
||||
- Seamless GUI mode that integrates apps windows onto the common Qubes trusted desktop
|
||||
- Support for [secure clipboard copy/paste](/doc/copy-paste/) between the Windows VM and other AppVMs
|
||||
- Support for [secure file exchange](/doc/copying-files/) between the Windows VM and other AppVMs
|
||||
- Support for qvm-run and generic qrexec for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
|
||||
- Xen PV drivers for Windows that increase performance compared to qemu emulated devices
|
||||
|
||||
Qubes Windows Tools are open source and are distributed under a GPL license.
|
||||
|
||||
NOTES:
|
||||
- Qubes Windows Tools are currently unmaintained
|
||||
- Currently only 64-bit versions of Windows 7 are supported by Qubes Windows Tools. Only emulated SVGA GPU is supported (although [there has been reports](https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA) on working GPU passthrough).
|
||||
- There is currently no audio support for Windows HVMs.
|
||||
- There is currently no USB pass-through support for Windows HVMs.
|
||||
- __This page documents the process of installing Qubes Windows Tools on versions up to R3.2.__. Installation on Qubes R4.0 is possible but is a work in progress and there are limitations/bugs (see [issue #3585](https://github.com/QubesOS/qubes-issues/issues/3585)).
|
||||
|
||||
|
||||
Installing Windows OS in a Qubes VM
|
||||
-----------------------------------
|
||||
|
||||
Please refer to [this page](/doc/windows-vm/) for instructions on how to install Windows in a Qubes VM.
|
||||
|
||||
NOTE: It is strongly suggested to enable autologon for any Windows HVMs that will have Qubes Tools installed. To do so, run `netplwiz` command from the `Win+R`/Start menu and uncheck the *Users must enter a user name and password to use this computer* option.
|
||||
|
||||
Installing Qubes guest tools in Windows 7 VMs
|
||||
---------------------------------------------
|
||||
|
||||
First, make sure that `qubes-windows-tools` is installed in your system:
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update qubes-windows-tools
|
||||
~~~
|
||||
|
||||
(If the above command does not work, it could be that the Qubes Tools are not in the stable repo yet. Try installing from the testing repo instead.)
|
||||
|
||||
You can also install the package from testing repositories, where we usually publish new versions first:
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
|
||||
~~~
|
||||
|
||||
This package brings the ISO with Qubes Windows Tools that is passed to the VM when `--install-windows-tools` is specified for the `qvm-start` command. Please note that none of this software ever runs in Dom0 or any other part of the system except for the Windows AppVM in which it is to be installed.
|
||||
|
||||
Before proceeding with the installation we need to disable Windows mechanism that allows only signed drivers to be installed, because currently (beta releases) the drivers we provide as part of the Windows Tools are not digitally signed with a publicly recognizable certificate. To do that:
|
||||
|
||||
- Start command prompt as Administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose "Run as administrator"
|
||||
- In the command prompt type `bcdedit /set testsigning on`
|
||||
- Reboot your Windows VM
|
||||
|
||||
In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even now, the fact that those drivers are not digitally signed, this doesn't affect security of the Windows VM in 'any' way. This is because the actual installation ISO (the `qubes-windows-tools-*.iso` file) is distributed as a signed RPM package and its signature is verified by the `qubes-dom0-update` utility once it's being installed in Dom0. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
|
||||
|
||||
To install the Qubes Windows Tools in a Windows VM one should start the VM passing the additional option `--install-windows-tools`:
|
||||
|
||||
~~~
|
||||
qvm-start lab-win7 --install-windows-tools
|
||||
~~~
|
||||
|
||||
Once the Windows VM boots, a CDROM should appear in the 'My Computer' menu (typically as `D:`) with a setup program in its main directory.
|
||||
|
||||
After successful installation, the Windows VM must be shut down and started again, possibly a couple of times.
|
||||
|
||||
Qubes will automatically detect the tools has been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using qvm-prefs command:
|
||||
|
||||
~~~
|
||||
qvm-prefs <your-appvm-name>
|
||||
~~~
|
||||
|
||||
NOTE: it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles is performed in an early boot phase when qrexec is not yet running, so timeout may occur with the default value. To change the property use this command in dom0:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s <vm-name> qrexec_timeout 300
|
||||
~~~
|
||||
|
||||
Using Windows AppVMs in seamless mode
|
||||
-------------------------------------
|
||||
|
||||
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the `-a` switch used here, which will auto-start the VM if it is not running):
|
||||
|
||||
~~~
|
||||
qvm-run -a my-win7-appvm explorer.exe
|
||||
~~~
|
||||
|
||||
 
|
||||
|
||||
Also, the inter-VM services work as usual -- e.g. to request opening a document or URL in the Windows AppVM from another VM:
|
||||
|
||||
~~~
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 roadmap.pptx
|
||||
~~~
|
||||
|
||||
~~~
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com
|
||||
~~~
|
||||
|
||||
... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
|
||||
|
||||
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don't provide a command line wrapper, `qvm-copy-to-vm` in Windows VMs) -- to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-\> Other AppVM.
|
||||
|
||||
To simulate CTRL-ALT-DELETE in the HVM (SAS, Secure Attention Sequence), press Ctrl-Alt-Home while having any window of this VM in the foreground.
|
||||
|
||||
|
||||
|
||||
Changing between seamless and full desktop mode
|
||||
-----------------------------------------------
|
||||
|
||||
You can switch between seamless and "full desktop" mode for Windows HVMs in their settings in Qubes Manager. The latter is the default.
|
||||
|
||||
Using template-based Windows AppVMs
|
||||
-----------------------------------
|
||||
|
||||
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just as for Linux AppVMs. This mode is not limited to Windows AppVMs, and can be used for any HVM (e.g. FreeBSD running in a HVM).
|
||||
|
||||
In order to create a HVM TemplateVM one can use the following command, suitably adapted:
|
||||
|
||||
~~~
|
||||
qvm-create --class TemplateVM win7-x64-template --property virt_mode=HVM --property kernel='' -l green
|
||||
~~~
|
||||
|
||||
... , set memory as appropriate, and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see instructions on [this page](/doc/hvm-create/).
|
||||
|
||||
If you use this Template as it is, then any HVMs that use it will effectively be DisposableVMs - the User directory will be wiped when the HVN is closed down.
|
||||
|
||||
If you want to retain the User directory between reboots, then it would make sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs.
|
||||
This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically.
|
||||
To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`.
|
||||
It's a selectable feature of the installer, enabled by default.
|
||||
If that feature is selected during installation, completion of the process requires two reboots:
|
||||
|
||||
- The private disk is initialized and formatted on the first reboot after tools installation. It can't be done **during** the installation because Xen mass storage drivers are not yet active.
|
||||
- User profiles are moved to the private disk on the next reboot after the private disk is initialized.
|
||||
Reboot is required because the "mover utility" runs very early in the boot process so OS can't yet lock any files in there.
|
||||
This can take some time depending on the profiles' size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot.
|
||||
That's a false alarm (you can increase AppVM's default boot timeout using `qvm-prefs`), the VM should appear "green" in Qubes Manager shortly after.
|
||||
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives).
|
||||
Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on it:
|
||||
|
||||
~~~
|
||||
qvm-create --hvm <new windows appvm name> --template <name of template vm> --label <label color>
|
||||
~~~
|
||||
|
||||
188
external/os-guides/windows/windows-vm.md
vendored
Normal file
188
external/os-guides/windows/windows-vm.md
vendored
Normal file
|
|
@ -0,0 +1,188 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Installing a Windows VM
|
||||
permalink: /doc/windows-vm/
|
||||
---
|
||||
|
||||
|
||||
Installing a Windows VM
|
||||
=======================
|
||||
|
||||
Qubes 4.0 - importing a Windows VM from R3.2
|
||||
-------------------------------------------
|
||||
|
||||
Importing should work, simply make sure that you are not using Xen's newer linux stubdomain and that the VM is in HVM mode (these steps should be done automatically when importing the VM):
|
||||
|
||||
~~~
|
||||
qvm-features VMNAME linux-stubdom ''
|
||||
qvm-prefs VMNAME virt_mode hvm
|
||||
~~~
|
||||
|
||||
Note however that you are better off creating a new Windows VM to benefit from the more recent emulated hardware: R3.2 uses a MiniOS based stubdomain with an old and mostly unmaintained 'qemu-traditional' while R4.0 uses a Linux based stubdomain with a recent version of upstream qemu (see [this post](https://groups.google.com/d/msg/qubes-devel/tBqwJmOAJ94/xmFCGJnuAwAJ)).
|
||||
|
||||
|
||||
Windows VM installation
|
||||
-----------------------
|
||||
|
||||
### Summary ###
|
||||
|
||||
~~~
|
||||
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
|
||||
qvm-prefs win7new memory 4096
|
||||
qvm-prefs win7new maxmem 4096
|
||||
qvm-prefs win7new kernel ''
|
||||
qvm-volume extend win7new:root 25g
|
||||
qvm-prefs win7new debug true
|
||||
qvm-features win7new video-model cirrus
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
|
||||
# restart after the first part of the windows installation process ends
|
||||
qvm-start win7new
|
||||
# once Windows is installed and working
|
||||
qvm-prefs win7new memory 2048
|
||||
qvm-prefs win7new maxmem 2048
|
||||
qvm-features --unset win7new video-model
|
||||
qvm-prefs win7new qrexec_timeout 300
|
||||
# with Qubes Windows Tools installed:
|
||||
qvm-prefs win7new debug false
|
||||
~~~
|
||||
|
||||
To install Qubes Windows Tools, follow instructions [below](#xen-pv-drivers-and-qubes-windows-tools).
|
||||
|
||||
### Detailed instructions ###
|
||||
|
||||
MS Windows versions considerations:
|
||||
|
||||
- The instructions *may* work on other versions than Windows 7 x64 but haven't been tested.
|
||||
- Qubes Windows Tools (QWT) only supports Windows 7 x64. Note that there are [known issues](https://github.com/QubesOS/qubes-issues/issues/3585) with QWT on Qubes 4.x
|
||||
|
||||
Create a VM named win7new in [HVM](/doc/hvm/) mode (Xen's current PVH limitations precludes from using PVH):
|
||||
|
||||
~~~
|
||||
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
|
||||
~~~
|
||||
|
||||
Windows' installer requires a significant amount of memory or else the VM will crash with such errors:
|
||||
|
||||
`/var/log/xen/console/hypervisor.log`:
|
||||
|
||||
> p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
|
||||
> (XEN) domain_crash called from p2m-pod.c:1218
|
||||
> (XEN) Domain 120 (vcpu#0) crashed on cpu#3:
|
||||
|
||||
So, increase the VM's memory to 4096MB (memory = maxmem because we don't use memory balancing).
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new memory 4096
|
||||
qvm-prefs win7new maxmem 4096
|
||||
~~~
|
||||
|
||||
Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence:
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new kernel ''
|
||||
~~~
|
||||
|
||||
A typical Windows 7 installation requires between 15GB up to 19GB of disk space depending on the version (Home/Professional/...). Windows updates also end up using significant space. So, extend the root volume from the default 10GB to 25GB (note: it is straightforward to increase the root volume size after Windows is installed: simply extend the volume again in dom0 and then extend the system partition with Windows's disk manager).
|
||||
|
||||
~~~
|
||||
qvm-volume extend win7new:root 25g
|
||||
~~~
|
||||
|
||||
Set the debug flag in order to have a graphical console:
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new debug true
|
||||
~~~
|
||||
|
||||
The second part of the installation process will crash with the standard VGA video adapter and the VM will stay in "transient" mode with the following error in `guest-win7new-dm.log`:
|
||||
|
||||
> qemu: /home/user/qubes-src/vmm-xen-stubdom-linux/build/qemu/exec.c:1187: cpu_physical_memory_snapshot_get_dirty: Assertion `start + length <= snap->end' failed.
|
||||
|
||||
To avoid that error we temporarily have to switch the video adapter to 'cirrus':
|
||||
|
||||
~~~
|
||||
qvm-features win7new video-model cirrus
|
||||
~~~
|
||||
|
||||
The VM is now ready to be started; the best practice is to use an installation ISO [located in a VM](/doc/hvm/#installing-an-os-in-an-hvm-domain):
|
||||
|
||||
~~~
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
|
||||
~~~
|
||||
|
||||
Given the higher than usual memory requirements of Windows, you may get a `Not enough memory to start domain 'win7new'` error. In that case try to shutdown unneeded VMs to free memory before starting the Windows VM.
|
||||
|
||||
At this point you may open a tab in dom0 for debugging, in case something goes amiss:
|
||||
|
||||
~~~
|
||||
tailf /var/log/qubes/vm-win7new.log \
|
||||
/var/log/xen/console/hypervisor.log \
|
||||
/var/log/xen/console/guest-win7new-dm.log
|
||||
~~~
|
||||
|
||||
The VM will shutdown after the installer completes the extraction of Windows installation files. It's a good idea to clone the VM now (eg. `qvm-clone win7new win7newbkp1`). Then, (re)start the VM with `qvm-start win7new`.
|
||||
|
||||
The second part of Windows' installer should then be able to complete successfully. You may then perform the following post-install steps:
|
||||
|
||||
Decrease the VM's memory to a more reasonable value (memory balancing on Windows is unstable so keep `memory` equal to `maxmen`).
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new memory 2048
|
||||
qvm-prefs win7new maxmem 2048
|
||||
~~~
|
||||
|
||||
Revert to the standard VGA adapter :
|
||||
|
||||
~~~
|
||||
qvm-features --unset win7new video-model
|
||||
~~~
|
||||
|
||||
Finally, increase the VM's `qrexec_timeout`: in case you happen to get a BSOD or a similar crash in the VM, utilities like chkdsk won't complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools' installation.
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new qrexec_timeout 300
|
||||
~~~
|
||||
|
||||
At that point you should have a functional and stable Windows VM, although without updates, Xen's PV drivers nor Qubes integration (see sections [Windows Update](#windows-update) and [Xen PV drivers and Qubes Windows Tools](#xen-pv-drivers-and-qubes-windows-tools) below). It is a good time to clone the VM again.
|
||||
|
||||
|
||||
Windows update
|
||||
--------------
|
||||
|
||||
Depending on how old your installation media is, fully updating your Windows VM may take *hours* (this isn't specific to Xen/Qubes) so make sure you clone your VM between the mandatory reboots in case something goes wrong. This [comment](https://github.com/QubesOS/qubes-issues/issues/3585#issuecomment-366471111) provides useful links on updating a Windows 7 SP1 VM.
|
||||
|
||||
Note: if you already have Qubes Windows Tools installed the video adapter in Windows will be "Qubes video driver" and you won't be able to see the Windows Update process when the VM is being powered off because Qubes services would have been stopped by then. Depending on the size of the Windows update packs it may take a bit of time until the VM shutdowns by itself, leaving one wondering if the VM has crashed or still finalizing the updates (in dom0 a changing CPU usage - eg. shown with `xentop` - usually indicates that the VM hasn't crashed).
|
||||
To avoid guessing the VM's state enable debugging (`qvm-prefs -s win7new debug true`) and in Windows' device manager (My computer -> Manage / Device manager / Display adapters) temporarily re-enable the standard VGA adapter and disable "Qubes video driver". You can disable debugging and revert to Qubes' display once the VM is updated.
|
||||
|
||||
|
||||
Xen PV drivers and Qubes Windows Tools
|
||||
------------------------------------
|
||||
|
||||
Installing Xen's PV drivers in the VM will lower its resources usage when using network and/or I/O intensive applications, but *may* come at the price of system stability (although Xen's PV drivers on a Win7 VM are usually very stable). There are two ways of installing the drivers:
|
||||
|
||||
1. installing the drivers independently, from Xen's [official site](https://www.xenproject.org/developers/teams/windows-pv-drivers.html)
|
||||
2. installing Qubes Windows Tools (QWT), which bundles Xen's PV drivers.
|
||||
|
||||
Notes about using Xen's VBD (storage) PV driver:
|
||||
- Windows 7: installing the driver requires a fully updated VM or else you'll likely get a BSOD and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn't much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn't have access to untrusted networks and if you don't use I/O intensive apps. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools (QWT). If QWT are installed, you should temporarily re-enable the standard VGA adapter in Windows and disable Qubes' (see the section above).
|
||||
- the option to install the storage PV driver is disabled by default in Qubes Windows Tools
|
||||
- in case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver from Xen's site (xenvbd.tar).
|
||||
|
||||
|
||||
Installing Qubes Windows Tools:
|
||||
- on R3.2: see [this page](/doc/windows-tools/)
|
||||
- R4.0: you'll have to install QWT for Qubes R3.2. Be warned that QWT on R4.0 is a work in progress though (see [issue #3585](https://github.com/QubesOS/qubes-issues/issues/3585) for instructions and known issues).
|
||||
|
||||
|
||||
With Qubes Windows Tools installed the early graphical console provided in debugging mode isn't needed anymore since Qubes' display driver will be used instead of the default VGA driver:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s win7new debug false
|
||||
~~~
|
||||
|
||||
|
||||
Further customization
|
||||
---------------------
|
||||
|
||||
Please see the [Customizing Windows 7 templates](/doc/windows-template-customization/) page (despite the focus on preparing the VM for use as a template, most of the instructions are independent from how the VM will be used - ie. TemplateVM or StandaloneVM).
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue