IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Virt-manager doesn't consider CPU pinning settings in the Processor tab yet so
this is the patch to provide CPU pinning support for virt-manager. It's using
only CPU definition for libvirt itself and it doesn't support CPU pinning for
domains that are currently in running state since this feature will be rarely
used for already running domains in my opinion.
The behavior is opt in via preferences, off by default. The icon allows
starting, stopping, and pausing VMs, opening console/details, and quiting the
entire app.
VCPU count is pointless to have in the main view. ID is similarly pointless,
its only value being that it showed the connection driver, which is now
part of the connection name.
Memory is the only useful field here, but even it's prescence is dubious:
there isn't much value in seeing at a glance what memory amounts VMs
are statically defined with.
A toolbar at the top is much more in line with existing UI convention, and is
more intuitive. Delete is dropped from the upfront buttons (since this likely
isn't a common operation), and buttons for shutdown and pause are added.
This allows us to get many more relevant icons (mouse, tablet, sound card).
Also, reorganize the virtual network and hardware lists to have icons appear
first in the row.
Key of URI in the migration list, not the short hostname we show: we can
have multiple connections with the same hostname, and it confuses things. This
allows us to drop the migrate invocation differences for the xen driver,
so things work as they should.
Since libvirt has supported multithreaded client connections for a while now,
we can run all our libvirt polling in a thread. This will prevent the UI
from blocking and becoming sluggish if there are lots of VMs or connections
open.
We just need to be vigilant in ensuring that all UI updating done via any
tick function is scheduled with gobject.idle_add, to preserve the benefits.
We need to parse the XML doc when polling for disk and net stats. However,
it isn't that important for us to have up2date xml when doing so: having a
disk or net device added behind our back is likely a rare occurence, and
the xml will be updated via other means quite often.
So, don't update the xml.
