Reserve uiutil for the little gtk helper functions, rest goes into shared
UI (which all should probably be factored into their own files but thats
a task for another day)
Much of uihelpers is just simple stuff that's shared between addhw
and details UI, so just make it staticmethods in addhw, which details
already has a reference to.
The xend toolstack is deprecated upstream. While support needs continue
for this legacy toolstack, the newer libxl toolstack does not need xend
to work. Additionally, libvirt now has drivers for supporting the libxl
toolstack.
This patch changes the check from /var/lib/xend to /var/lib/xen
which is a common path in both toolstacks. Neither the old path nor the
new one actually proves that xend is currently running. It just validates
that xen has been installed on the machine.
Signed-off-by: Charles Arnold <carnold@suse.com>
Do not show only the OS supported stable when stable_defaults is not
used. commit dc0b9bbaaf introduced this
issue.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
We could specify 'model' for scsi controllers,
that means we could see more than one controllers
with same icon and blank details.
That will confuse users.
This patch will show details of scsi controller device.
And also we could modify scsi controller model
between 'default' and 'virtio-scsi'.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
There were multiple problems with the setting and usage of
hide_unsupported_rhel_options. Due to the fact that the option has
several diferent namings throughout the code, this patch is renaming
it to stable_defaults, which basically says what the option does and
makes it possible to use it without need for more than one negation
(where the old code had up to 4 of them in some places), which also
helps understanding it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
We set virtio-scsi controller index according to
the number of scsi controller in VM.
This patch will set virtio-scsi controller index
via max index in scsi controller list.
How to reproduce:
a)
If we got an VM with two scsi controller:
<controller type='scsi' index='0'>
<controller type='scsi' index='2'>
#reason for index='2':
someone delete a scsi controller with index=1
by virsh
b)
add a virtio-scsi disk by virt-manager
c)
error threw by virt-manager:
libvirtError: XML error: Multiple 'scsi' controllers with index '2'
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
We should not encourage user use device type 'LUN'
if they selected virtio bus.
This patch will prevent user from doing this.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
On first run, the remote URL install handling creates a storage pool
for /var/lib/libvirt/boot on the remote host. After this, it clears
the VirtualConnection's object cache, so the next time all pools are
fetched, it returns an accurate list.
However that clear_cache call wasn't propagated up to virt-manager's
cache. Add a new cb to fix it.
This makes new x86 kvm guests use the host's CPU model as reported by
libvirt capabilities output. This is a reasonable compromise for now
to increase performance while we wait for libvirt/qemu to fix host-model.
Add a preference for changing the default CPU mode/model. The options are:
- default (whatever virt-manager chooses as the default)
- hypervisor default (no <cpu> block, what we've always done)
- nearest host cpu model (just the 'model' from caps->host->cpu)
- copy host cpu (the entire <cpu> block from caps->host)
The setting only applies to KVM guests, not tested with anything else.
The default is left as is for now (hypervisor default).
copy host CPU will one day use mode='host-model', when it does what
we want. At that point we will probably make it the default
If we didn't set values for @type and @iobase in
XML, libvirt will use the default value.
Currently, virt-manager will display "-" if we don't
set any values.
This patch will use default value for display.
And update test case to cover this scenario.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Similar to how we allow disabling disk/net polling, not sure yet what
effect it might have on remote connections, so best to add this option
just to be safe.
Unlike disk/net stats, we enable this checking by default.
