GNOME Bugzilla – Bug 684801
Don't blank the screen when running as a virtual machine
Last modified: 2012-11-20 22:45:39 UTC
If you are running GNOME as a virtual machine, automatically blanking the screen isn't very useful, and can get in the way of what the user is trying to do. In these situations we should make sure that the screen isn't blanked, and that the screen blank settings are not exposed in System Settings.
The only problem being, how do we detect that we're running inside a virtual machine?
(In reply to comment #1) > The only problem being, how do we detect that we're running inside a virtual > machine? A little bird told me that systemd will provide...
From http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface: If you write software that wants to detect whether it is run in a container, please check /proc/1/environ and look for the container= environment variable. Do not assume the environment variable is inherited down the process tree. It generally is not. Hence check the environment block of PID 1, not your own.
(In reply to comment #3) > From http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface: > > If you write software that wants to detect whether it is run in a container, > please check /proc/1/environ and look for the container= environment variable. > Do not assume the environment variable is inherited down the process tree. It > generally is not. Hence check the environment block of PID 1, not your own. Is a container a VM? If I run within GNOME Boxes, VMWare or VirtualBox, is that a container?
(In reply to comment #4) > (In reply to comment #3) > > From http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface: > > > > If you write software that wants to detect whether it is run in a container, > > please check /proc/1/environ and look for the container= environment variable. > > Do not assume the environment variable is inherited down the process tree. It > > generally is not. Hence check the environment block of PID 1, not your own. > > Is a container a VM? If I run within GNOME Boxes, VMWare or VirtualBox, is that > a container? I can't answer that, but should be easily testable (at least for boxes).
container= is only for containers, not for VMs such as vmware/vbox/qemu. For GNOME we probably want to detect both containers and VM. Unfortunately not all containers/VMs can be detected without privileges. In systemd we ship a tool "systemd-detect-virt" which will detect the VM and container solution. We could make this tool SUID (or use FS caps) so that unprivileged users can use it to detect VMs. Then "systemd-detect-virt -q" could be invoked by GNOME and if it returns 0 then you know you run in a container/VM. If its not desirable to invoke an external process for this I could add this to the D-Bus interfaces of either PID 1 or hostnamed.
Thinking about it I think it would be much nicer to expose this in hostnamed. Opinions?
(In reply to comment #5) > I can't answer that, but should be easily testable (at least for boxes). No, I don't think a full qemu system is a container at all. I was going to suggest "virt-what" which is a shell script to detect all manner of virt, but it seems to not detect qemu when it's being used with KVM. It uses a heuristic to detect some kind of timing wonkyness that might suggest the host is running in a VM. Not ideal at all, but it might be the best we've got.
(In reply to comment #7) > Thinking about it I think it would be much nicer to expose this in hostnamed. > Opinions? Yes, that's much easier from a g-s-d point of view.
(In reply to comment #9) > (In reply to comment #7) > > Thinking about it I think it would be much nicer to expose this in hostnamed. > > Opinions? > > Yes, that's much easier from a g-s-d point of view. Not sure hostnamed is the best place (I'd rather have a separate interface), but as long as we don't need to have the heuristics done ourselves, I'm fine with it.
So I decided to add this to PID1's bus apis after all, not to hostnamed. PID 1 detects and caches this value anyway, and hence we should just export this on the bus for unprivileged processes. This is now in systemd git, most likely will end up in F18, too. $ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1 --method org.freedesktop.DBus.Properties.Get "org.freedesktop.systemd1.Manager" "Virtualization" (<'kvm'>,) I also documented this in systemd's Wiki: http://www.freedesktop.org/wiki/Software/systemd/dbus GNOME should just check this new string property. If it is the empty string we are running on bare-metal. If it is a non-empty string it is an ID for the virtualization tech used (btw: might be something to show in gnome system info?).
nice idea, filed as bug 685531
Created attachment 227244 [details] [review] test patch for initial review What about something like this? I've not disabled the timer stuff for VMs as I didn't want wildly different code paths, and that testing the idle stuff on a VM is something I do occasionally. I've also left suspend-on-machine-idle enabled, is that something we want?
(In reply to comment #13) > Created an attachment (id=227244) [details] [review] > test patch for initial review > > What about something like this? I've not disabled the timer stuff for VMs as I > didn't want wildly different code paths, and that testing the idle stuff on a > VM is something I do occasionally. Sounds fine. > I've also left suspend-on-machine-idle enabled, is that something we want? Probably not, no.
(In reply to comment #14) > (In reply to comment #13) > > I've also left suspend-on-machine-idle enabled, is that something we want? > > Probably not, no. Okay, I've disabled this as well. I've pushed this to master: commit 0a8576628455760235bfb7586be6d040879905e0 Author: Richard Hughes <richard@hughsie.com> Date: Thu Oct 25 12:12:17 2012 +0100 power: Do not attempt to suspend, dim or blank if running as a virtual machine Resolves: https://bugzilla.gnome.org/show_bug.cgi?id=684801 You need a fairly new version (e.g. F18) of systemd to make it work. If there are no complaints and no problems we can maybe (comments?) merge it to 3-6 too as there are no new strings.
I understand why this change was proposed, but I have two concerns: 1) I plan to use VMs as a testing tool, and having the system behave differently makes it more likely that bugs will make it to people who actually run GNOME on bare metal. Especially bugs in subsystems like this. 2) Some people want to deploy GNOME in VMs by default, where the host is just a thin hypervisor. In this scenario, they often want behaviors that make the system feel like a "real" host. Anyways, If we go this way, I'd really like a GNOME-global switch to disable any special behaviors when run as a VM. Maybe gnome-settings-daemon should have a gsettings key "enable-virtualization-customization"? It could default to true.
Then please file a separate bug so we can discuss this. No point in discussing it in a bug that's already fixed.
(In reply to comment #17) > Then please file a separate bug so we can discuss this. No point in discussing > it in a bug that's already fixed. But...file it where? (This is one of the shitty things about bugzilla, you have to pick some arbitrary component for a "bug"). I dunno. Let's pick gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=688759