Run VM apps at low process priority

[davidpanderson]

Currently VM apps (i.e. vbox_headless.exe) run at normal process priority.
This slows down system response; they should run at low priority.

I recall that VBox has no provision for running VMs at low priority.
If this is still the case, perhaps the client can identify VM processes
and lower the priority itself.

[lfield]

Duplicate of #2273 but proposes a different solution.

[davidpanderson]

Goals:

1. stagger the start of VM apps at client startup
   currently they can saturate I/O when several start at once
2. lower the priority of VM apps.
   currently they run at normal process priority

Challenge:
There is AFAIK no way to find the process IDs of the VMs the client starts,
so that we can distinguish them from other VMs

Proposal:

1. Staggering:
   a) wait 30 sec before starting any VM app
   b) wait 15 sec between starting VM apps

2. lowering priority:

Add to ACTIVE_TASK
double start_time: when started
bool demoted: VM job; has been demoted

When we enumerate processes (procinfo_setup())
make a list of the processes running VBoxheadless.exe.
Do this at startup, before we start any jobs.

Subsequently, we enumerate all processes every 10 sec.
for each VM process P not in previous VM list
look for an active VM task T that
- was started after the previous process scan
- has not been demoted;
find the earliest such.
lower its priority; flag as demoted

This isn't foolproof; it may demote non-BOINC VMs or fail to demote BOINC VMs.

[JuhaSointusalo]

1. stagger the start of VM apps at client startup
   currently they can saturate I/O when several start at once

There is an older ticket open for staggered startup of tasks. #1293

2. lower the priority of VM apps.
   currently they run at normal process priority

VirtualBox locks down the VM process pretty tight. If I try to change the priority of the process that is really running the VM all I get back is Access denied. It would seem to me that the only really working way to control the priority of VM tasks is implementing the control in VirtualBox as #2273 says.

Since it's not possible to implement both of the goals of this ticket at the same time (different code bases and all that) I would suggest that this ticket is closed and David copies the proposed implementation of staggered startup to #1293. This is so that

1. we don't have duplicate issues
2. the tickets can be closed as soon as they are done instead of having our backlog full of half completed tickets

[AenBleidd]

@davidpanderson, correct me if I'm wrong but looking at the implementation of vbox_wrapper I see that it saves PID of VBoxHeadless process:

boinc/samples/vboxwrapper/vbox_common.cpp

Lines 1103 to 1107 in 9942a6d

	if (pi.hProcess && (ulExitCode == STILL_ACTIVE)) {
	vm_pid = pi.dwProcessId;
	vm_pid_handle = pi.hProcess;
	retval = BOINC_SUCCESS;
	}

boinc/samples/vboxwrapper/vbox_common.cpp

Lines 1115 to 1133 in 9942a6d

	int pid = fork();
	if (-1 == pid) {
	vboxlog_msg(
	"Status Report: Launching virtualbox/vboxheadless failed!."
	);
	vboxlog_msg(
	" Error: %s (%d)",
	strerror(errno),
	errno
	);
	retval = ERR_FORK;
	} else if (0 == pid) {
	if (-1 == execv(argv[0], argv)) {
	_exit(errno);
	}
	} else {
	vm_pid = pid;
	retval = BOINC_SUCCESS;
	}

Even if this PID is pointed not to the exact process that running the VM, I guess, using it we can find child processes and find necessary one.
And this will not affect other VBox instances that are run by someone else