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.
Our validation check might not be up to date, WRT what characters are
acceptable. So if we try to --auto-clone an existing valid VM with
some characters we aren't expecting, we cause ourselves to error.
Just skip the validation and let libvirt complain if something is wrong.
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
95170e8892 added --network=direct
without updating the number of possible values for --network in the
man page.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
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.
If we didn't install python-coverage, we could not
run 'python setup.py test'.
This patch fixes this little bug.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
When refreshing the details window after it has been already
initialized, we don't change the value of the View->Toolbar item in
the menus on which then the toggle_toolbar() depends and due to the
menu keeping the old value, the toolbar might (not) be shown even if
it should not (or should) be.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1049145
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>