mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-05-08 17:55:06 -04:00
Move current pages to /en/ subdirectory
This commit is contained in:
Axon
parent
f3ee78f223
commit
a91496e9d6
159 changed files with 2 additions and 2 deletions
|
|
@ -1,73 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: FedoraTemplateUpgrade
|
||||
permalink: /en/doc/fedora-template-upgrade-18/
|
||||
redirect_from:
|
||||
- /doc/FedoraTemplateUpgrade18/
|
||||
- /wiki/FedoraTemplateUpgrade/
|
||||
---
|
||||
|
||||
Upgrade of Fedora template
|
||||
==========================
|
||||
|
||||
(**Note:** There is a [newer version of this page for upgrading from Fedora 20 to Fedora 21](/en/doc/fedora-template-upgrade-20/).)
|
||||
|
||||
This instruction in simplified version of [official Fedora instruction](https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum). Note that only "yum" method will work in Qubes template VM (if you are curious why: mostly because template VM does not have own bootloader).
|
||||
|
||||
Upgrading Fedora 18 to Fedora 20
|
||||
--------------------------------
|
||||
|
||||
Commands to run in dom0 console (you can do the same from Qubes Manager):
|
||||
|
||||
~~~
|
||||
qvm-clone fedora-18-x64 fedora-20-x64
|
||||
qvm-run -a fedora-20-x64 gnome-terminal
|
||||
~~~
|
||||
|
||||
Commands to run in new fedora-20-x64 template:
|
||||
|
||||
~~~
|
||||
sudo yum --releasever=20 distro-sync
|
||||
poweroff
|
||||
~~~
|
||||
|
||||
If you have installed a lot of software in your template, it may happen that you don't have enough disk space for upgrade. Yum will tell you this just after confirming the operation (before it change anything to your system). In that case you need to provide some "external" place for yum cache (uses about 2GB during upgrade). For example attach virtual disk stored in some file. Prepare the file in dom0:
|
||||
|
||||
~~~
|
||||
truncate -s 5GB /var/tmp/template-upgrade-cache.img
|
||||
qvm-block -A fedora-20-x64 dom0:/var/tmp/template-upgrade-cache.img
|
||||
~~~
|
||||
|
||||
Then use it in template:
|
||||
|
||||
~~~
|
||||
sudo mkfs.ext4 /dev/xvdi
|
||||
sudo mount /dev/xvdi /mnt/removable
|
||||
sudo yum --releasever=20 --setopt=cachedir=/mnt/removable distro-sync
|
||||
~~~
|
||||
|
||||
After upgrade is finished, you can remove /var/tmp/template-upgrade-cache.img file.
|
||||
|
||||
Compacting templates root.img
|
||||
=============================
|
||||
|
||||
fstrim, nor "discard" mount option do not work on template root fs, so when some file is removed in the template, space isn't freed in dom0. This means that template will use about twice a space that is really need after upgrade.
|
||||
|
||||
**If you have at least `qubes-core-dom0-2.1.68` installed, you can use `qvm-trim-template` tool. Otherwise use instructions below.**
|
||||
|
||||
You can compact root.img in the "old way", you'll need about 15GB (template's max size + really used space there) in dom0 for this operation: Start the template, fill all the free space with zeros, for example with:
|
||||
|
||||
~~~
|
||||
dd if=/dev/zero of=/var/tmp/zero
|
||||
(wait for "No space left on device" error)
|
||||
rm -f /var/tmp/zero
|
||||
~~~
|
||||
|
||||
Then shutdown template and all VMs based on it. Go into template directory in dom0 (/var/lib/qubes/vm-templates/fedora-20-x64 or so) and issue:
|
||||
|
||||
~~~
|
||||
cp --sparse=always root.img root.img.new
|
||||
mv root.img.new root.img
|
||||
~~~
|
||||
|
||||
Done.
|
||||
|
|
@ -1,223 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: FedoraTemplateUpgrade
|
||||
permalink: /en/doc/fedora-template-upgrade-20/
|
||||
redirect_from:
|
||||
- /doc/FedoraTemplateUpgrade20/
|
||||
- /wiki/FedoraTemplateUpgrade20/
|
||||
---
|
||||
|
||||
How to Upgrade Fedora Templates
|
||||
===============================
|
||||
|
||||
Summary: Upgrading the Standard Fedora 20 Template to Fedora 21
|
||||
---------------------------------------------------------------
|
||||
|
||||
[user@dom0 ~]$ qvm-clone fedora-20-x64 fedora-21
|
||||
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal
|
||||
[user@dom0 ~]$ qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img
|
||||
[user@fedora-21 ~]$ sudo mkfs.ext4 /dev/xvdi
|
||||
[user@fedora-21 ~]$ sudo mount /dev/xvdi /mnt/removable
|
||||
[user@fedora-21 ~]$ sudo mkdir /mnt/removable/modules
|
||||
[user@fedora-21 ~]$ sudo cp -rp /usr/lib/modules /mnt/removable/modules
|
||||
[user@fedora-21 ~]$ sudo mount --bind /mnt/removable/modules /usr/lib/modules
|
||||
[user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard
|
||||
[user@fedora-21 ~]$ sudo yum clean all
|
||||
[user@fedora-21 ~]$ sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync
|
||||
[user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/
|
||||
|
||||
(Shut down TemplateVM via Qubes VM Manager; may need to be killed.)
|
||||
|
||||
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal
|
||||
[user@fedora-21 ~]$ sudo yum -y update
|
||||
|
||||
(Shut down TemplateVM by any normal means.)
|
||||
|
||||
[user@dom0 ~]$ qvm-trim-template fedora-21
|
||||
|
||||
Detailed: Upgrading the Standard Fedora 20 Template to Fedora 21
|
||||
----------------------------------------------------------------
|
||||
|
||||
These instructions will show you how to upgrade the standard Fedora 20
|
||||
TemplateVM to Fedora 21. The same general procedure may be used to upgrade any
|
||||
template based on the standard Fedora 20 template.
|
||||
|
||||
1. Clone the existing template and start a terminal in the new template.
|
||||
|
||||
[user@dom0 ~]$ qvm-clone fedora-20-x64 fedora-21
|
||||
[user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal
|
||||
|
||||
2. Attempt the upgrade process in the new template.
|
||||
|
||||
[user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard
|
||||
[user@fedora-21 ~]$ sudo yum clean all
|
||||
[user@fedora-21 ~]$ sudo yum --releasever=21 distro-sync
|
||||
[user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/
|
||||
|
||||
(Shut down TemplateVM via Qubes VM Manager; may need to be killed.)
|
||||
|
||||
If you encounter no errors, proceed to step 7.
|
||||
|
||||
3. If `yum` reports that you do not have enough free disk space to proceed with
|
||||
the upgrade process, create an empty file in dom0 to use as a cache and
|
||||
attach it to the template as a virtual disk.
|
||||
|
||||
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img
|
||||
|
||||
Then reattempt the upgrade process, but this time using the virtual disk as
|
||||
a cache.
|
||||
|
||||
[user@fedora-21 ~]$ sudo mkfs.ext4 /dev/xvdi
|
||||
[user@fedora-21 ~]$ sudo mount /dev/xvdi /mnt/removable
|
||||
[user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard
|
||||
[user@fedora-21 ~]$ sudo yum clean all
|
||||
[user@fedora-21 ~]$ sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync
|
||||
[user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/
|
||||
|
||||
(Poweroff via Qubes VM Manager. May need to be killed.)
|
||||
|
||||
4. If `yum` complains that there is not enough free space in `/usr/lib/modules`,
|
||||
do this before reattempting the upgrade:
|
||||
|
||||
[user@fedora-21 ~]$ sudo mkdir /mnt/removable/modules
|
||||
[user@fedora-21 ~]$ sudo cp -rp /usr/lib/modules /mnt/removable/modules
|
||||
[user@fedora-21 ~]$ sudo mount --bind /mnt/removable/modules /usr/lib/modules
|
||||
|
||||
5. `yum` may complain:
|
||||
|
||||
At least X MB more space needed on the / filesystem.
|
||||
|
||||
In this case, one option is to [resize the TemplateVM's disk
|
||||
image](/doc/ResizeDiskImage/) before reattempting the upgrade process.
|
||||
(See **Additional Information** below for other options.)
|
||||
|
||||
6. After the upgrade process is finished, remove the cache file, if you
|
||||
created one.
|
||||
|
||||
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
|
||||
|
||||
7. Ensure your new template is fully updated.
|
||||
|
||||
[user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal
|
||||
[user@fedora-21 ~]$ sudo yum -y update
|
||||
|
||||
8. Trim the new template (see **Compacting the Upgraded Template** for details
|
||||
and other options).
|
||||
|
||||
[user@dom0 ~]$ qvm-trim-template fedora-21
|
||||
|
||||
9. (Optional) Remove the old default template.
|
||||
|
||||
[user@dom0 ~]$ sudo yum remove qubes-template-fedora-20-x64
|
||||
|
||||
|
||||
Summary: Upgrading the Minimal Fedora 20 Template to Fedora 21
|
||||
--------------------------------------------------------------
|
||||
|
||||
[user@dom0 ~]$ qvm-clone fedora-20-x64-minimal fedora-21-minimal
|
||||
[user@dom0 ~]$ qvm-run -a fedora-21-minimal xterm
|
||||
[user@fedora-21-minimal ~]$ su -
|
||||
[root@fedora-21-minimal ~]# yum clean all
|
||||
[user@fedora-21-minimal ~]# yum --releasever=21 distro-sync
|
||||
[user@fedora-21-minimal ~]# cp /usr/lib/qubes/init/ip* /etc/sysconfig/
|
||||
|
||||
(Shut down the TemplateVM via Qubes VM Manager. May need to be killed.)
|
||||
|
||||
[user@dom0 ~]$ qvm-run -a fedora-21-minimal xterm
|
||||
[user@fedora-21-minimal ~]$ su -
|
||||
[root@fedora-21-minimal ~]# yum -y update
|
||||
|
||||
(Shut down TemplateVM by any normal means.)
|
||||
|
||||
[user@dom0 ~]$ qvm-trim-template fedora-21-minimal
|
||||
|
||||
(If you encounter insufficient space issues, you may need to use the methods
|
||||
described for the standard template above.)
|
||||
|
||||
|
||||
Differences Between the Standard and Minimal Upgrade Procedures
|
||||
---------------------------------------------------------------
|
||||
|
||||
The procedure for upgrading the minimal template (or any template based on the
|
||||
minimal template) is the same as the procedure for the standard template above,
|
||||
**with the following exceptions**:
|
||||
|
||||
1. `gnome-terminal` is not installed by default. Unless you've installed it
|
||||
(or another terminal emulator), use `xterm`. (Of course, you can also use
|
||||
`xterm` for the standard template, if you prefer.)
|
||||
2. `nautilus-actions` and `libcacard` are not installed by default, so do not
|
||||
try to erase them (unless you've installed them).
|
||||
3. `sudo` is not installed by default. Unless you've installed it, use `su` as
|
||||
demonstrated above. (Of course, you can also use `su` for the standard
|
||||
template, if you prefer.)
|
||||
|
||||
|
||||
Compacting the Upgraded Template
|
||||
================================
|
||||
|
||||
Neither `fstrim` nor the `discard` mount option works on the TemplateVM's root
|
||||
filesystem, so when a file is removed in the template, space is not freed in
|
||||
dom0. This means that the template will use about twice as much space as is
|
||||
really necessary after upgrading.
|
||||
|
||||
If you have at least `qubes-core-dom0-2.1.68` installed and are on Qubes R2,
|
||||
you can use the `qvm-trim-template` tool:
|
||||
|
||||
[user@dom0 ~]$ qvm-trim-template fedora-21
|
||||
|
||||
If you do not have `qubes-core-dom0-2.1.68` or are on Qubes R3-rc1, you can
|
||||
compact the `root.img` manually. To do this, you will need about 15GB (the
|
||||
TemplateVM's max size + the actually used space there) free space in dom0.
|
||||
|
||||
1. Start the template and fill all the free space with zeros, for example
|
||||
with:
|
||||
|
||||
[user@fedora-21 ~]$ dd if=/dev/zero of=/var/tmp/zero
|
||||
|
||||
2. Wait for the "No space left on device" error. Then:
|
||||
|
||||
[user@fedora-21 ~]$ rm -f /var/tmp/zero
|
||||
|
||||
3. Shut down the template and all VMs based on it. Then:
|
||||
|
||||
[user@dom0 ~]$ cd /var/lib/qubes/vm-templates/fedora-21
|
||||
[user@dom0 ~]$ cp --sparse=always root.img root.img.new
|
||||
[user@dom0 ~]$ mv root.img.new root.img
|
||||
|
||||
|
||||
Additional Information
|
||||
======================
|
||||
|
||||
As mentioned above, you may encounter the following `yum` error:
|
||||
|
||||
At least X MB more space needed on the / filesystem.
|
||||
|
||||
In this case, you have several options:
|
||||
|
||||
1. [Increase the TemplateVM's disk image size](/en/doc/resize-disk-image/).
|
||||
This is the solution mentioned in the main instructions above.
|
||||
2. Delete files in order to free up space. One way to do this is by
|
||||
uninstalling packages. You may then reinstalling them again after you
|
||||
finish the upgrade process, if desired). However, you may end up having to
|
||||
increase the disk image size anyway (see previous option).
|
||||
3. Increase the `root.img` size with `qvm-grow-root`. It should be easy to
|
||||
extend the `qvm-grow-root` tool in order to support PV (and not only HVM)
|
||||
VMs. However, someone would need to do this (patches welcome).
|
||||
4. Do the upgrade in parts, e.g., by using package groups. (First upgrade
|
||||
`@core` packages, then the rest.)
|
||||
5. Do not perform an in-place upgrade. Instead, simply download and install a
|
||||
new template package, then redo all desired template modifications.
|
||||
|
||||
With regard to the last option, here are some useful messages from the mailing
|
||||
list which also apply to TemplateVM management and migration in general:
|
||||
|
||||
* [Marek](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/dS1jbLRP9n8J)
|
||||
* [Jason M](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/5PxDfI-RKAsJ)
|
||||
|
||||
Known issues with Fedora 21
|
||||
===========================
|
||||
|
||||
* [The "Update VM" command in Qubes Manager does not work](https://github.com/QubesOS/qubes-issues/issues/982).
|
||||
|
|
@ -1,311 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: HvmCreate
|
||||
permalink: /en/doc/hvm-create/
|
||||
redirect_from:
|
||||
- /doc/HvmCreate/
|
||||
- /wiki/HvmCreate/
|
||||
---
|
||||
|
||||
Creating and using HVM (fully virtualized) domains in Qubes 2
|
||||
=============================================================
|
||||
|
||||
What are HVM domains?
|
||||
---------------------
|
||||
|
||||
HVM domains (Hardware VM), in contrast to PV domains (Paravirtualized domains), allow to create domains based on any OS, if one only has its installation ISO. E.g. this allows to have Windows-based VMs in Qubes.
|
||||
|
||||
Interested readers might want to check [this article](http://theinvisiblethings.blogspot.com/2012/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 Linuxed-based PV domains).
|
||||
|
||||
Creating an HVM domain
|
||||
----------------------
|
||||
|
||||
First, lets create a new HVM domain (use the --hvm switch to qvm-create, or choose HVM type in the Qubes Manager VM creation dialog box):
|
||||
|
||||
~~~
|
||||
qvm-create win7 --hvm --label green
|
||||
~~~
|
||||
|
||||
(Of course, the name of the domain ("win7"), as well as it's label ("green"), are just exemplary).
|
||||
|
||||
Now, we need to install an OS inside this VM, this can done by attaching an installation ISO upon starting the VM (this currently can be done only from command line, but in the future we surely will added an option to do this also from the manager):
|
||||
|
||||
~~~
|
||||
qvm-start win7 --cdrom=/usr/local/iso/win7_en.iso
|
||||
~~~
|
||||
|
||||
The command above assumes the installation ISO was somehow transferred to Dom0, e.g. copied using `dd` command from an installation CDROM. 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`:
|
||||
|
||||
~~~
|
||||
qvm-start win7 --cdrom=/dev/cdrom
|
||||
~~~
|
||||
|
||||
Now, the VM will start booting from the attached CDROM device, which in the example above just happens to be the Windows 7 installation disk. Depending on the OS that is being installed in the VM, one might be required to start the VM several times (as is the case e.g. with Windows 7 installation), because whenever the installer wants to "reboot the system", it actually shutdowns the VM (and Qubes won't automatically start it), so several invocations of qvm-start command (as shown above) might be needed.
|
||||
|
||||
[](/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. However, for security reasons, networking is disabled for Qubes Dom0, which makes it not possible to download an ISO within Dom0. Also Qubes do not provide any (easy to use) mechanisms for copying files between AppVMs and Dom0, and generally tries to discourage such actions. So, it would be inconvenient to require that the installation ISO for an HVM domain be always located in Dom0. And the good news is that this is indeed not required -- one can use the following syntax when specifying the location of /usr/local/iso/win7\_en.iso the installation ISO:
|
||||
|
||||
~~~
|
||||
--cdrom=[appvm]:[/path/to/iso/within/appvm]
|
||||
~~~
|
||||
|
||||
Assuming e.g. the an installation ISO named `ubuntu-12.10-desktop-i386.iso` has been downloaded in `work-web` AppVM, and located within `/home/user/Downloads` directory within this AppVM, one can immediately create a new HVM and use this ISO as an installation media with the following command (issued in Dom0, of course):
|
||||
|
||||
~~~
|
||||
qvm-create --hvm ubuntu --label red
|
||||
qvm-start ubuntu --cdrom=work-web:/home/user/Downloads/ubuntu-12.10-desktop-i386.iso
|
||||
~~~
|
||||
|
||||
Of course the AppVM where the ISO is kept must also be running for this to work (this VM is now serving the ISO and acting as a disk backend).
|
||||
|
||||
|
||||
|
||||
Setting up networking for HVM domains
|
||||
-------------------------------------
|
||||
|
||||
Just like standard (paravirtualized) AppVMs, the HVM domains got 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](http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html).
|
||||
|
||||
However, a generic HVM domain, e.g. a standard Windows or Ubuntu installation, has (at least initially) no Qubes agent scripts running inside it, 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 built in (but not Qubes tools) and which bypass the stub-domain networking (their net frontends connect directly to the net backend in the netvm), and so 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.
|
||||
|
||||
Now, one should configure the networking within the HVM according to those settings (IP/netmask/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
|
||||
--------------------------------
|
||||
|
||||
TODO (Coming in Qubes R2 beta 3).
|
||||
|
||||
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 image, and essentially will 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. Of course, the IP addresses, assigned by Qubes, will also be different, 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
|
||||
~~~
|
||||
|
||||
Please note that as of now Qubes does not support shared templates for HVM domains. This means that HVM domains cloned this way will have two separate copies of the whole filesystems. This has consequences in taking much more disk space compared to standard AppVMs that share the root fs with the Template VM. Another consequence is that it's probably not legal to clone a proprietary OS, such as Windows this way, unless your license specifically allows for that (even though Windows Activation won't complain when one sets identical MAC address for the cloned VMs, it's doubtful practice at best).
|
||||
|
||||
In the near future we plan on introducing shared template also for HVM domains, hopefully solving the problems described above.
|
||||
|
||||
~~Installing Qubes support tools in Windows 7 VMs~~ (only for R2 Beta 2)
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Note: the R2 Beta 3 (which is coming soon) has automated most of the actions described below -- please see [this page instead](/en/doc/windows-appvms/).
|
||||
|
||||
Qubes support tools for Windows VMs is a set of programs and drivers that provide integration of Windows VMs with the rest of the Qubes system. Currently the following features become available for Windows VMs after installation of those tools:
|
||||
|
||||
- Support for [secure clipboard copy/paste](/en/doc/copy-paste/) between the Windows VM and other AppVMs
|
||||
- Support for [secure file exchange](/en/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
|
||||
|
||||
Features that are currently not supported, but are planned for future releases (as soon as R2 Beta 2):
|
||||
|
||||
- Video driver for Windows allowing custom resolutions (arbitrary HVM window resizing) and VM's mouse cursor hiding
|
||||
- Seamless app window mode, in which application windows are extracted and composed onto a common desktop just like it's currently done for Linux AppVMs. Currently Windows HVMs run in a window that contains the whole desktop of the VM.
|
||||
|
||||
Qubes Windows Support Tools are not open source and are distributed under a commercial license and their source code is not publicly available.
|
||||
|
||||
Because the Windows Support Tools are not licensed under a GPL license they are not distributed with Qubes installation ISO. Instead, one can download them when needed using the standard Qubes command for installing software in Dom0:
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update qubes-windows-tools
|
||||
~~~
|
||||
|
||||
This should install `qubes-windows-tools-*.rpm` in your system, a package that brings an ISO with Windows Support Tools:
|
||||
|
||||
~~~
|
||||
[joanna@dom0 ~]$ rpm -ql qubes-windows-tools-1-201211301354.noarch
|
||||
/usr/lib/qubes/qubes-windows-tools-201211301354.iso
|
||||
~~~
|
||||
|
||||
Now, in order to install the tools in a Windows VM one should start the VM with the ISO attached:
|
||||
|
||||
~~~
|
||||
qvm-start lab-win7 --cdrom=/usr/lib/qubes/qubes-windows-tools-201211301354.iso
|
||||
~~~
|
||||
|
||||
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:
|
||||
|
||||
[](/attachment/wiki/HvmCreate/r2b1-win7-installing-qubes-tools-1.png)
|
||||
|
||||
Before proceeding with the installation we need to disable Windows mechanism that allows only signed drivers to be installed, because currently the drivers we provide as part of the Windows Support Tools are not digitally signed with a publicly recognizable certificate. How to do that is explained in the `README` file also located on the installation CDROM. 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, and also to accept a few scary looking warning windows during the installation process, as shown below.
|
||||
|
||||
[](/attachment/wiki/HvmCreate/r2b1-win7-installing-qubes-tools-2.png)
|
||||
[](/attachment/wiki/HvmCreate/r2b1-win7-installing-qubes-tools-4.png)
|
||||
[](/attachment/wiki/HvmCreate/r2b1-win7-installing-qubes-tools-5.png)
|
||||
|
||||
After successful installation, the Windows VM must be shut down.
|
||||
|
||||
Additionally, once should inform Qubes that tools have been installed in this VM by setting the `qrexec_installed` flag in the VM's properties -- this can be done using the `qvm-prefs` command in Dom0, e.g.:
|
||||
|
||||
~~~
|
||||
qvm-prefs lab-win7 -s qrexec_installed true
|
||||
~~~
|
||||
|
||||
Also, by default Qubes assumes that the default user in the Windows VM is named `user` -- if one has chosen a different user during Windows installation, Qubes should be informed about this by setting the `default_user` property for the VM, e.g.:
|
||||
|
||||
~~~
|
||||
qvm-prefs lab-win7 -s default_user joanna
|
||||
~~~
|
||||
|
||||
If everything went fine (please remember about the need to reboot the Windows VM after installation of the tools), one can run some simple tests to see if qrexec service runs fine with this VM, e.g.:
|
||||
|
||||
~~~
|
||||
qvm-run lab-win7 calc
|
||||
~~~
|
||||
|
||||
... or something more fancy (a "networkless" telnet to Windows ;):
|
||||
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-run lab-win7 -p cmd.exe
|
||||
Microsoft Windows [Version 6.1.7601]
|
||||
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
|
||||
|
||||
C:\Windows\system32>dir c:\
|
||||
dir c:\
|
||||
Volume in drive C has no label.
|
||||
Volume Serial Number is 64FB-0198
|
||||
|
||||
Directory of c:\
|
||||
|
||||
08/26/2012 12:06 PM <DIR> DRIVERS
|
||||
12/12/2012 03:36 PM <DIR> Program Files
|
||||
10/25/2012 12:12 PM <DIR> Program Files (x86)
|
||||
03/22/2012 02:50 PM <DIR> SWTOOLS
|
||||
03/02/2012 12:22 AM <DIR> Users
|
||||
12/12/2012 03:40 PM <DIR> Windows
|
||||
0 File(s) 0 bytes
|
||||
6 Dir(s) 1,432,260,608 bytes free
|
||||
|
||||
C:\Windows\system32>exit
|
||||
exit
|
||||
~~~
|
||||
|
||||
Another things to check are if clipboard copy/paste and file copy works fine with this VM. If it doesn't, then perhaps one more VM reboot is necessary (seriously, hey this is Windows!).
|
||||
|
||||
And the screenshot below illustrates the Send To entries in a Windows VM that can be used to copy/send files to other Qubes domains:
|
||||
|
||||
[](/attachment/wiki/HvmCreate/win7-sendto-another-vm.png)
|
||||
|
||||
Assigning PCI devices to HVM domains
|
||||
------------------------------------
|
||||
|
||||
HVM domains (including Windows VMs) can be [assigned PCI devices](/en/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.
|
||||
|
||||
Once problem, however, at the moment, is that after the whole system gets suspend into S3 sleep, and subsequently resumed, such attached devices stop working and should be restarted within the VM. Under Windows this can be achieved by opening the Device Manager, selecting the actual device, such as a USB controller, and then first 'Disabling', 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:
|
||||
|
||||
- [LinuxHVMTips](/en/doc/linux-hvm-tips/)
|
||||
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: LinuxHVMTips
|
||||
permalink: /en/doc/linux-hvm-tips/
|
||||
redirect_from:
|
||||
- /doc/LinuxHVMTips/
|
||||
- /wiki/LinuxHVMTips/
|
||||
---
|
||||
|
||||
Tips for Linux in HVM domain
|
||||
============================
|
||||
|
||||
Screen resolution
|
||||
-----------------
|
||||
|
||||
Some kernel/Xorg combination use only 640x480 in HVM, which is quite small. To enable maximum resolution, some changes in Xorg configuration are needed:
|
||||
|
||||
1. Force "vesa" video driver
|
||||
2. Provide wide horizontal synchronization range
|
||||
|
||||
To achieve it (all commands run as root):
|
||||
|
||||
1. Generate XOrg configuratio (if you don't have it):
|
||||
|
||||
~~~
|
||||
X -configure :1 && mv ~/xorg.conf.new /etc/X11/xorg.conf
|
||||
~~~
|
||||
|
||||
2. Add HorizSync line to Monitor section, it should look something like:
|
||||
|
||||
~~~
|
||||
Section "Monitor"
|
||||
Identifier "Monitor0"
|
||||
VendorName "Monitor Vendor"
|
||||
ModelName "Monitor Model"
|
||||
HorizSync 30.0 - 60.0
|
||||
EndSection
|
||||
~~~
|
||||
|
||||
3. Change driver to "vesa" in Device section:
|
||||
|
||||
~~~
|
||||
Section "Device"
|
||||
# (...)
|
||||
Identifier "Card0"
|
||||
Driver "vesa"
|
||||
VendorName "Technical Corp."
|
||||
BoardName "Unknown Board"
|
||||
BusID "PCI:0:2:0"
|
||||
EndSection
|
||||
~~~
|
||||
|
||||
Now you should get at least 1280x1024 and be able to choose other modes.
|
||||
|
||||
Qubes agents
|
||||
------------
|
||||
|
||||
Linux Qubes agents are written with PV domain in mind, but it looks to be possible to run them also in HVM domain. However some work is required to achieve it. Check [this thread](https://groups.google.com/group/qubes-devel/browse_thread/thread/081df4a43e49e7a5).
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Templates
|
||||
permalink: /en/doc/templates/
|
||||
redirect_from:
|
||||
- /doc/Templates/
|
||||
- /wiki/Templates/
|
||||
---
|
||||
|
||||
Templates
|
||||
=========
|
||||
|
||||
Every AppVM in Qubes is based on some template, this is where all the software
|
||||
available for AppVMs is installed. Default template is based on Fedora, but
|
||||
there are additional templates based on other Linux distributions, or with some
|
||||
additional software installed by default. This concept is described
|
||||
[here](/doc/GettingStarted/#appvms-domains-and-templatevms).
|
||||
|
||||
Some templates are available in ready to use binary form, but some of them are
|
||||
only as a source code, which can be built using [Qubes Builder](/en/doc/qubes-builder/).
|
||||
Especially some templates "flavors" are available in source code form only.
|
||||
Take a look at [Qubes Builder
|
||||
documentation](https://github.com/QubesOS/qubes-builder/blob/master/README.md)
|
||||
how to compile them.
|
||||
|
||||
ITL Supported templates
|
||||
-----------------------
|
||||
|
||||
For those templates ITL is responsible for build and releasing updates,
|
||||
especially ITL guarantees that the binary updates are compiled from exactly
|
||||
the source code we publish.
|
||||
|
||||
- Fedora
|
||||
- [Fedora - Minimal](/doc/Templates/FedoraMinimal)
|
||||
- [Debian](/en/doc/templates/debian/)
|
||||
|
||||
Community Supported templates
|
||||
-----------------------------
|
||||
|
||||
Those templates are supported by Qubes Community. Some of them are available in
|
||||
ready to use binary package (built by ITL), some are only in source code form.
|
||||
In any case ITL does not provide updates for those templates, but such updates
|
||||
can be provided by template maintainer.
|
||||
|
||||
In short - by installing those templates, you trust not only ITL and
|
||||
distribution maintainers, but also the template maintainer. It can also happen
|
||||
that those templates are somehow less stable, because we do not test them.
|
||||
|
||||
- [Whonix](/en/doc/templates/whonix/)
|
||||
- [Ubuntu](/en/doc/templates/ubuntu/)
|
||||
- [Archlinux](/en/doc/templates/archlinux/)
|
||||
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Archlinux template
|
||||
permalink: /en/doc/templates/archlinux/
|
||||
redirect_from:
|
||||
- /doc/Templates/Archlinux/
|
||||
- /wiki/Templates/Archlinux/
|
||||
---
|
||||
|
||||
Archlinux template
|
||||
===============
|
||||
|
||||
Archlinux template is one of the templates made by Qubes community. It should
|
||||
be considered experimental as Qubes developers team use mainly Fedora-based VMs
|
||||
to test new features/updates.
|
||||
|
||||
Main maintainer of this template is [Olivier Médoc](mailto:o_medoc@yahoo.fr).
|
||||
He also provides binary updates for the template, which are signed using this
|
||||
key:
|
||||
|
||||
pub 2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
|
||||
Key fingerprint = D85E E12F 9678 51CC F433 515A 2043 E7AC C183 3B9C
|
||||
uid Olivier MEDOC (Qubes-OS signing key) <o_medoc@yahoo.fr>
|
||||
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
Currently we do not ship ready to use binary package. It can be compiled using
|
||||
[this instructions](/en/doc/building-archlinux-template/).
|
||||
|
||||
Olivier provides binary package build by himself, you can get it for:
|
||||
* Qubes R2 [here](https://groups.google.com/d/msgid/qubes-devel/54CE3FB1.3050708%40yahoo.fr).
|
||||
* Qubes R3 [here](https://groups.google.com/d/msg/qubes-users/RI3KQVEEc30/h5nsNw_SHTQJ)
|
||||
|
||||
|
||||
|
||||
Known issues
|
||||
------------
|
||||
|
||||
If you want to help in improving the template, feel free to [contribute](/en/doc/contributing/).
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Debian
|
||||
permalink: /en/doc/templates/debian/
|
||||
redirect_from:
|
||||
- /doc/Templates/Debian/
|
||||
- /wiki/Templates/Debian/
|
||||
---
|
||||
|
||||
Debian template(s)
|
||||
===============
|
||||
|
||||
If you like to use Debian Linux distribution in your AppVMs, you can install one of available Debian templates.
|
||||
|
||||
Updates for this template are provided by ITL and are signed by this key:
|
||||
|
||||
pub 4096R/47FD92FA 2014-07-27
|
||||
Key fingerprint = 2D43 E932 54EE EA7C B31B 6A77 5E58 18AB 47FD 92FA
|
||||
uid Qubes OS Debian Packages Signing Key
|
||||
|
||||
The key is already installed when you install (signed) template package. You
|
||||
can also obtain the key from [git
|
||||
repository](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes-archive-keyring.gpg),
|
||||
which is also integrity-protected using signed git tags.
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
It can be installed via the following command:
|
||||
|
||||
Debian 7 (wheezy) - old stable:
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-7
|
||||
|
||||
Debian 8 (jessie) - stable:
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8
|
||||
|
||||
Debian 9 (stretch) - testing:
|
||||
|
||||
A prebuilt template is not yet available, but you can build an experimental stretch template from source.
|
||||
|
||||
|
||||
Known issues
|
||||
------------
|
||||
|
||||
If you want to help in improving the template, feel free to [contribute](/wiki/ContributingHowto).
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: FedoraMinimal
|
||||
permalink: /en/doc/templates/fedora-minimal/
|
||||
redirect_from:
|
||||
- /doc/Templates/FedoraMinimal/
|
||||
- /wiki/Templates/FedoraMinimal/
|
||||
---
|
||||
|
||||
Fedora - minimal
|
||||
================
|
||||
|
||||
We have uploaded a new "minimal" template to our templates-itl repo. The template weighs only 150MB and has most of the stuff cut off, except for minimal X and xterm.
|
||||
|
||||
More into in ticket \#828
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
It can be installed via the following command:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-21-minimal
|
||||
~~~
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
It is a good idea to clone the original template, and make any changes in the new clone instead:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ qvm-clone fedora-21-minimal <your new template name>
|
||||
~~~
|
||||
|
||||
The sudo package is not installed by default, so let's install it:
|
||||
|
||||
~~~
|
||||
[user@F21-Minimal ~]$ su -
|
||||
[user@F21-Minimal ~]$ yum install sudo
|
||||
~~~
|
||||
|
||||
The rsyslog logging service is not installed by default. All logging is now being handled by the systemd journal. Users requiring the rsyslog service should install it manually.
|
||||
|
||||
To access the journald log, use the `journalctl` command.
|
||||
|
||||
### as a NetVM
|
||||
|
||||
If you want to use this template to for standard NetVMs you should install some more packeges:
|
||||
|
||||
~~~
|
||||
[user@F21-Minimal ~]$ sudo yum install NetworkManager NetworkManager-wifi network-manager-applet wireless-tools dbus-x11 dejavu-sans-fonts tar tinyproxy
|
||||
~~~
|
||||
|
||||
And maybe some more optional but useful packages as well:
|
||||
|
||||
~~~
|
||||
[user@F21-Minimal ~]$ sudo yum install pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat gnome-keyring
|
||||
~~~
|
||||
|
||||
If your network device needs some firmware then you should also install the corresponding packages as well. The `lspci; yum search firmware` command will help to choose the right one :)
|
||||
|
||||
### as a ProxyVM
|
||||
|
||||
If you want to use this template as a ProxyVM you may want to install even more packages
|
||||
|
||||
#### Firewall
|
||||
|
||||
This template is ready to use for a standard firewall VM.
|
||||
|
||||
#### VPN
|
||||
|
||||
The needed packages depend on the VPN technology. The `yum search "NetworkManager VPN plugin"` command may help you to choose the right one.
|
||||
|
||||
[More details about setting up a VPN Gateway](/wiki/VPN#ProxyVM)
|
||||
|
||||
#### TOR
|
||||
|
||||
[UserDoc/TorVM](/wiki/UserDoc/TorVM)
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Ubuntu
|
||||
permalink: /en/doc/templates/ubuntu/
|
||||
redirect_from:
|
||||
- /doc/Templates/Ubuntu/
|
||||
- /wiki/Templates/Ubuntu/
|
||||
---
|
||||
|
||||
Ubuntu template(s)
|
||||
==================
|
||||
|
||||
If you like to use Ubuntu Linux distribution in your AppVMs, you can build and
|
||||
install one of available Ubuntu templates. Those template currently are not
|
||||
available in ready to use binary packages, because Canonical does not allow
|
||||
to redistribute a modified Ubuntu. The redistribution is not allowed by their
|
||||
[Intellectual property rights policy](http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy).
|
||||
|
||||
|
||||
Install
|
||||
-------
|
||||
|
||||
It can built using [Qubes Builder](/en/doc/qubes-builder/). You can also access its
|
||||
documentation in the [source code
|
||||
repository](https://github.com/QubesOS/qubes-builder/blob/master/README.md).
|
||||
|
||||
To quickly prepare the builder configuration, you can use `setup` script
|
||||
available in the repository - it will interactively ask you which templates you
|
||||
want to build.
|
||||
|
||||
Known issues
|
||||
------------
|
||||
|
||||
If you want to help in improving the template, feel free to
|
||||
[contribute](/wiki/ContributingHowto).
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Whonix template
|
||||
permalink: /en/doc/templates/whonix/
|
||||
redirect_from:
|
||||
- /doc/Templates/Whonix/
|
||||
- /wiki/Templates/Whonix/
|
||||
---
|
||||
|
||||
Whonix template(s)
|
||||
==================
|
||||
|
||||
Whonix is an operating system focused on anonymity, privacy and security. It's
|
||||
based on the Tor anonymity network, Debian GNU/Linux and security by isolation.
|
||||
Its primary isolation mechanism is VirtualBox, but now it is also possible to
|
||||
run it on top of Qubes OS!
|
||||
|
||||
Whonix template(s) are another Qubes community contribution. Currently Whonix actively maintains those templates.
|
||||
|
||||
More details, including installation instructions on [Whonix Qubes web page](https://www.whonix.org/wiki/Qubes).
|
||||
|
|
@ -1,125 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: UninstallingWindowsTools2
|
||||
permalink: /en/doc/uninstalling-windows-tools-2/
|
||||
redirect_from:
|
||||
- /doc/UninstallingWindowsTools2/
|
||||
- /wiki/UninstallingWindowsTools2/
|
||||
---
|
||||
|
||||
Uninstalling Qubes Tools for Windows v2.x
|
||||
=========================================
|
||||
|
||||
**Do not try to uninstall Qubes Tools for Windows (QTW) 2.x from Windows Control Panel. It will render your HVM unbootable and will require manual fixing.**
|
||||
|
||||
Preface
|
||||
-------
|
||||
|
||||
Version 2.x of QTW (used for Windows HVMs in Qubes R2) is difficult to uninstall due to issues with the Xen GPL PV drivers package that is used. However, uninstalling QTW version 2.x is required to migrate the HVM to Qubes R3.
|
||||
HVMs with QTW 2.x *will not boot normally in Qubes R3* due to Xen drivers failing. They will boot in Safe Mode. It's easier to uninstall QTW 2.x from Qubes R2, but if that's not an option it's also possible in Qubes R3 (just a bit more complicated). Details below.
|
||||
|
||||
Uninstalling QTW 2.x in Qubes R2
|
||||
--------------------------------
|
||||
|
||||
1. Copy the uninstall script posted at the end of this document and save it in the HVM as a .BAT file.
|
||||
2. Reboot the HVM in Safe Mode: type `bcdedit /set safeboot minimal` in a command prompt with admin privileges then restart normally. The OS will now always start in Safe Mode until the setting is reverted.
|
||||
3. In Safe Mode execute the uninstall script from step 1.
|
||||
4. Open Device Manager. Manually uninstall Qubes Video device (in 'Display adapters') and Xen PCI driver (in 'System devices'). This will prevent the (already removed) devices from showing up.
|
||||
5. Type `bcdedit /deletevalue safeboot` in a command prompt to disable Safe Mode boot.
|
||||
6. Reboot. Open Device Manager and verify that there are no active Xen PV devices:
|
||||
- There should be one unidentified PCI device in System devices (this is the Xen PV device, not functioning because PV drivers are inactive).
|
||||
- Disk drives should be QEMU (emulated).
|
||||
- Network adapter should be Realtek (emulated).
|
||||
|
||||
Now you can backup the HVM, migrate it to Qubes R3 and install QTW 3.x there.
|
||||
|
||||
Uninstalling QTW 2.x in Qubes R3
|
||||
--------------------------------
|
||||
|
||||
HVMs with QTW 2.x will not boot normally in Qubes R3 due to the old Xen drivers failing. If removing QTW from Qubes R2 is not an option (see above) then you will need to boot the HVM in Safe Mode.
|
||||
|
||||
### Preparation in dom0
|
||||
|
||||
Disable VM tools in VM's preferences:
|
||||
* `qvm-prefs -s vmname qrexec_installed false`
|
||||
* `qvm-prefs -s vmname guiagent_installed false`
|
||||
|
||||
### Enabling Safe Mode
|
||||
* If you're quick you can mash F8 just as the HVM boots to access Windows' advanced boot options. The timing for it is very tight though. If you manage to get the boot menu, select Safe Mode boot.
|
||||
* Alternatively, allow the HVM to (try to) boot. It will crash with a BSOD.
|
||||
* After the crash start the HVM again. Now Windows will display the recovery menu which, for some unknown reason, does not include Safe Mode boot option. We need to try harder.
|
||||
* Select **Launch Startup Repair**.
|
||||
* If you're prompted to try System Restore, **don't**. Hit cancel.
|
||||
* Grab a drink or read a book while Windows tries to do something but ultimately the repair process fails.
|
||||
* *Now* you're presented with a choice of *advanced options* that include a command prompt. Why isn't this available from the start?
|
||||
* Launch the command prompt, log in and type `bcdedit /set {default} safeboot minimal`. The OS will now always start in Safe Mode until the setting is reverted.
|
||||
* Reboot and proceed with the uninstallation instructions from the previous paragraph (*Uninstalling QTW 2.x in Qubes R2*).
|
||||
|
||||
If you need network access to copy the uninstall script to the HVM, use *Safe Mode with Networking* instead of pure Safe Mode (replace `minimal` with `network` in the bcdedit commands above). Disable the Xen PV network device first. You may need to manually configure IP settings for the emulated Realtek adapter.
|
||||
|
||||
|
||||
The uninstall script
|
||||
====================
|
||||
|
||||
Save it as a .BAT file in the HVM and run in Safe Mode.
|
||||
|
||||
~~~
|
||||
@echo off
|
||||
|
||||
:: This batch file uninstalls Qubes Tools for Windows version 2.x
|
||||
:: Needs to be run in safe mode
|
||||
|
||||
:: Registry cleanup
|
||||
reg delete "HKLM\Software\Invisible Things Lab" /f
|
||||
|
||||
:: services/drivers
|
||||
reg delete HKLM\System\CurrentControlSet\Services\ShutdownMon /f
|
||||
reg delete HKLM\System\CurrentControlSet\Services\QrexecAgent /f
|
||||
reg delete HKLM\System\CurrentControlSet\Services\QTWHelper /f
|
||||
reg delete HKLM\System\CurrentControlSet\Services\QubesNetworkSetup /f
|
||||
reg delete HKLM\System\CurrentControlSet\Services\QVideo /f
|
||||
reg delete HKLM\System\CurrentControlSet\Services\XenNet /f
|
||||
reg delete HKLM\System\CurrentControlSet\Services\XenPCI /f
|
||||
reg delete HKLM\System\CurrentControlSet\Services\XenVbd /f
|
||||
|
||||
:: xenpci filter entries
|
||||
reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f
|
||||
reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318} /v UpperFilters /f
|
||||
reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f
|
||||
|
||||
:: files
|
||||
rmdir /q /s "%ProgramFiles%\Invisible Things Lab"
|
||||
rmdir /q /s "%ProgramFiles%\Xen PV Drivers"
|
||||
|
||||
del /q /s "%windir%\system32\move-profiles.exe"
|
||||
del /q /s "%windir%\system32\windows-utils.dll"
|
||||
del /q /s "%windir%\system32\qvgdi.dll"
|
||||
del /q /s "%windir%\system32\drivers\qvmini.sys"
|
||||
del /q /s "%windir%\system32\drivers\xennet.sys"
|
||||
del /q /s "%windir%\system32\drivers\xenpci.sys"
|
||||
del /q /s "%windir%\system32\drivers\xenvbd.sys"
|
||||
|
||||
:: driver store entries
|
||||
FOR /F "delims=. tokens=1" %%I IN ('DIR /B "%SYSTEMROOT%\INF\OEM*.INF"') DO (
|
||||
TYPE "%SYSTEMROOT%\INF\%%I.inf" | FIND /c /i "Xen GPL PV" >%TEMP%\qtwuninstall
|
||||
FOR /f %%c IN (%TEMP%\qtwuninstall) DO (
|
||||
IF /I %%c NEQ 0 (
|
||||
DEL "%SYSTEMROOT%\INF\%%I.inf"
|
||||
DEL "%SYSTEMROOT%\INF\%%I.pnf"
|
||||
)
|
||||
)
|
||||
)
|
||||
|
||||
FOR /F "delims=. tokens=1" %%I IN ('DIR /B "%SYSTEMROOT%\INF\OEM*.INF"') DO (
|
||||
TYPE "%SYSTEMROOT%\INF\%%I.inf" | FIND /c /i "Qubes" >%TEMP%\qtwuninstall
|
||||
FOR /f %%c IN (%TEMP%\qtwuninstall) DO (
|
||||
IF /I %%c NEQ 0 (
|
||||
DEL "%SYSTEMROOT%\INF\%%I.inf"
|
||||
DEL "%SYSTEMROOT%\INF\%%I.pnf"
|
||||
)
|
||||
)
|
||||
)
|
||||
|
||||
echo.
|
||||
echo Cleanup finished. Please manually uninstall Qubes Video and Xen devices from the Device Manager.
|
||||
~~~
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: WindowsAppVms
|
||||
permalink: /en/doc/windows-appvms/
|
||||
redirect_from:
|
||||
- /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 Support tools inside the VM. This page describes this process in detail.
|
||||
|
||||
Qubes support tools for Windows is 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 (available on Qubes R2 Beta 3 and later)
|
||||
- Support for [secure clipboard copy/paste](/en/doc/copy-paste/) between the Windows VM and other AppVMs
|
||||
- Support for [secure file exchange](/en/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 Support Tools are not open source and are distributed under a commercial license and their source code is not publicly available. Current status is: **Beta**.
|
||||
|
||||
NOTE: Currently only 64-bit versions of Windows 7 are support by Qubes Windows Tools.
|
||||
|
||||
Installing Windows OS in a Qubes VM
|
||||
-----------------------------------
|
||||
|
||||
Please refer to [this page](/en/doc/hvm-create/) for instructions on how to install Windows in a Qubes VM.
|
||||
|
||||
Installing Qubes support tools in Windows 7 VMs
|
||||
-----------------------------------------------
|
||||
|
||||
First, make sure that `qubes-windows-tools` is installed in your system:
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update 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 even though the Qubes Windows Tools are proprietary, 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.
|
||||
|
||||
To install the Qubes Windows support 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.
|
||||
|
||||
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 Support Tools are not digitally signed with a publicly recognizable certificate. How to do that is explained in the `README` file also located on the installation CDROM. 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, and also to accept a few scary looking warning windows during the installation process, as shown below.
|
||||
|
||||
|
||||
|
||||
After successful installation, the Windows VM must be shut down and started again.
|
||||
|
||||
Qubes (R2 Beta 3 and later releases) 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>
|
||||
~~~
|
||||
|
||||
Using Windows AppVMs in seamless mode (Qubes R2 Beta 3 and later)
|
||||
-----------------------------------------------------------------
|
||||
|
||||
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 http://www.invisiblethingslab.com
|
||||
~~~
|
||||
|
||||
... just like in case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Forcing Windows AppVM into full desktop mode
|
||||
--------------------------------------------
|
||||
|
||||
You can switch between seamless and "full desktop" mode for Windows HVMs in their settings in Qubes Manager.
|
||||
|
||||
Using template-based Windows AppVMs (Qubes R2 Beta 3 and later)
|
||||
---------------------------------------------------------------
|
||||
|
||||
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just like it is done 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:
|
||||
|
||||
~~~
|
||||
qvm-create --hvm-template win7-x64-template -l green
|
||||
~~~
|
||||
|
||||
... and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see [this page](/en/doc/hvm-create/) instructions. However, it would make lots of 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 Windows-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide setting are stored in the root filesystem (which holds the system-wide registry hives).
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on:
|
||||
|
||||
~~~
|
||||
qvm-create --hvm <new windows appvm name> --template <name of template vm> --label <label color>
|
||||
~~~
|
||||
|
|
@ -1,103 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: WindowsTools2
|
||||
permalink: /en/doc/windows-tools-2/
|
||||
redirect_from:
|
||||
- /doc/WindowsTools2/
|
||||
- /wiki/WindowsTools2/
|
||||
---
|
||||
|
||||
Qubes Tools for Windows: 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.*
|
||||
|
||||
Installable components
|
||||
----------------------
|
||||
|
||||
Qubes Tools for Windows (QTW for short) contain several components than can be enabled or disabled during installation:
|
||||
|
||||
- Xen GPL PV drivers (required): drivers for the hardware exposed by Xen.
|
||||
- Core Windows Agent: qrexec agent and services. Needed for proper integration with Qubes.
|
||||
- Move user profiles: User profiles directory (c:\\Users) will be moved into the private disk backed by private.img. This disk will be initialized/formatted automatically if needed. This feature is useful for Windows-based HVM templates, so child AppVMs can have their separate user profiles.
|
||||
- GUI Windows Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop.
|
||||
- Disable UAC: disables User Account Control prompts. *Is this still needed/wanted? Gui agent can handle UAC prompts now.*
|
||||
|
||||
**In testing VMs only** it's probably a good idea to install a VNC server before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
|
||||
|
||||
Verbose installation
|
||||
--------------------
|
||||
|
||||
If the install process fails you can retry it using the command line below to get a detailed installation log (and send that to us):
|
||||
|
||||
`msiexec /i path-to-qubes-tools.msi /lv path-to-log-file.txt`
|
||||
|
||||
Uninstalling
|
||||
------------
|
||||
|
||||
See [this page](/en/doc/uninstalling-windows-tools-2/).
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Starting from version 2.2.\* various aspects of Qubes Tools for Windows can be configured through registry. Main configuration key is located in `HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools`. Configuration values set on this level are global to all QTW components. It's possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are:
|
||||
|
||||
|**Name**|**Type**|**Description**|**Default value**|
|
||||
|:-------|:-------|:--------------|:----------------|
|
||||
|LogDir|String|Directory where logs are created|c:\\Program Files\\Invisible Things Lab\\Qubes OS Windows Tools\\log|
|
||||
|LogLevel|DWORD|Log verbosity (see below)|2 (INFO)|
|
||||
|LogRetention|DWORD|Maximum age of log files (in seconds), older logs are automatically deleted|604800 (7 days)|
|
||||
|
||||
Possible log levels:
|
||||
|
||||
||
|
||||
|0|Error|Serious errors that most likely cause irrecoverable failures|
|
||||
|1|Warning|Unexpected but non-fatal events|
|
||||
|2|Info|Useful information|
|
||||
|3|Debug|Internal state dumps for troubleshooting|
|
||||
|4|Verbose|Trace most function calls|
|
||||
|
||||
Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only.
|
||||
|
||||
To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without `.exe` extension. For example, to change qrexec-agent's log level to Debug, set it like this:
|
||||
|
||||
|
||||
|
||||
Component-specific settings currently available:
|
||||
|
||||
|**Component**|**Setting**|**Type**|**Description**|**Default value**|
|
||||
|:------------|:----------|:-------|:--------------|:----------------|
|
||||
|wga|UseDirtyBits|DWORD|Enable experimental feature of the gui agent/qvideo driver: use page table dirty bits to determine changed display regions. This can improve performance but may impact display responsiveness (some changes may not be detected resulting in "stale" image). Needs VM restart to apply change.|0|
|
||||
|wga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since wga is restarted on desktop change).|1|
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
|
||||
|
||||
- `qvm-start --debug vmname`
|
||||
- mash F8 on the boot screen to enable boot options and select Safe Mode (optionally with networking)
|
||||
|
||||
Safe Mode should at least give you access to logs (see above).
|
||||
|
||||
**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QTW version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events.
|
||||
|
||||
If a specific component is malfunctioning, you can increase it's log verbosity as explained above to get more troubleshooting information. Below is a list of components:
|
||||
|
||||
||
|
||||
|qrexec-agent|Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.|
|
||||
|qrexec-client-vm|Used for communications by the qrexec protocol.|
|
||||
|wga|Gui agent.|
|
||||
|QTWHelper|Service that monitors session/desktop changes (logon/logoff/locking/UAC...) and simulates SAS sequence (ctrl-alt-del).|
|
||||
|prepare-volume|Utility that initializes and formats the disk backed by `private.img` file. It's registered to run on next system boot during QTW setup, if that feature is selected (it can't run *during* the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.|
|
||||
|move-profiles|Utility that moves user profiles directory to the private disk. It's registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: `c:\move-profiles.log` (it can't use our common logger library so none of the log settings apply).|
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
When we publish new QTW version (which is announced on `qubes-users` Google Group) it's usually pushed to the `current-testing` repository first. To use versions from current-testing, run this in dom0:
|
||||
|
||||
`qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools`
|
||||
|
||||
That command will download a new QTW .iso from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos.
|
||||
|
|
@ -1,109 +0,0 @@
|
|||
---
|
||||
layout: doc
|
||||
title: WindowsTools
|
||||
permalink: /en/doc/windows-tools-3/
|
||||
redirect_from:
|
||||
- /doc/WindowsTools3/
|
||||
- /wiki/WindowsTools/
|
||||
redirect_from:
|
||||
-
|
||||
- /doc/WindowsTools/
|
||||
---
|
||||
|
||||
Qubes Tools for Windows: 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.*
|
||||
*HVM templates are not supported yet. Specifically, user profiles are not yet moved to a VM's private image (fix incoming).*
|
||||
|
||||
Installable components
|
||||
----------------------
|
||||
|
||||
Qubes Tools for Windows (QTW for short) contain several components than can be enabled or disabled during installation:
|
||||
|
||||
- Shared components (required): common libraries used by QTW components.
|
||||
- Xen PV drivers: drivers for the virtual hardware exposed by Xen.
|
||||
- Base Xen PV Drivers (required): paravirtual bus and interface drivers.
|
||||
- Xen PV Disk Drivers: paravirtual storage drivers.
|
||||
- Xen PV Network Drivers: paravirtual network drivers.
|
||||
- Qubes Core Agent: qrexec agent and services. Needed for proper integration with Qubes.
|
||||
- Qubes GUI Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop.
|
||||
|
||||
**In testing VMs only** it's probably a good idea to install a VNC server before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
|
||||
|
||||
Verbose installation
|
||||
--------------------
|
||||
|
||||
If the install process fails you can retry it using the command line below to get a detailed installation log (and send that to us):
|
||||
|
||||
`msiexec /i path-to-qubes-tools.msi /lv path-to-log-file.txt`
|
||||
|
||||
Uninstalling QTW 3.x is **not recommended**. It will most likely make the OS non-bootable because drivers for Xen storage devices will be uninstalled. This will be fixed in the future.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Starting from version 2.2.\* various aspects of Qubes Tools for Windows can be configured through registry. Main configuration key is located in `HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools`. Configuration values set on this level are global to all QTW components. It's possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are:
|
||||
|
||||
|**Name**|**Type**|**Description**|**Default value**|
|
||||
|:-------|:-------|:--------------|:----------------|
|
||||
|LogDir|String|Directory where logs are created|c:\\Program Files\\Invisible Things Lab\\Qubes Tools\\log|
|
||||
|LogLevel|DWORD|Log verbosity (see below)|2 (INFO)|
|
||||
|LogRetention|DWORD|Maximum age of log files (in seconds), older logs are automatically deleted|604800 (7 days)|
|
||||
|
||||
Possible log levels:
|
||||
|
||||
||
|
||||
|0|Error|Serious errors that most likely cause irrecoverable failures|
|
||||
|1|Warning|Unexpected but non-fatal events|
|
||||
|2|Info|Useful information|
|
||||
|3|Debug|Internal state dumps for troubleshooting|
|
||||
|4|Verbose|Trace most function calls|
|
||||
|
||||
Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only.
|
||||
|
||||
To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without `.exe` extension. For example, to change qrexec-agent's log level to Debug, set it like this:
|
||||
|
||||
|
||||
|
||||
Component-specific settings currently available:
|
||||
|
||||
|**Component**|**Setting**|**Type**|**Description**|**Default value**|
|
||||
|:------------|:----------|:-------|:--------------|:----------------|
|
||||
|qga|UseDirtyBits|DWORD|Enable experimental feature of the gui agent/qvideo driver: use page table dirty bits to determine changed display regions. This can improve performance but may impact display responsiveness (some changes may not be detected resulting in "stale" image). Needs VM restart to apply change.|0|
|
||||
|qga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).|1|
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
|
||||
|
||||
- `qvm-start --debug vmname`
|
||||
- mash F8 on the boot screen to enable boot options and select Safe Mode (optionally with networking)
|
||||
|
||||
Safe Mode should at least give you access to logs (see above).
|
||||
|
||||
**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QTW version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from c:\Windows.
|
||||
Xen logs (/var/log/xen/console/guest-*) are also useful as they contain pvdrivers diagnostic output.
|
||||
|
||||
If a specific component is malfunctioning, you can increase it's log verbosity as explained above to get more troubleshooting information. Below is a list of components:
|
||||
|
||||
||
|
||||
|qrexec-agent|Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.|
|
||||
|qrexec-client-vm|Used for communications by the qrexec protocol.|
|
||||
|qga|Gui agent.|
|
||||
|QgaWatchdog|Service that monitors session/desktop changes (logon/logoff/locking/UAC...) and simulates SAS sequence (ctrl-alt-del).|
|
||||
|qubesdb-daemon|Service for accessing Qubes configuration database.|
|
||||
|network-setup|Service that sets up network parameters according to VM's configuration.|
|
||||
|prepare-volume|Utility that initializes and formats the disk backed by `private.img` file. It's registered to run on next system boot during QTW setup, if that feature is selected (it can't run *during* the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.|
|
||||
|move-profiles|Utility that moves user profiles directory to the private disk. It's registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: `c:\move-profiles.log` (it can't use our common logger library so none of the log settings apply).|
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
When we publish new QTW version (which is announced on `qubes-users` Google Group) it's usually pushed to the `current-testing` or `unstable` repository first. To use versions from current-testing, run this in dom0:
|
||||
|
||||
`qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools`
|
||||
|
||||
That command will download a new QTW .iso from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos.
|
||||
Loading…
Add table
Add a link
Reference in a new issue