mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-28 08:49:42 -05:00
Merge branch 'master' of https://github.com/taradiddles/qubes-doc into taradiddles-master
This commit is contained in:
Andrew David Wong
commit
a833f749ea
@ -10,38 +10,30 @@ redirect_from:
|
||||
---
|
||||
|
||||
Creating and using HVM (fully virtualized) domains
|
||||
=============================================================
|
||||
==================================================
|
||||
|
||||
What are HVM domains?
|
||||
---------------------
|
||||
|
||||
HVM domains (Hardware VM), in contrast to PV domains (Paravirtualized domains), allow one to create domains based on any OS for which one has an installation ISO. For example, this allows one to have Windows-based VMs in Qubes.
|
||||
|
||||
Interested readers might want to check
|
||||
[this article](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html)
|
||||
to learn why it took so long for Qubes OS to support HVM domains
|
||||
(Qubes 1 only supported Linux based PV domains). As of
|
||||
Qubes 4, every VM is PVH by default, except those with attached PCI devices which are HVM.
|
||||
[See here](https://blog.invisiblethings.org/2017/07/31/qubes-40-rc1.html) for a discussion
|
||||
of the switch to HVM from R3.2's PV, and [here](/news/2018/01/11/qsb-37/)
|
||||
for changing the default to PVH.
|
||||
Interested readers might want to check [this article](https://blog.invisiblethings.org/2012/03/03/windows-support-coming-to-qubes.html) to learn why it took so long for Qubes OS to support HVM domains (Qubes 1 only supported Linux based PV domains). As of Qubes 4, every VM is PVH by default, except those with attached PCI devices which are HVM. [See here](https://blog.invisiblethings.org/2017/07/31/qubes-40-rc1.html) for a discussion of the switch to HVM from R3.2's PV, and [here](/news/2018/01/11/qsb-37/) for changing the default to PVH.
|
||||
|
||||
Creating an HVM domain
|
||||
----------------------
|
||||
|
||||
First, let's create a new HVM domain. Use the `--hvm` switch to `qvm-create`, or choose HVM type in the Qubes Manager VM creation dialog box:
|
||||
With a GUI: in Qubes Manager VM creation dialog box choose the "Standalone qube not based on a template" type. If "install system from device" is selected (which is by default), then `virt_mode` will be set to `hvm` automatically. Otherwise, open the newly created VM's Qube Settings GUI and in the "Advanced" tab select "HVM" in the virtualization mode drop-down list.
|
||||
|
||||
Command line (the VM's name and label color are for illustration purposes):
|
||||
|
||||
R3.2:
|
||||
~~~
|
||||
qvm-create win7 --hvm --label green
|
||||
qvm-create my-new-vm --hvm --label green
|
||||
~~~
|
||||
|
||||
The name of the domain ("win7") as well as its label ("green") are just exemplary of course.
|
||||
|
||||
**Note:** To create a StandaloneVM in Qubes R4, use the --class option, as VMs are template-based by default
|
||||
|
||||
R4.0: VMs are template-based by default so the `--class StandaloneVM` option is needed to create a StandaloneVM:
|
||||
~~~
|
||||
qvm-create win7 --class StandaloneVM --property virt_mode=hvm --property kernel="" --property memory=4096 --property maxmem=4096 --property debug=True --label green
|
||||
qvm-features win7 video-model cirrus
|
||||
qvm-create my-new-vm --class StandaloneVM --property virt_mode=hvm
|
||||
~~~
|
||||
|
||||
If you receive an error like this one, then you must first enable VT-x in your BIOS:
|
||||
@ -50,45 +42,165 @@ If you receive an error like this one, then you must first enable VT-x in your B
|
||||
libvirt.libvirtError: invalid argument: could not find capabilities for arch=x86_64
|
||||
~~~
|
||||
|
||||
Now we need to install an OS inside this VM. This can be done by attaching an installation ISO to and starting the VM (this can currently only be done from command line, but in the future we will surely add an option to do this also from the manager):
|
||||
Installing an OS in an HVM domain
|
||||
---------------------------------
|
||||
|
||||
You will have to boot the VM with the installation media "attached" to it. You may either use the GUI or command line instructions. That can be accomplished in three ways:
|
||||
|
||||
1. If you have the physical cdrom media and a disk drive
|
||||
~~~
|
||||
qvm-start my-new-vm --cdrom=/dev/cdrom
|
||||
~~~
|
||||
2. If you have an ISO image of the installation media located in dom0
|
||||
~~~
|
||||
qvm-start my-new-vm --cdrom=dom0:/usr/local/iso/installcd.iso
|
||||
~~~
|
||||
3. If you have an ISO image of the installation media located in a VM (obviously the VM where the media is located must be running)
|
||||
~~~
|
||||
qvm-start my-new-vm --cdrom=someVM:/home/user/installcd.iso
|
||||
~~~
|
||||
|
||||
For security reasons you should *never* copy untrusted data to dom0. Qubes doesn't provide any easy to use mechanism for copying files between VMs and Dom0 anyway and generally tries to discourage such actions.
|
||||
|
||||
Next, the VM will start booting from the attached installation media. Depending on the OS being installed in the VM, one might be required to start the VM several times (as is the case with Windows 7 installations) because whenever the installer wants to "reboot the system" it actually shuts down the VM and Qubes won't automatically start it. Several invocations of `qvm-start` command (as shown above) might be needed.
|
||||
|
||||
Setting up networking for HVM domains
|
||||
-------------------------------------
|
||||
|
||||
Just like standard paravirtualized AppVMs, the HVM domains get fixed IP addresses centrally assigned by Qubes. Normally Qubes agent scripts (or services on Windows) running within each AppVM are responsible for setting up networking within the VM according the configuration created by Qubes (through [keys](/doc/vm-interface/#qubesdb) exposed by dom0 to the VM). Such centrally managed networking infrastructure allows for [advanced networking configuration](https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html).
|
||||
|
||||
A generic HVM domain such as a standard Windows or Ubuntu installation, however, has no Qubes agent scripts running inside it initially and thus requires manual networking configuration so that it match the values assigned by Qubes for this domain.
|
||||
|
||||
Even though we do have a small DHCP server that runs inside HVM untrusted stub domain to make the manual network configuration not necessary for many VMs, this won't work for most modern Linux distributions which contain Xen networking PV drivers (but not Qubes tools) built in which bypass the stub-domain networking (their net frontends connect directly to the net backend in the netvm). In this instance our DHCP server is not useful.
|
||||
|
||||
In order to manually configure networking in a VM, one should first find out the IP/netmask/gateway assigned to the particular VM by Qubes. This can be seen e.g. in the Qubes Manager in the VM's properties:
|
||||
|
||||
|
||||
|
||||
Alternatively, one can use the `qvm-ls -n` command to obtain the same information and configure the networking within the HVM according to those settings (IP/netmask/gateway).
|
||||
|
||||
DNS servers: in R3.2 the DNS addresses are the same as the gateway's IP. In R4.0, the DNS ips are `10.139.1.1` and `10.139.1.2`.
|
||||
|
||||
Qubes R3.2 only supports IPv4. Qubes R4.0 has [opt-in support](https://www.qubes-os.org/doc/networking/#ipv6) for IPv6 forwarding.
|
||||
|
||||
Using Template-based HVM domains
|
||||
--------------------------------
|
||||
|
||||
Please see our dedicated page on [installing and using Windows-based AppVMs](/doc/windows-appvms/).
|
||||
|
||||
Cloning HVM domains
|
||||
-------------------
|
||||
|
||||
Just like normal AppVMs, the HVM domains can also be cloned either using a command-line `qvm-clone` command or via manager's 'Clone VM' option in the right-click menu.
|
||||
|
||||
The cloned VM will get identical root and private images and will essentially be identical to the original VM except that it will get a different MAC address for the networking interface:
|
||||
|
||||
~~~
|
||||
qvm-start win7 --cdrom=DispVM:/home/user/win7.iso
|
||||
or
|
||||
qvm-start win7 --cdrom=dom0:/usr/local/iso/win7_en.iso
|
||||
[joanna@dom0 ~]$ qvm-prefs my-new-vm
|
||||
name : my-new-vm
|
||||
label : green
|
||||
type : HVM
|
||||
netvm : firewallvm
|
||||
updateable? : True
|
||||
installed by RPM? : False
|
||||
include in backups: False
|
||||
dir : /var/lib/qubes/appvms/my-new-vm
|
||||
config : /var/lib/qubes/appvms/my-new-vm/my-new-vm.conf
|
||||
pcidevs : []
|
||||
root img : /var/lib/qubes/appvms/my-new-vm/root.img
|
||||
private img : /var/lib/qubes/appvms/my-new-vm/private.img
|
||||
vcpus : 4
|
||||
memory : 512
|
||||
maxmem : 512
|
||||
MAC : 00:16:3E:5E:6C:05 (auto)
|
||||
debug : off
|
||||
default user : user
|
||||
qrexec_installed : False
|
||||
qrexec timeout : 60
|
||||
drive : None
|
||||
timezone : localtime
|
||||
|
||||
[joanna@dom0 ~]$ qvm-clone my-new-vm my-new-vm-copy
|
||||
|
||||
/.../
|
||||
|
||||
[joanna@dom0 ~]$ qvm-prefs my-new-vm-copy
|
||||
name : my-new-vm-copy
|
||||
label : green
|
||||
type : HVM
|
||||
netvm : firewallvm
|
||||
updateable? : True
|
||||
installed by RPM? : False
|
||||
include in backups: False
|
||||
dir : /var/lib/qubes/appvms/my-new-vm-copy
|
||||
config : /var/lib/qubes/appvms/my-new-vm-copy/my-new-vm-copy.conf
|
||||
pcidevs : []
|
||||
root img : /var/lib/qubes/appvms/my-new-vm-copy/root.img
|
||||
private img : /var/lib/qubes/appvms/my-new-vm-copy/private.img
|
||||
vcpus : 4
|
||||
memory : 512
|
||||
maxmem : 512
|
||||
MAC : 00:16:3E:5E:6C:01 (auto)
|
||||
debug : off
|
||||
default user : user
|
||||
qrexec_installed : False
|
||||
qrexec timeout : 60
|
||||
drive : None
|
||||
timezone : localtime
|
||||
~~~
|
||||
|
||||
The above first command assumes the installation ISO was transferred to a DispVM (copied using `dd` command from an installation CDROM for example). The second is for when the iso is in Dom0, which is not recommended. If one wishes to use the actual physical media without copying it first to a file, then one can just pass `/dev/cdrom` as an argument to `--cdrom`:
|
||||
Note how the MAC addresses differ between those two otherwise identical VMs. The IP addresses assigned by Qubes will also be different of course to allow networking to function properly:
|
||||
|
||||
~~~
|
||||
qvm-start win7 --cdrom=/dev/cdrom
|
||||
[joanna@dom0 ~]$ qvm-ls -n
|
||||
/.../
|
||||
my-new-vm-copy | | Halted | Yes | | *firewallvm | green | 10.137.2.3 | n/a | 10.137.2.1 |
|
||||
my-new-vm | | Halted | Yes | | *firewallvm | green | 10.137.2.7 | n/a | 10.137.2.1 |
|
||||
/.../
|
||||
~~~
|
||||
|
||||
Next, the VM will start booting from the attached CDROM device (which in the example above just happens to be a Windows 7 installation disk). Depending on the OS being installed in the VM, one might be required to start the VM several times (as is the case with Windows 7 installations), because whenever the installer wants to "reboot the system" it actually shuts down the VM and Qubes won't automatically start it. Several invocations of qvm-start command (as shown above) might be needed.
|
||||
|
||||
**Note:** If your Windows installation gets stuck at the glowing Windows logo, you might want to read [Issue 2488](https://github.com/QubesOS/qubes-issues/issues/2488) for a solution.
|
||||
|
||||
[](/attachment/wiki/HvmCreate/r2b1-win7-installing.png)
|
||||
|
||||
Using Installation ISOs located in other VMs
|
||||
--------------------------------------------
|
||||
|
||||
Sometimes one wants to download the installation ISO from the Web and use it for HVM creation. For security reasons, networking is disabled for Qubes Dom0, which makes it impossible to download an ISO within Dom0. Qubes also does not provide any easy to use mechanisms for copying files between AppVMs and Dom0 and generally tries to discourage such actions. Due to these factors it would be inconvenient to require that the installation ISO for an HVM domain be always located in Dom0. The good news, however, is that this is indeed not required. One can use the following syntax when specifying the location of an installation ISO (such as the Windows 7 installation ISO):
|
||||
If for any reason one would like to make sure that the two VMs have the same MAC address, one can use qvm-prefs to set a fixed MAC address for the VM:
|
||||
|
||||
~~~
|
||||
--cdrom=[appvm]:[/path/to/iso/within/appvm]
|
||||
[joanna@dom0 ~]$ qvm-prefs my-new-vm-copy -s mac 00:16:3E:5E:6C:05
|
||||
[joanna@dom0 ~]$ qvm-prefs my-new-vm-copy
|
||||
name : my-new-vm-copy
|
||||
label : green
|
||||
type : HVM
|
||||
netvm : firewallvm
|
||||
updateable? : True
|
||||
installed by RPM? : False
|
||||
include in backups: False
|
||||
dir : /var/lib/qubes/appvms/my-new-vm-copy
|
||||
config : /var/lib/qubes/appvms/my-new-vm-copy/my-new-vm-copy.conf
|
||||
pcidevs : []
|
||||
root img : /var/lib/qubes/appvms/my-new-vm-copy/root.img
|
||||
private img : /var/lib/qubes/appvms/my-new-vm-copy/private.img
|
||||
vcpus : 4
|
||||
memory : 512
|
||||
maxmem : 512
|
||||
MAC : 00:16:3E:5E:6C:05
|
||||
debug : off
|
||||
default user : user
|
||||
qrexec_installed : False
|
||||
qrexec timeout : 60
|
||||
drive : None
|
||||
timezone : localtime
|
||||
~~~
|
||||
|
||||
Assuming that an installation ISO named `ubuntu-12.10-desktop-i386.iso` has been downloaded in `work-web` AppVM and is located within the `/home/user/Downloads` directory within this AppVM, one can immediately create a new HVM using this ISO as an installation media with the following command issued in Dom0:
|
||||
Installing Qubes support tools in Windows 7 VMs
|
||||
-----------------------------------------------
|
||||
|
||||
~~~
|
||||
qvm-create --hvm ubuntu --label red
|
||||
qvm-start ubuntu --cdrom=work-web:/home/user/Downloads/ubuntu-12.10-desktop-i386.iso
|
||||
~~~
|
||||
Windows specific steps are described on [separate page](/doc/windows-appvms/).
|
||||
|
||||
The AppVM where the ISO is kept must be running for this to work as this VM is now serving the ISO and acting as a disk backend.
|
||||
Assigning PCI devices to HVM domains
|
||||
------------------------------------
|
||||
|
||||
|
||||
HVM domains (including Windows VMs) can be [assigned PCI devices](/doc/assigning-devices/) just like normal AppVMs. E.g. one can assign one of the USB controllers to the Windows VM and should be able to use various devices that require Windows software, such as phones, electronic devices that are configured via FTDI, etc.
|
||||
|
||||
One problem at the moment however, is that after the whole system gets suspended into S3 sleep and subsequently resumed, some attached devices may stop working and should be restarted within the VM. This can be achieved under a Windows HVM by opening the Device Manager, selecting the actual device (such as a USB controller), 'Disabling' the device, and then 'Enabling' the device again. This is illustrated on the screenshot below:
|
||||
|
||||
|
||||
|
||||
Converting VirtualBox VM to HVM
|
||||
-------------------------------
|
||||
@ -121,16 +233,16 @@ Convert vmdk to raw:
|
||||
qemu-img convert -O raw *.vmdk win10.raw
|
||||
~~~
|
||||
|
||||
Create new HVM in Dom0, with amount of RAM in MB you wish:
|
||||
Copy the root image file to a temporary location in Dom0:
|
||||
|
||||
~~~
|
||||
qvm-create --hvm win10 --label red --mem=4096
|
||||
qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10-root.img
|
||||
~~~
|
||||
|
||||
Copy file to Dom0:
|
||||
Create a new HVM in Dom0 with the root image we just copied to Dom0 (change the amount of RAM in GB as you wish):
|
||||
|
||||
~~~
|
||||
qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /var/lib/qubes/appvms/win10/root.img
|
||||
qvm-create --hvm win10 --label red --mem=4096 --root-move-from /home/user/win10-root.img
|
||||
~~~
|
||||
|
||||
Start win10 VM:
|
||||
@ -159,147 +271,11 @@ List filetypes supported by qemu-img:
|
||||
qemu-img -h | tail -n1
|
||||
~~~
|
||||
|
||||
Setting up networking for HVM domains
|
||||
-------------------------------------
|
||||
|
||||
Just like standard paravirtualized AppVMs, the HVM domains get fixed IP addresses centrally assigned by Qubes. Normally Qubes agent scripts running within each AppVM are responsible for setting up networking within the VM according the configuration created by Qubes. Such centrally managed networking infrastructure allows for [advanced networking configuration](https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html).
|
||||
|
||||
A generic HVM domain such as a standard Windows or Ubuntu installation, however, has no Qubes agent scripts running inside it initially and thus requires manual networking configuration so that it match the values assigned by Qubes for this domain.
|
||||
|
||||
Even though we do have a small DHCP server that runs inside HVM untrusted stub domain to make the manual network configuration not necessary for many VMs, this won't work for most modern Linux distributions which contain Xen networking PV drivers (but not Qubes tools) built in which bypass the stub-domain networking (their net frontends connect directly to the net backend in the netvm). In this instance our DHCP server is not useful.
|
||||
|
||||
In order to manually configure networking in a VM, one should first find out the IP/netmask/gateway assigned to the particular VM by Qubes. This can be seen e.g. in the Qubes Manager in the VM's properties:
|
||||
|
||||
|
||||
|
||||
Alternatively, one can use `qvm-ls -n` command to obtain the same information. One should configure the networking within the HVM according to those settings (IP/netmask/gateway). One should set DNS addresses to the same IP as gateway.
|
||||
|
||||
Only IPv4 networking is currently supported in Qubes.
|
||||
|
||||
**Note:** If one plans on installing Qubes Tools for Windows guests (see below) it is 'not' necessary to configure networking manually as described in this section, because the tools will take care of setting the networking automatically for such Windows domains.
|
||||
|
||||
Using Template-based HVM domains
|
||||
--------------------------------
|
||||
|
||||
Please see our dedicated page on [installing and using Windows-based AppVMs](/doc/windows-appvms/).
|
||||
|
||||
Cloning HVM domains
|
||||
-------------------
|
||||
|
||||
Just like normal AppVMs, the HVM domains can also be cloned either using a command-line `qvm-clone` command or via manager's 'Clone VM' option in the right-click menu.
|
||||
|
||||
The cloned VM will get identical root and private images and will essentially be identical to the original VM except that it will get a different MAC address for the networking interface:
|
||||
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-prefs win7
|
||||
name : win7
|
||||
label : green
|
||||
type : HVM
|
||||
netvm : firewallvm
|
||||
updateable? : True
|
||||
installed by RPM? : False
|
||||
include in backups: False
|
||||
dir : /var/lib/qubes/appvms/win7
|
||||
config : /var/lib/qubes/appvms/win7/win7.conf
|
||||
pcidevs : []
|
||||
root img : /var/lib/qubes/appvms/win7/root.img
|
||||
private img : /var/lib/qubes/appvms/win7/private.img
|
||||
vcpus : 4
|
||||
memory : 512
|
||||
maxmem : 512
|
||||
MAC : 00:16:3E:5E:6C:05 (auto)
|
||||
debug : off
|
||||
default user : user
|
||||
qrexec_installed : False
|
||||
qrexec timeout : 60
|
||||
drive : None
|
||||
timezone : localtime
|
||||
|
||||
[joanna@dom0 ~]$ qvm-clone win7 win7-copy
|
||||
|
||||
/.../
|
||||
|
||||
[joanna@dom0 ~]$ qvm-prefs win7-copy
|
||||
name : win7-copy
|
||||
label : green
|
||||
type : HVM
|
||||
netvm : firewallvm
|
||||
updateable? : True
|
||||
installed by RPM? : False
|
||||
include in backups: False
|
||||
dir : /var/lib/qubes/appvms/win7-copy
|
||||
config : /var/lib/qubes/appvms/win7-copy/win7-copy.conf
|
||||
pcidevs : []
|
||||
root img : /var/lib/qubes/appvms/win7-copy/root.img
|
||||
private img : /var/lib/qubes/appvms/win7-copy/private.img
|
||||
vcpus : 4
|
||||
memory : 512
|
||||
maxmem : 512
|
||||
MAC : 00:16:3E:5E:6C:01 (auto)
|
||||
debug : off
|
||||
default user : user
|
||||
qrexec_installed : False
|
||||
qrexec timeout : 60
|
||||
drive : None
|
||||
timezone : localtime
|
||||
~~~
|
||||
|
||||
Note how the MAC addresses differ between those two otherwise identical VMs. The IP addresses assigned by Qubes will also be different of course to allow networking to function properly:
|
||||
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-ls -n
|
||||
/.../
|
||||
win7-copy | | Halted | Yes | | *firewallvm | green | 10.137.2.3 | n/a | 10.137.2.1 |
|
||||
win7 | | Halted | Yes | | *firewallvm | green | 10.137.2.7 | n/a | 10.137.2.1 |
|
||||
/.../
|
||||
~~~
|
||||
|
||||
If for any reason one would like to make sure that the two VMs have the same MAC address, one can use qvm-prefs to set a fixed MAC address for the VM:
|
||||
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-prefs win7-copy -s mac 00:16:3E:5E:6C:05
|
||||
[joanna@dom0 ~]$ qvm-prefs win7-copy
|
||||
name : win7-copy
|
||||
label : green
|
||||
type : HVM
|
||||
netvm : firewallvm
|
||||
updateable? : True
|
||||
installed by RPM? : False
|
||||
include in backups: False
|
||||
dir : /var/lib/qubes/appvms/win7-copy
|
||||
config : /var/lib/qubes/appvms/win7-copy/win7-copy.conf
|
||||
pcidevs : []
|
||||
root img : /var/lib/qubes/appvms/win7-copy/root.img
|
||||
private img : /var/lib/qubes/appvms/win7-copy/private.img
|
||||
vcpus : 4
|
||||
memory : 512
|
||||
maxmem : 512
|
||||
MAC : 00:16:3E:5E:6C:05
|
||||
debug : off
|
||||
default user : user
|
||||
qrexec_installed : False
|
||||
qrexec timeout : 60
|
||||
drive : None
|
||||
timezone : localtime
|
||||
~~~
|
||||
|
||||
Installing Qubes support tools in Windows 7 VMs
|
||||
-----------------------------------------------
|
||||
|
||||
Windows specific steps are described on [separate page](/doc/windows-appvms/).
|
||||
|
||||
Assigning PCI devices to HVM domains
|
||||
------------------------------------
|
||||
|
||||
HVM domains (including Windows VMs) can be [assigned PCI devices](/doc/assigning-devices/) just like normal AppVMs. E.g. one can assign one of the USB controllers to the Windows VM and should be able to use various devices that require Windows software, such as phones, electronic devices that are configured via FTDI, etc.
|
||||
|
||||
One problem at the moment however, is that after the whole system gets suspended into S3 sleep and subsequently resumed, some attached devices may stop working and should be restarted within the VM. This can be achieved under a Windows HVM by opening the Device Manager, selecting the actual device (such as a USB controller), 'Disabling' the device, and then 'Enabling' the device again. This is illustrated on the screenshot below:
|
||||
|
||||
[](/attachment/wiki/HvmCreate/r2b1-win7-usb-disable.png)
|
||||
|
||||
Further reading
|
||||
---------------
|
||||
|
||||
Other documents related to HVM:
|
||||
|
||||
- [Windows VMs](/doc/windows-vm/)
|
||||
- [LinuxHVMTips](/doc/linux-hvm-tips/)
|
||||
|
||||
@ -7,10 +7,18 @@ permalink: /doc/windows/
|
||||
Windows VMs in Qubes OS
|
||||
=======================
|
||||
|
||||
Like any other unmodified OSes, Windows can be installed in Qubes as an [HVM](/doc/hvm/) domain.
|
||||
|
||||
Qubes Windows Tools are then usually installed to provide integration with the rest of the Qubes system; they also include Xen's paravirtualized (PV) drivers to increase performance compared to qemu emulated devices. Alternatively, only Xen's PV drivers can be installed if integration with Qubes isn't required or if the tools aren't supported on a give version of Windows. In the latter case, one would have to [enable inter-VM networking](https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes) to be able to exchange files with HVMs.
|
||||
|
||||
|
||||
For more information about Windows VMs in Qubes OS, please see the specific guides below:
|
||||
|
||||
* [Installing and Using Windows-based AppVMs (Qubes R2 Beta 3 and later)](/doc/windows-appvms/)
|
||||
* [Installing and Using Windows-based VMs](/doc/windows-vm/)
|
||||
* [Installing and Using Qubes Windows Tools (Qubes R2 Beta 3 up to R3.2)](/doc/windows-tools/)
|
||||
* [Issue #3585 - Installation and know limitations of Qubes Windows Tools in Qubes R4.0](https://github.com/QubesOS/qubes-issues/issues/3585)
|
||||
* [Advanced options and troubleshooting of Qubes Tools for Windows (R3)](/doc/windows-tools-3/)
|
||||
* [Advanced options and troubleshooting of Qubes Tools for Windows (R2)](/doc/windows-tools-2/)
|
||||
* [Uninstalling Qubes Tools for Windows 2.x](/doc/uninstalling-windows-tools-2/)
|
||||
* [Creating and Using HVM and Windows Domains](/doc/hvm/)
|
||||
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ Qubes Windows Tools: advanced settings and troubleshooting
|
||||
==========================================================
|
||||
|
||||
**This document only applies to Qubes R2 (tools version 2.x)**
|
||||
*Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.*
|
||||
*Only 64-bit Windows 7 (any edition) is supported currently.*
|
||||
|
||||
Installable components
|
||||
----------------------
|
||||
|
||||
@ -13,7 +13,7 @@ Qubes Windows Tools: advanced settings and troubleshooting
|
||||
==========================================================
|
||||
|
||||
**This document only applies to Qubes R3 (tools version 3.x)**
|
||||
*Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.*
|
||||
*Only 64-bit Windows 7 (any edition) is supported currently.*
|
||||
|
||||
Installable components
|
||||
----------------------
|
||||
|
||||
@ -1,17 +1,16 @@
|
||||
---
|
||||
layout: doc
|
||||
title: Windows AppVms
|
||||
permalink: /doc/windows-appvms/
|
||||
title: Qubes Windows Tools
|
||||
permalink: /doc/windows-tools/
|
||||
redirect_from:
|
||||
- /doc/windows-appvms/
|
||||
- /en/doc/windows-appvms/
|
||||
- /doc/WindowsAppVms/
|
||||
- /wiki/WindowsAppVms/
|
||||
---
|
||||
|
||||
Installing and using Windows-based AppVMs
|
||||
=========================================
|
||||
|
||||
Qubes provides special support for running Windows-based AppVMs. This requires the user to install Windows 7 x64 in a Qubes VM and subsequently install Qubes Windows Tools inside the VM (support for Windows 8+ is in development). This page describes this process in detail.
|
||||
What are 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:
|
||||
|
||||
@ -23,12 +22,16 @@ Qubes Windows Tools are a set of programs and drivers that provide integration o
|
||||
|
||||
Qubes Windows Tools are open source and are distributed under a GPL license.
|
||||
|
||||
NOTE: 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 pass-through). There is currently no audio support for Windows HVMs.
|
||||
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 pass-through). There is currently no audio 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/hvm-create/) for instructions on how to install Windows 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.
|
||||
|
||||
309
managing-os/windows/windows-vm.md
Normal file
309
managing-os/windows/windows-vm.md
Normal file
@ -0,0 +1,309 @@
|
||||
---
|
||||
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)).
|
||||
|
||||
|
||||
Qubes 3.2 - Windows VM installation
|
||||
-----------------------------------
|
||||
|
||||
### Summary ###
|
||||
|
||||
~~~
|
||||
qvm-create win7new --hvm --label red
|
||||
qvm-prefs -s win7new memory 4096
|
||||
qvm-prefs -s win7new maxmem 4096
|
||||
qvm-grow-root win7new 25g
|
||||
qvm-prefs -s win7new debug true
|
||||
cp /var/lib/qubes/appvms/win7new/win7new.conf /tmp
|
||||
sed -i "s/<model \+type='xen' \+vram=/<model type='cirrus' vram=/" /tmp/win7new.conf
|
||||
qvm-start --custom-config=/tmp/win7new.conf --cdrom=untrusted:/home/user/windows_install.iso win7new
|
||||
# restart after the first part of the windows installation process ends
|
||||
qvm-start --custom-config=/tmp/win7new.conf win7new
|
||||
# once Windows is installed and working
|
||||
qvm-prefs -s win7new memory 2048
|
||||
qvm-prefs -s win7new maxmem 2048
|
||||
rm /tmp/win7new.conf
|
||||
qvm-prefs -s win7new qrexec_timeout 300
|
||||
# with Qubes Windows Tools installed:
|
||||
qvm-prefs -s win7new debug false
|
||||
~~~
|
||||
|
||||
### 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.
|
||||
|
||||
Create a VM named win7new in [HVM](/doc/hvm/) mode (Xen's current PVH limitations precludes from using PVH):
|
||||
|
||||
~~~
|
||||
qvm-create win7new --hvm --label red
|
||||
~~~
|
||||
|
||||
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 -s win7new memory 4096
|
||||
qvm-prefs -s win7new maxmem 4096
|
||||
~~~
|
||||
|
||||
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-grow-root win7new 25g
|
||||
~~~
|
||||
|
||||
Set the debug flag in order to have a graphical console:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s 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'. Backup the VM's configuration file and substitute the video driver from 'xen' to 'cirrus':
|
||||
|
||||
~~~
|
||||
cp /var/lib/qubes/appvms/win7new/win7new.conf /tmp
|
||||
sed -i "s/<model \+type='xen' \+vram=/<model type='cirrus' vram=/" /tmp/win7new.conf
|
||||
# or edit the file manually ; either way, make sure the adapter is now 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 --custom-config=/tmp/win7new.conf --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 --custom-config=/tmp/win7new.conf 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 -s win7new memory 2048
|
||||
qvm-prefs -s win7new maxmem 2048
|
||||
~~~
|
||||
|
||||
We don't need to use the 'cirrus' video adapter anymore; simply starting the VM with `qvm-start win7new` will use the default XEN adapter, but to avoid any mistakes let's remove the temporary configuration file we created before:
|
||||
|
||||
~~~
|
||||
rm /tmp/win7new.conf
|
||||
~~~
|
||||
|
||||
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 -s 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 integration](#xen-pv-drivers-and-qubes-integration) below). It is a good time to clone the VM again.
|
||||
|
||||
|
||||
Qubes 4.0 - 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
|
||||
~~~
|
||||
|
||||
### 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 integration](#xen-pv-drivers-and-qubes-integration) 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 integration
|
||||
------------------------------------
|
||||
|
||||
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…
Reference in New Issue
Block a user