Can you please provide higher resolutions for desktop and possibly have them on out of the box so all users configs conform to one another?
1024x768 is too limited for modern computer screens and so make little sense. They make reading in the workstation uncomfortable.
Two steps here.
We’re not done with step 1) yet.
Multiple parts here:
KVM:
a) What resolution are you able to choose at the moment?
b) Perhaps Higher Screen Resolution without VirtualBox Guest Additions will help as well. If you figure something out, we can ship such a config by default.
c) What do KVM manualy say about reaching desktop higher resolutions? Try.
The only resolution available inside Whonix is 1024x768
When following the resolution instructions you referred to, I get a very distorted desktop. One that is too big and needs scrolling around. In fullscreen mode everything becomes microscopic in size. This may be our only option though, but I’m not sure where to go from here.
Theonly documented waysto adjust resolution in KVM are either to do so with qemu-kvm commands directly outside of libvirt. Or to install spice-vdagent. The former is not advisable and the latter doesn’t do anything in my experience.
The only resolution available inside Whonix is 1024x768Next direction: Is this a Whonix specific issue or does this happen with plain Debian or other Linux distributions [in KVM] as well?
The former is not advisableWhy not?
Next direction: Is this a Whonix specific issue or does this happen with plain Debian or other Linux distributions [in KVM] as well?
I think its whonix specific. I can’t say about plain Debian but other distros I have installed have a list of options for screen resolutions.
Why not?
By not going through libvirt starting vms via gui won’t be possible anymore and we also lose protections libvirt provides.
Can you get a plain Debian KVM VM for comparison please? I guess we will be needing this quite often for all sorts of things.
I see. This cannot be set in libvirt… Sounds bad. You sure about this? Has this been discussed with libvirt devs?
So why can’t this be set using libvirt? Can’t libvirt pass arbitrary options to kvm? Looks like it can.
Can you get a plain Debian KVM VM for comparison please? I guess we will be needing this quite often for all sorts of things.
Sure. I got it now and will set it up.
I see. This cannot be set in libvirt... Sounds bad. You sure about this? Has this been discussed with libvirt devs?So why can’t this be set using libvirt? Can’t libvirt pass arbitrary options to kvm? Looks like it can.
- Search term: libvirt pass option to kvm
- Stefan Hajnoczi: How to pass QEMU command-line options through libvirt
I’ll ask.
Yes I remember discussing with you qemu command passthrough sometime back. Thanks for reminding me about this. I think its handy when we want to configure settings that libvirt doesn’t currently support. A pitfall of this is that it might be unstable because of constant API updates, but I think this is worth trying for a variety of reaons. Maybe it will allow us to turn off the microphone even though libvirt doesn’t support this.
Before I rely on it wholesale I’ll ask if this special feature is protected by sVirt. I know for a fact that direct qemu-kvm isn’t but this is different becuase is an integrated component in libvirt itself.
Another problem with passing through commands I just ran across is its’ need to fetch xml schema from an unencrypted link online. Unless I find a way to download and distribute the schema with a link to it locally, this is a showstopper.
t is necessary to issue an XML namespace request (the special xmlns:name attribute) that pulls in http://libvirt.org/schemas/domain/qemu/1.0; typically, the namespace is given the name of qemu. With the namespace in place, it is then possible to add an element under driver, with the following sub-elements repeated as often as needed:
Update: It my not be a good idea for security after al since we are using qemu commands that add devices instead of perform simple queries as the safe usecase mentioned in the reply
https://www.redhat.com/archives/libvir-list/2014-September/msg00288.html
After testing I am seeing 1024x768 is the highest resolution on Debian wheezy as well.
To summarize:
[quote=“HulaHoop, post:8, topic:471”]Another problem with passing through commands I just ran across is its’ need to fetch xml schema from an unencrypted link online. Unless I find a way to download and distribute the schema with a link to it locally, this is a showstopper.
Are you sure this really is the case? The documentation “pulls in” may be a bit misleading, but I don’t think it means a http request. Neither “XML namespace request” is a common phrase, let alone a phrase to mean “download from web”. If that were the case, I’d say, report a security bug. That link http://libvirt.org/schemas/domain/qemu/1.0 can’t even be opened in browser (broken page). I don’t think it depends on it. So most likely this is a bug in documentation.
I’ve searched libvirt.org for xmlns:name as well as xmlns but didn’t find a lot.
Found xmlns elsewhere:
Also doesn’t sound like “it downloads that content”.
[quote=“HulaHoop, post:9, topic:471”]Update: It my not be a good idea for security after al since we are using qemu commands that add devices instead of perform simple queries as the safe usecase mentioned in the reply
https://www.redhat.com/archives/libvir-list/2014-September/msg00288.html[/quote]
Doesn’t sound like a strong general warning. We would probably not be adding/removing devices. Changing resolution doesn’t sound like something that causes security issues. To be sure, if you found a command that would help here, ask on kvm list if that very use of qemu:commandline would be sane.
[quote=“HulaHoop, post:10, topic:471”]After testing I am seeing 1024x768 is the highest resolution on Debian wheezy as well.
To summarize:
One thing I forgot to mention yesteray. It seems that in other guests that have more resolution options, spice-vdagent comes installed with them - after I looked. Now even with that Debian does not see anything higher. I am confident this is a Debian bug
The only qemu commands I saw for playing around with resolution is the emulated ones like ‘vga’ and not qxl. qxl is dependent on spice-vdagent in this situation.
I am glad, but not surprised, it's not a Whonix introduced issue. Could you research please that Debian issue and/or ask on http://unix.stackexchange.com/ please?
ok
Got it working by changing graphics card from QXL to VMVGA
Got into settings then “Display and Monitor” size and orientation, a very large selection of resolutions became available.
1280x720 fills the screen and 1366x768 makes it hi-res.
We don’t have to switch to VMVGA, adding it as a secondary video card works too.
I can’t find the post where I told gh0st how to set up a vm with multiple graphics cards can you please see if you can find it? I want to add this to the configuration.
Already saw this forum function?
Should be somewhere there?
(When you click on a profile such as Whonix Forum there is a “Show Posts” button.)
Ok found it, however when trying to add multiple cards the xml rejects them. I asked on the libvirt list for instructions to do this and have it work.
https://www.redhat.com/archives/libvir-list/2014-September/msg01193.html
As per the libvirt list, turns out SPICE does support high resolutions, it was a matter of the QXL driver not being installed/setup in Debian though its included. After doing that I am able to have a full hi-res desktop 
Could you please include a configuration file out of the box for a stanard high resolution. I’m willing to test it out first.
The package involved: xserver-xorg-video-qxl