Windows documentation / reorganization, fixes and new content #600
Conversation
* new links * short explanation about install, QWT, ...
- remove duplicated content about ISOs in dom0, appVMs, ... - remove references to windows VMs - add link to windows VM new page
|
I have read all files. Looking good... Few personal comments: In windows-vm.md@175-214 should be moved to windows-tools and a simple link provided here In windows-vm.md@222-245, should be condensed (as the user is after the condensed version here with minimum to set), and provided at the top (it just works if people follow these instructions AFAIK) A lot of comments, but there was a lot of work to restructure a part of the doc that was very confusing. +1 from me. |
@taradiddles had it at the top originally but it made the doc look a bit cluttered, so we moved them to the end with a link. Maybe the condensed version of them wouldn't look so "busy". |
I'm quite sure it's
I already had a 'win7' VM imported from 3.2 and thought that people may too. So if they are to copy/paste instructions, 'win7new' made more sense than 'win7' and having to search/replace the vm's name. Renaming the VM is then a simple matter through the gui or two commands in dom0.
Yes, that's from the post by Marek linked a few lines below.
Shouldn't make a difference but OK to change them.
I don't agree: you can install PV drivers without installing QWT (eg. for win10 VMs) and the qrexec timeout instruction is needed without QWT for stuff like chkdsk.
I thought that too but I wanted to avoid duplicates (like 'QWT is unstable' in the QWT page, and 'QWT is unstable' in the windows page).
See https://github.com/taradiddles/qubes-notes/wiki/test-page One version has a horizontal scrollbar (personally I don't like those), the other version is line escaped and IMO looks as much cluttered as the original version, while being more error-prone.
Thank you :) |
|
@taradiddles, I am not able to reply in line like you do. Probably a github noob issue or maybe because I am not PR owner... anyway In regards to the PV, at this point in time, I feel that it depends if the system is stable with them. My experience has been to have a usable and stable win7 without (just the qvm-create+prefs+features, install win7, features-unset+qrexec-timeout). An option could be to put this is a post-install section (tweaks, PV, QWT ref)? same as you in general I don't mind and happy to follow what @awokd and others think. However having a clear line between what is stable and not, is I feel important. On the condensed, you are right, it looks better. |
You have to copy/paste the text you're replying to and insert a leading
It is stable in my case but I don't use Windows often so it doesn't really prove anything. I agree that adding a warning about stability could be helpful.
That's what I first wanted to do but I couldn't find how to create sub-sub-sections with Qubes' markdown coding guidelines (ie. how to write the equivalent of |
|
fyi, reworked the 'Xen PV drivers + Qubes integration' section in the last commit |
OK, makes sense. I would have put 'tweaks' and move 'pv drivers' + 'qwt' in the qwt page. But you have more experience than me with the PV install, so fine with me. |
|
A note about memory balancing: we make sure it's disabled during install by setting memory = maxmen but there's no mention about it after install. The qmemman doc implies that memory balancing works with Windows but under 4.0rc4, with memory < maxmem and memwriter enabled in the services tab, the VM crashes when the used memory reaches the 'memory' VM's value - eg. it looks like memory isn't increased automatically. I don't see any meminfo-writer process in the list of running processes, I don't know whether it's because of yet another issue with QWT under 4.0 or if memory balancing was broken in 3.2 too. Q: add a paragraph about memory balancing assuming it's working (ie. memory < maxmen + enable meminfo-writer) and file an issue ? Or add a note that memory balancing simply doesn't work, and that one has to set memory = maxmem ? |
Suggest this for now. Could also file an issue and link to it with the same note. Not seeing that process on Win7 on R3.2 either. |
(2000/4000Mo -> 2048/4096Mo)
managing-os/hvm.md
Outdated
|
|
||
| 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 "HVM" type. |
There was a problem hiding this comment.
On R4 there is no "HVM" type in that dialog. Instead, one should choose "Standalone qube not based on a template". If "install system from device" is selected (which is by default), then virt_mode will be set to hvm automatically.
managing-os/hvm.md
Outdated
|
|
||
| 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: | ||
|
|
||
|  | ||
| [](/attachment/wiki/HvmCreate/r2b1-win7-installing.png) |
There was a problem hiding this comment.
Looks like unintended image change.
There was a problem hiding this comment.
unintended, + problem with mass renaming. fixed.
managing-os/hvm.md
Outdated
|
|
||
| **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. | ||
| Only IPv4 networking is currently supported in Qubes. |
There was a problem hiding this comment.
This is no longer true: https://www.qubes-os.org/doc/networking/#ipv6
There was a problem hiding this comment.
updated notes ; fwiw that line is from the existing doc, maybe I should have checked that the current instructions aren't true anymore with R4.0
managing-os/hvm.md
Outdated
| @@ -295,11 +200,82 @@ HVM domains (including Windows VMs) can be [assigned PCI devices](/doc/assigning | |||
|
|
|||
| 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) | |||
| [](/attachment/wiki/HvmCreate/r2b1-my-new-vm-usb-disable.png) | |||
There was a problem hiding this comment.
Unless you want to rename files in qubes-attachment repository, keep original name here.
There was a problem hiding this comment.
same here ; fixed (also removed the (/attachment/wiki/HvmCreate/r2b1-win7-usb-disable.png) duplication.)
managing-os/hvm.md
Outdated
| Copy file to Dom0: | ||
|
|
||
| ~~~ | ||
| qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /var/lib/qubes/appvms/win10/root.img |
There was a problem hiding this comment.
This will work only for R3.2 - on R4.0 by default LVM is used. On the other hand, if you copy that image to some temporary place (/home/user ?), then use qvm-create ... --root-move-from=..., then it will work on both versions.
There was a problem hiding this comment.
I see; they were not part of my instructions, I simply moved them to the end of the page without even looking at them. I fixed the instructions with your suggestion.
managing-os/windows/windows-vm.md
Outdated
| qvm-prefs win7new kernel '' | ||
| ~~~ | ||
|
|
||
| A typical Windows 7 installation requires between 15Go up to 19Go 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 10Go to 25Go (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). |
There was a problem hiding this comment.
my mistake - I'm used to the french way of writing GB. (if you're wondering, the 'o' is from 'octet' which means 'byte').
fixed...
managing-os/windows/windows-vm.md
Outdated
| R4.0: | ||
| ~~~ | ||
| qvm-prefs win7new debug true | ||
| ~~~ |
managing-os/windows/windows-vm.md
Outdated
| ~~~ | ||
| qvm-prefs win7new memory 2048 | ||
| qvm-prefs win7new maxmem 2048 | ||
| ~~~ |
managing-os/windows/windows-vm.md
Outdated
| R4.0: | ||
| ~~~ | ||
| qvm-prefs win7new qrexec_timeout 300 | ||
| ~~~ |
managing-os/windows/windows-vm.md
Outdated
| R4.0: | ||
| ~~~ | ||
| qvm-prefs win7new debug false | ||
| ~~~ |
ghost
mentioned this pull request
|
@marmarek fyi I've changed the doc as requested some time ago ; I only commented in the change requests, not here, so maybe you didn't receive notifications. Or more likely, you're too busy with the R4.0 release :) |
|
just saw https://www.qubes-os.org/doc/doc-guidelines/#version-specific-documentation I've refactored the doc accordingly - see the following page; if it looks OK I'll push a commit to https://github.com/taradiddles/qubes-doc/blob/master/managing-os/windows/windows-vm-test.md |
| 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=/" /var/lib/qubes/appvms/win7new/win7new.conf | ||
| qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new |
There was a problem hiding this comment.
Shouldn't this use copied config in /tmp (qvm-start --custom-config=...)? Also sed should operate on that config copy. The /var/lib/qubes/appvms/win7new/win7new.conf config is regenerated before each VM start.
There was a problem hiding this comment.
Shouldn't this use copied config in /tmp (qvm-start --custom-config=...)?
No: the file copied to /tmp is a backup that we're supposed to restore later on with cp /tmp/win7new.conf /var/... ; but given your comment below I see that's not a good idea.
The /var/lib/qubes/appvms/win7new/win7new.conf config is regenerated before each VM start.
I didn't know that. Out of curiosity, where does Qubes get the VM's "real" settings from then ? I don't have R3.2 anymore to test unfortunately....
Anyway, I've updated the doc to use qvm-start --custom-config= ; I initially wanted to avoid that because users might forget about it and only run qvm-start but I guess they'll have to stick to the doc :)
Hopefully I didn't forget anything (+ fixed the tail -f remark).
There was a problem hiding this comment.
I didn't know that. Out of curiosity, where does Qubes get the VM's "real" settings from then ?
From qubes.xml, basically what you see in qvm-prefs. In fact the .conf file in VM's directory isn't used at all, qvm-start write there the same thing that is sent to libvirt, just to ease modification. And unless you specify --custom-config, with a different path, actual config is built on each VM start.
There was a problem hiding this comment.
Thanks for the clarification.
The last version of the doc should be OK then (for 3.2, the instructions use qvm-start --custom-config=/tmp/vmname.conf, where the conf file in /tmp has been modified to use the cirrus video adapter).
| ~~~ | ||
| tail -f /var/log/qubes/vm-win7new.log | ||
| tail -f /var/log/xen/console/hypervisor.log | ||
| tail -f /var/log/xen/console/guest-win7new-dm.log |
There was a problem hiding this comment.
Hint: you can pass multiple files to tail -f, then you'll have nice monitoring of all those files in one window.
+ improve 'tail -f' debug command + use qvm-start --custom-config=/tmp/win7new.conf instead of changing the original file
A lot of modifications and additions here - likely not a good idea for a 1st PR attempt but I didn't find how to split the PR into several ones (git noob here).
qvm-start --cdromstuffI'm not sure I got the header part right on the pages. I also didn't find a way to test the http links on github, hopefully they're OK.
No problem to cherry-pick some of my commits and reject the PR of course...