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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Because sata, usb and scsi use same device prefix: sd*, They will be
included into occupied list while we add virtio-scsi disks, This is
wrong and may cause adding additional virtio-scsi controller.
How to reproduce:
1. fresh install a qemu guest.
2. add 6 virtual USB disks.
3. add disk A on scsi bus.
(then a virtio-scsi controller 0 will be added automatically)
4. add disk B on scsi bus.
5. observe.
Expected:
disk A and disk B should be connected to virtio-scsi controller 0 because
controller 0 has enough available slots.
Actual:
disk A was connected to virtio-scsi controller 0.
An additional virtio-scsi controller 1 was added and disk B was connected
to it because virt-manager thought the virtio-scsi controller 0 doesn't
have available slot.
Signed-off-by: Lin Ma <lma@suse.com>
Fix all E125:
Continuation line with same indent as next logical line
Also remove ignore options of E125
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
The current order of check operations is wrong. First we set the new
path for the disk in question and after that we check whether some
guest already uses a disk with the same path.
The issue is that virt-manager returns a cached list of guests in
path_in_use_by() and the cached guest has the disk path already
updated.
Ideally we don't update the path at all, but we do it to run some
checks before the path is actually changed. In order to fix the
referenced bug, change the order of check operations.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1453094
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If initialization of new object fails we put it into blacklist and
newer parse it again until virt-manager is restarted. This helps to
reduce number of failures if some object fails initialization every
time.
However, there are some cases where we put object into blacklist
incorrectly. One of the cases is while creating new storage pool.
If the storage pool requires to be build before started but user
doesn't check to build it as well the start of the new storage pool
fails. The issue is that at first we define that object which triggers
a lifecycle event for storage pool and queues new poll operation over
storage pools. Before the poll operation starts the starting of the
storage pools fails and we undefine that storage pool before it is
initialized. The initialization fails and the storage pool is never
managed from that point.
This patch modifies the blacklist to allow 3 failures before we give up
on a specific object and if the object is initialized without error
we remove it from blacklist completely.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446486
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1093394
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Graphics devices has a new XML element to configure UNIX socket path:
<graphics type='vnc' socket='/path/to/socket'>
<listen type='socket' socket='/path/to/socket'/>
</graphics>
<graphics type='spice'>
<listen type='socket' socket='/path/to/socket'/>
</graphics>
and as you can see SPICE uses only the new XML element. For VNC the
old 'socket' attribute is for backward compatibility.
In order to connect to SPICE graphics on remote host using SSH tunnel
we need to get the UNIX socket path from <listen> element.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441127
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1488480
This also fixes an issue with floppy not showing at all, the proper
boot.dev name is 'fd' but we were looking for 'floppy'.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
There are multiple models of the panic device, the address type is only
one and is valid only for "isa" model.
To not break the virt-install/virt-xml the command line parser needs to
be updated. Before this patch there was only one parameter that
configured the "iobase". Now the first parameter configures a model
but to keep it backward compatible it follows these rules:
1. there is only one parameter and it matches known model:
--panic isa
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
2. there is only one parameter and it doesn't match any model:
--panic 0x505
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
3. there are two parameters:
--panic isa,iobase=0x505
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This is advanced configuration and it's not required to configure
at all to have a working panic device.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The message when failing to connect can be misleading as package names
will differ per Distribution as well as not apply for e.g. self built
binaries.
This changes the message in a way to be more generic not implying literal
package names.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Dealing with packagekit across desktops and in a consistent
manner is a pain. This code path is rarely exercised and difficult
to test, so just fallback to giving a hint error message and
let the user install if they care.
Use default place to store file systems of bootstraped containers.
If the current user has effective UID 0 use:
/var/lib/libvirt/filesystems/<container-name>
otherwise use:
~/.local/share/libvirt/filesystems/<container-name>
The current implementation calls _new_object_cb, which isn't
expected to be run from a non-main thread, and can cause crashes.
https://bugzilla.redhat.com/show_bug.cgi?id=1457170
Switch the impl to just wait for 3 seconds for the pool to show
up in our cache.
This patch add a checkbox for password visibility toggle.
As we stored password of SPICE/VNC in clear text in XML,
it's easy to use in UI.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Add virtual terminal emulator (Vte) in which could be shown details
of background running process.
Usage example:
- To enable details:
> asyncjob.details_enable()
- To show text inside the Vte:
> asyncjob.details_update("Some text here")
The bootstrap method is called at the end of the "create dialog" (when
"Finish" button is clicked).
We handle two cases:
1. When virt-bootstrap fails. User re-clicks the 'Finish' button and we
reattempt the container bootstrap.
2. When virt-bootstrap succeeds, but something later in the install
fails, like XML define. If user re-clicks 'Finish' we don't attempt
virt-bootstrap again, just use the directory path.
This is achieved by unchecking the 'install-oscontainer-bootstrap'
checkbox is unchecked if virt-bootstrap succeeds.
Log messages from the virtBootstrap's logger are stored in string
buffer and shown in case of failure.
- Show error if source URL is not provided.
- Require password for authentication to source registry when username
is provided.
- Show error if destination path is not directory.
- Show error if the user has no write permissions to destination path.
- Show Yes/No dialog if the destination directory is not empty.
Don't list every <controller>, just filter it all down to one listing.
There isn't anything interesting to tweak anyways, at least not anything
the UI supports.
We need to quote URL values in the username, that's what libvirt expects.
Unquote the values before caching them in the URI object, so console
connections continue to work
https://bugzilla.redhat.com/show_bug.cgi?id=1452389
If we detect that the UEFI image is build to require SMM feature we
should configure the guest to enable SMM feature and set q35 machine
type. Without this user wouldn't be able to boot the guest.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1387479
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The cb_add_new_pool callback will add a newly created storage pool
into virt-manager's cache so we don't have to wait for the libvirt
event to be handled.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1435064
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
libvirt added network forward mode 'open' by commit 25e8112d, No any
iptables rules are added to this virtual network.
This patch adds support to create such a virtual network.
Signed-off-by: Lin Ma <lma@suse.com>
It relies on the presence of X cursor fonts in the system. Use
recommended gdk_cursor_new_from_name and use cursor names that works
on different backends.
Deprecated since Gdk 3.16
https://bugzilla.redhat.com/show_bug.cgi?id=1442612
If we set on_crash as `preserve`, we'll get a crashed
VM state.
At this time, it's impossible to start this VM.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
When showing all the OSes, the list of distributions for some types of
OSes (Linux, UNIX) will get insanely long, and thus very hard to scroll.
As solution, introduce groups for some of the OS families, leaving the
ones without a defined group into a "Others" group.
To keep the completion working in the editable combobox, add a separate
completion model for the completion entry, providing all the OSes
directly there as simple list.
There are a number of changes related to this:
- the model for the OS comboboxes is now a TreeStore, and the iterations
on the OS variant keep that into account
- there are better UI labels for OS types and groups
- when there are no groups for a type, add all the OSes directly, just
like now
- optimize the way types are added to the combobox: when not adding all
of them, filter out those not "supported"
- optimize the way OSes are added to the combobox: query only for the
list we need (supported or all, not both), and group them according
to the hash defined
- add separator + "show all" options only when not showing all of them
- _add_os_row now is called only when needed, so remove its "supported"
parameter
Seen in a bug log file:
[Tue, 28 Mar 2017 12:05:21 virt-manager 2465] DEBUG (cli:251) Uncaught exception:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/details.py", line 1303, in refresh_vm_state
self.console.details_update_widget_states()
File "/usr/share/virt-manager/virtManager/console.py", line 1025, in details_update_widget_states
return self._update_vm_widget_states()
File "/usr/share/virt-manager/virtManager/console.py", line 597, in _update_vm_widget_states
self._refresh_widget_states()
File "/usr/share/virt-manager/virtManager/console.py", line 663, in _refresh_widget_states
self.widget("details-menu-vm-screenshot").set_sensitive(is_viewer)
TypeError: Argument 1 does not allow None as a value
This is in fact a bug in QEMU so we have to workaround this issue
to allow to connect to guest with VNC and listen type none.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1434551
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When the Autostart checkbox on the host Virtual Network or Storage tabs
is deselected, the label reads "Never", and when selected the label reads
"On Boot". This changes these labels to always read "On Boot".
Add virtuozzo hypervisor to connection list.
Add radio buttons for choosing VM or container virtualization type.
New wizard window for setting template name for containers.
We don't have any way at the momemnt to synchronously update cached
object lists. So if old_nvram will create a pool for the nvram dir
(/var/lib/libvirt/qemu/nvram), new_nvram won't see that new object
in our cache, will attempt to create it itself, and raise an error.
Next attempts succeed though.
We can avoid this by not even setting new_nvram.path, that step was
redundant anyways since we are setting a vol_install right afterwards.
This way, new_nvram is getting a reference to the parent_pool object
via the vol_install, so it doesn't even check the pool object cache.
Libvirt storage API doesn't support renaming storage volumes so
we need to copy the nvram file and remove the old one.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1368922
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Libvirt doesn't support creating volumes for some storage pools,
don't generate default clone_path for these storage pools.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1420190
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If we don't default to clone the disk in question don't try to generate
and assign default clone_path, this will force user to select the path
explicitly and avoid some unnecessary errors in debug log.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Similarly to virt-install --listen=none, add a combobox to select
the listen type: "address" or "none" for now, as suggested by Pavel
Hrdina.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Add an OpenGL checkbox to the Spice graphics options (only available if
SUPPORT_CONN_SPICE_GL).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
If a package has no summary, try to use the description (if available):
- if it is just one line (mostly because the package manager only has
a single line as description of a package), then use it fully
- if it contains more lines, then take the first only, adding suspension
dots to indicate it is longer than that
Refresh the 'Information' page when there are new inspection data
available, so they can be seen even without switching to a different
page and back. This could be seen when starting virt-manager, and
opening quickly the 'Information' page of an uninspected guest.
Now we act for each item in the queue, so there is no more need to drain
it fully before doing anything. Thus, turn _run into a simple
get+process+done loop.
We might get 'conn-added' signals for the same connections more than
once, so make sure to skip a new connection notification when the
connection is already known.
Currently, the handling of the 'vm_added' element in the queue (added as
consequence of the 'vm-added' signal) is to act as trigger to rescan
every VM in every local connection; this operation is "fast" because
every VM except the newly added is already marked as visited. Still, it
is an not really efficient way to visit new VMs.
Instead, just push in the queue all the data we get in vm_added, so when
processing the queue we can process each VM straight away. Because of
this, make sure to gracefully handle VMs that were removed while the
'vm_added' item for them was sitting in the queue (which is something
the old code did not handle properly).
When connecting to remote SPICE we use ssh tunnel if the SPICE is
listening only on "localhost". Our ssh tunnel scheduler uses locks
to serialize the requests for FD in order to not spam user for ssh
password.
However when the main_channel is connected and emits AUTH_ERROR
we ask user for password and request for new FD. Unfortunately
after the new request is handled we didn't unlock the scheduler
and all other request would remain waiting for the lock.
We need to unlock every FD request for the SPICE main channel not
only the first one when the channel itself is created.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1401790
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When there is no high quality icon for a guest, try getting the low
quality icon. This should make virt-manager show icons for Ubuntu and
Windows guests.
When the network interface is up the active XML contains only IP address
even in case that the inactive XML was configured to get the IP address
from DHCP server. To propagate this information back to UI we need to
get both XMLs to figure out current IP addresses and the configuration.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1410722
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Libvirt provides domain capabilities where supported disk bus types are
listed. Virt-manager should try to get those bus types. The old code
remains as fallback if domain capabilities doesn't contain the disk
bus types.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1387218
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Yet another issue with not using window.get_size() and instead using
its size allocation directly, which differ on wayland due to client
side decorations.
https://bugzilla.redhat.com/show_bug.cgi?id=1397598
The virt-manager application generates invalid guest XML when a
spapr-vio SCSI model controller is changed to a virtio-scsi model controller.
1. Create a guest
2. Add an spapr-vio controller to the guest via this gui path:
->Add Hardware
->Controller
->Type SCSI
->Model Hypervisor default
At this point, there will be a valid spapr-vio SCSI controller defined:
<controller type='scsi' index='0'>
<address type='spapr-vio' reg='0x2000'/>
</controller>
3.Now modify the above SCSI controller using this gui path:
->Choose "Controller sPAPR SCSI" on left pane
->Choose "VirtIO SCSI" for the Model on the right pane
->Apply
At this point, there will be a SCSI controller definition which is invalid due to an incorrect address type:
~# virsh dumpxml dotg2|grep -A2 -i scsi
<controller type='scsi' index='0' model='virtio-scsi'>
<address type='spapr-vio' reg='0x2000'/>
</controller>
Any attempt to start the guest will throw this error:
error: Failed to start domain dotg2
error: internal error: process exited while connecting to monitor: 2016-12-02T17:45:12.989165Z qemu-system-ppc64le: -device virtio-scsi-pci,id=scsi0,reg=0x2000: Property '.reg' not found
virt-manager fails to realize that the address type needs to be changed to a PCI address for a virtio-scsi controller.
If you change the model, you are supposed to leave the address field empty, so that libvirt sets it correctly. Or change the address field also appropriately.
Note that this bug can be reproduced entirely within virt-manager. No manual editing of guest XML is being done here. So, fix is to make virt-manager delete the address field when the SCSI controller model is changed, allowing libvirt to automatically assign a new address with the correct type.
Signed-off-by: Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
such as a VM is active.
This patch will disable 'Clone' label in VMActionMenu
if we can't clone a VM,
as same as we did for 'Clone' button in clone ui page.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
For Xen, virt-manager uses a 'xenmigr' URI scheme, which is not
supported by the libvirt libxl driver. Attempting migration
fails with
libvirtError: invalid argument: unable to parse URI: xenmigr://myhost
The old xend-based libvirt driver supports this scheme, but also
supports an empty scheme. It's not clear what the 'xenmigr' scheme
is used for. 'xenmigr' is not referenced by any files in the Xen
code-base, including old branches with xend.
Drop setting scheme to 'xenmigr' when creating the Xen migration URI.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
libvirt has supported the migration V3 protocol for many years now.
A nice feature of the virDomainMigrate3 API is that it will detect
the protocol version supported by the underlying hypervisor,
including whether it supports the extensible parameters variant,
and call the hypervisor API with parameters fixed up as needed.
Change virt-manager to use the virDomainMigrate3 API, allowing
migration to work with hypervisors that only support the extensible
parameters variant of the migration V3 API.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
When creating a storage volume, it wouldn't show up in the list
since the refresh signaling was busted.
Code was using VIR_STORAGE_POOL_EVENT_REFRESHED which was dropped
from lifecycle event type, refresh is introduced as top level
event.
Function _close_viewer should be always called together with setting
unavailable page. Call only _activate_unavailable_page which does both things.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We need to tweak refresh() handling to work similar to the shared
XML and status caching in libvirtobject.py: when the user manually
invokes the refresh() operation, and storage events are set up,
we just invoke the refresh() but let the event loop handle
refreshing the cache.
This fixes a backtrace when invoking a manual refresh via the
host details dialog
When new pool objects appear, we call refresh() on them, to ensure
we have the latest data (in case manual changes were made to the
storage pool directory behind libvirt's back, which is quite common).
However with the storage event support, this results in lots of
REFRESHED signals during initial connection startup, which kick
off redundant object polling.
Avoid storage REFRESHED events if they come in before the connection
is finished starting up to skip this redundant polling.
Otherwise this triggers some event calls and results in double
polling during connection startup. Doesn't cause any issues, just
spams the logs and needless libvirt calls
Even if it's not marked readonly or shareable, floppy media is
very likely to be a shared resource and not something that belongs
to the VM that the user will want to delete by default.
continue_install is intended to facilitate windows XP style 3 stage
installs:
stage 1: initial dos style disk setup, reboot
stage 2: actual full installer, reboot
stage 3: OS is functional, virt-install is done
The code assumed that we needed to keep the cdrom as the primary
boot device for the second stage, so virt-install/virt-manager needed
to hang around through the second stage run, wait until the VM shutdown,
then encode the final XML to boot of the disk.
Windows is and always has been smart enough to handle that case though...
after the initial boot, if we set the hd as the primary boot device
for stage 2, the disk bits that windows already installed will make
use of the cdrom as necessary. So the entire premise of continue_install
is irrelevant. Maybe back when it was added, when xen didn't even have
working ACPI support, this served a purpose, but I'm pretty sure we
can safely drop it nowadays.
If the first install attempt fails, then the second attempt succeeds,
we were still removing the disk images we created as though the
install never succeeded. We need to clear out the cached failed_guest
value via the customize dialog callback
https://bugzilla.redhat.com/show_bug.cgi?id=1342043
This improves loading domcapabilities to get domcapabilities for recommended
machine, not for default machine.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If password for console is saved currently there is no way how to tell
virt-manager to forget that password. This patch improves the authentication
page in order to provide a way how to forget password simply by unchecking the
"Save this password in your keyring".
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Commit 839ce682 removed deprecated support of save/restore which was replaced by
managedsave feature. This is a leftover that wasn't removed together with that
commit.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1340356
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Commit a0c2fdf4 fixed a bug that there was no way how to close the app.
The original issue isn't present anymore but reverting that commit isn't
enough. We need to increment/decrement window count while
showing/closing the create window in order to not exit right after
the create window is opened.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1331707
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
- If connecting remotely but graphics has no listen address,
like the spice GL case.
- Trying to connect to a TLS using VM over an ssh tunnel, it doesn't
seem to work: https://bugzilla.redhat.com/show_bug.cgi?id=1320331
Basically reverting this commit:
commit 1c8bf88db7
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Jun 18 08:46:24 2013 -0400
baseclass: Add unregister wrappers for idle and timeout
If an idle handler raises an exception, it isn't unregistered and loops
forever. This is a regression from previous pygobject and pygtk:
https://bugzilla.gnome.org/show_bug.cgi?id=702552
Work around this for now with our own wrappers.
Commit 159e4af1 fixed a case where VM was started if user destroyed VM
while installing it. This moves the code before we check whether we
need to restart the VM in order to continue in installation (windows
requires that).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1235238
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This is largely left over from the old days when a xen VM could
start up but still take a bit of time for the allocated VNC port
to be reflected in the XML.
This may still be an issue with old old xen, but I suspect it's
not relevant for anything modern, and it causes some issues with
listen=none behavior that spice supports. Just drop it and see if
anyone complains
Function virDomainOpenGraphicsFD() from libvirt can return -1
But in this case libvirt-python will raise an exception.
We should handle this case and return -1 as invalid FD.
In commit 5c451b64 Viewer._open() there is a code to open
graphics console in case of invalid GraphicsFD.
(crobinso: also log the error message)
So far we used only the last --extra-args argument from virt-install
command line, but it makes more sense to use all occurrences of
--extra-args and pass them to kernel.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This allows to connect to VM without any display listening socket, the
fd passing is done through libvirt connection.
Furthermore, since it uses unix socket, spice can use virgl locally
with texture sharing. This effectively enables spice-gtk to display
local virgl rendering.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
In case that libvirtd is stopped, we could receive another type of error
from libvirt "libvirtError: internal error: client socket is closed".
This one is usually reported from local connection.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
libvirt does not allow this and attempt to do so causes error during domain
startup. Prevent this in the beginning instead with correct explanation.
Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
So I was confused here and completely missed that GtkApplication is
meant to handle the common case of invoking actions in an existing
app instance. So drop the manual dbus server and use the simpler
Gtk support.
Fix a bunch of other errors in this area too
Traceback (most recent call last):
File "/home/crobinso/src/virt-manager/virtManager/details.py", line 1257, in switch_page
self.console.details_refresh_can_fullscreen()
File "/home/crobinso/src/virt-manager/virtManager/console.py", line 965, in details_refresh_can_fullscreen
return self._refresh_can_fullscreen()
File "/home/crobinso/src/virt-manager/virtManager/console.py", line 464, in _refresh_can_fullscreen
self.widget("control-fullscreen").set_sensitive(allow_fullscreen)
TypeError: Argument 1 does not allow None as a value
This allows virt-manager command line that launch windows to work for an
existing virt-manager instance. This is handy for scripting, and giving
other apps a reasonable way to launch a virt-manager VM window for
example.
This UI exposed the old NUMA allocation policy detailed in the last commit.
It's very much sub-optimal, and should be removed.
Manual cpuset configuration is also quite uncommon and not really something
worth exposing in the UI. It can easily be done from the command line
with virt-xml.
If people complain, I'd consider adding a checkbox for vcpu placement=auto,
or an option to do that by default for new VMs.
Currently we show channel label by its name.
If we use name com.redhat.spice.0 but set it
as unix socket, the label in details keep unchanged.
This patch will set label according to device type
if we failed matching target_name
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Most of this is lifted from 'meld'. The bits are
- compile gsettings schemas at setup.py install time
- add options to disable that, and use them in the RPM
- always pass GSETTINGS_SCHEMA_DIR so gsettings loading always works
regardless of the install dir
https://bugzilla.redhat.com/show_bug.cgi?id=1267377
Since qemu has the setuid qemu-bridge-helper, give a way in the UI
to specify a manual bridge name for qemu:///session. Might not work
all the time but at least the users can try
https://bugzilla.redhat.com/show_bug.cgi?id=1212443
