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.
Simplest is to have a separate UI area for the arch warning, since
the standard startup warning may still apply too.
Reported-by: João Pirralha <joaopirralha@gmail.com>
Originally this made sense, as it was the only way to specify a non-default
storage format when creating new storage.
Nowadays the storage browser is a full featured storage manager... and
this field is a bit confusing WRT whether it's used for creating new
storage, or informing libvirt about an existing image's format.
Drop it from the addhardware wizard, and simplify what we show in the
details wizard as well.
This is a little low level and rarely used IMO to have it in the UI.
If people want to edit this we should point them at virt-xml which
seems like the appropriate user friendlyness for this feature.
This made more sense when raw was the disk image default, but nowadays
we use qcow2 which doesn't even support non-sparse, so the UI is always
disabled.
If the user changed their preference to raw, it still doesn't make much
sense to show the option, since they are likely using raw for performance
in which case they are going to want to preallocate anyways.
So just default to sparse=False. If users want to override it, they can
do it via custom created storage.
Drop horizontal scrolling, since with gtk3 hidden scrollbars it might
mean users don't realize there's info that is scrolled off.
Adjust the default sizing to match that pattern
Trying to fall back to the create wizard can give weird results, since
it's really hard to ensure the customized changes are preserved if
the user changes things in the 'new' wizard.
It's largely the same, but now
- The code is better organized
- The UI is much more streamlined, only showing relevant fields when
required.
- We warn about the hostname/URI cases that we know libvirt will error on
- Drop some of the attempts at being smart, and just mimic what libvirt
will do.
This is only needed when people have very specific downtime constraints
on public facing services. I don't think that covers many virt-manager
users. So suggest they just use the command line for this.
We've had multiple requests over the years for something similar. People
might have to connect to multiple IP addresses, or really large hostnames,
that become difficult to distinguish in the UI.
Add a field in the host details page that allows setting a custom name,
and store it in gsettings.
We were already sharing a chunk of this in a haphazard way. Now officially
break it all out, similar to netlist.py. This mostly unifies the views
of host->storage and storagebrowser.py
And not the other way around. It's less confusing this way IMO, particularly
if virtio is selected by default and the user is confused, wondering
where the cdrom option is.
Take the opportunity to actually share the bus combo logic between details
and addhardware
People should rarely need to edit the mac address, so remove it from
the create wizard. However we only allow editing the mac address in
the 'customize' dialog: regular network details disables editing, since
that should be a rare and potentially dangerous operation.
It is added only in the details window, and intentionally not added to
the addhardware UI to keep it simpler. Users can edit this after a
new device is added.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Not all CPUs support Hyper-Threading. This patch adds a warning
message next to the threads selection field of processor topology
box. It warns that "Selected CPU model does not support
Hyper-Threading" when # of Threads > 1 and the selected CPU model
does not support Hyper-Threading.
This UI modification was added using glade 3.18.3.
Signed-off-by: Wei Huang <wei@redhat.com>
shortkey M for fs-mode in fsdetail duplicate shortkey of
"Virtual Machine" in details.
change it to 'o'.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
We expose a simple combobox with two entries: BIOS, and UEFI. The
UEFI option is only selectable if 1) libvirt supports the necessary
domcapabilities bits, 2) it detects that qemu supports the necessary
command line options, and 3) libvirt detects a UEFI binary on the
host that maps to a known template via qemu.conf
If those conditions aren't met, we disable the UEFI option, and show
a small warning icon with an explanatory tooltip.
The option can only be changed via New VM->Customize Before Install.
For existing x86 VMs, it's a readonly label.
Alt+f is already used for Finish. Choose Alt-o as it is already used
for "Format" in other places.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
After the migration to libosinfo, choosing an OS variant from "New VM"
wizard became a mess for the very long list of options.
Using an autocomplete entry text will facilitate this task, as an user
can start typing the variant as soon as the OS type is selected.
The combo-box is left untouched, so undecided users can still use it.
UI-suggested-by: Máirín Duffy <duffy@redhat.com>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Libvirt not allowed uid/gid_start
configured as none 0 or not specified.
This patch will disable config uid/gid_start in UI.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Add a new field "pool-source-name" in the createpool UI that is used
only with gluster fs pools.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
We acted like it would migrate a shutoff VM, but it just toggled
the LIVE flag. We should support true 'offline' migration, but
the UI will be different.
- Add options in the model drop down for clear, hvdefault, and app default
- Make 'copy host' a check box, when enabled it hides the model dropdown
- Detect if the VM CPU is a copy of the host CPU
- Undocumented bit that allows passing in host-model/host-passthrough
to the model field for people that really want those settings.
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
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.
Normally, setting cache=none is required in order to ensure a consistent view
of storage between the source and destination migration hosts. However, some
configurations have that quality without resorting to the use of an O_DIRECT
open (which is what cache=none does), and hence cache=none wouldn't be
necessary.
Unfortunately, libvirt is not able to determine on it's own all the
configurations which require cache=none for migration but in the interest of
safety enforces it when it isn't otherwise able to determine migration safety.
For this reason the libvirt api has an 'unsafe' option which allows the user
to override the safety migration checks.
This patch adds a checkbox to allow unsafe migration to the 'Advanced options'
portion of the migration dialog.
Signed-off-by: Charles Arnold <carnold@suse.com>
We could copy host CPU config by
button 'Copy host CPU configuration'.
If we regret to do this or the host CPU config
caused VM starting failure, we need a button to
help us clear CPU feature.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
If libguestfs fails to inspect the guest then show a warning.
Now the "Operating System" and "Applications" frames are visible
only when the guest inspection is available.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=755869
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Hide the 'type' field on non-xen: we shouldn't need to expose
kvm vs. qemu in the UI, just assume if kvm is available we use it.
Hide arch if there's only one available. And hide the whole expander
if we hid both sub fields.
Moving name to the end allows us to do things like generate a default
name based on the chosen OS type, which we do here. This is bz 736951
Moving arch/type to the front page of the wizard simplifies validation
and will be needed to intuitively install arm guests without a bunch
of hacky workarounds.
- Hide backing store for formats that don't support it
- Hide allocation for qcow2 since it doesn't do anything
- Automatically select the storage format as specified in prefs
Show a screenshot in the 'new snapshot' wizard. If we successfully create
that snapshot, save the screenshot in
~/.cache/virt-manager/$connuri/$vmuuid/snap-screenshot-$snapname.$ext
And show it in the snapshot details overview. We don't do any reaping
on snapshot delete, vm delete, etc, but that could be added later.
We sort them separately in the snapshot list, explicitly mention that
they are 'external', and add a UI field listing the memory/disk
details.
In general mixing internal and external snapshots is a recipe for
confusion and disaster, so I think the best thing to do is at least
acknowledge their presence in the UI but not make any attempt to
predict what will or will not work.
Commit b79ba8382e2205c416d7c4836ac9ee08c72e2c56 in libvirt adds a
<title> attribute to the domain XML, that is used by the user to
identify more easily the VM. This feature is not supported by all
HVs. This patch allows to see and modify the title from the details
window.
Something similar was requested here:
https://bugzilla.redhat.com/show_bug.cgi?id=798949
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Convert virtManager/host.py, do some cleanups and modernization to the
UI there, add tests.
createnet.py hasn't really been touched yet, but still works because
it was building the XML by hand anyways.
- Drop SDL, it doesn't mesh with modern libvirt
- Drop keymap, modern qemu/virt-manager handle this automagically
- Drop big text fields
- Misc other cleanups and simplifications
This adds initial UI for managing snapshots: list, run/revert, delete,
add, and redefining (for changing <description>) supported, but currently
only for internal snapshots. The UI is mostly in its final form except for
some bells and whistles.
The real remaining question is what do we want to advertise and support.
Internal (qcow2) snapshots are by far the simplest to manage, very
mature, and already have the semantics we want.
However most recent libvirt and qemu work has been to facilitate
external snapshots, which are more extensible and can be performed
live, and with qemu-ga coordination for extra safety. However
they make things much harder for virt-manager at the moment.
Until we have a plan, this work should be considered experimental
and not be relied upon.
Now when a password is used a check box must be explicitely selected.
This enable the possibility to set an empty password "".
Solves: https://bugzilla.redhat.com/show_bug.cgi?id=749718
Signed-off-by: Giuseppe Scrivano <gscrivano@gnu.org>
(crobinso: fix minor pylint violation)
The goal here is to reduce the amount of tick() polling that we do by default.
For things like pools, networks, and interfaces, the constant polling is
not very helpful and causes CPU churn and slowness for remote connections.
Switch to a more on demand style. Pages that want new information for
these objects now request a priority tick that only refreshes the info
we want.
This isn't perfect, but neither was the previous solution in the face of
things like XML updates behind our back. The real solution here is libvirt
event support across the board.
Add "Redirect USB device" option in console viewer. Initialize and
embed UsbDeviceWidget object from SpiceClientGtk into a dialog to
let user choose available USB devices for redirection.
Throw an error message if USB connection failed.
Auto-redirection is enable by default.
There is race between creating usbredir channel and calling
has_usb_redirection() when initializing spice session like
happening on virt-viwer. So adding a new signal handler
on_details_menu_virtual_manager_activate() to recheck the
status of usbredir channel, set "Redirect USB device" option
sensitive if it is availiable.
Add "Select USB devices to redirect" option in console viewer
Initialize and embed UsbDeviceWidget object from SpiceClientGtk into
a dialog to let use choose available USB devices for redirection.
Throw an error message if USB connection failed.
The syntax for static route support is defined by the
new <route> subelement which has the form:
<route family='xx' address='xx' prefix='n' gateway='gg' metric='m'/>
This patch builds on the previous patches for adding IPv6 support and
extending the virtual network support.
The static route support code has been recently added to libvirt and will
be included in libvirt 1.0.6.
.
Signed-off-by: Gene Czarcinski <gene@czarc.net>
host-model is a bit more scary then previous behavior, since the
model of an existing VM can transparently change across libvirt
upgrade or HW upgrade. This will probably be improved at the libvirt
level, but for now revert.
This reverts commit 17f43e47fb.
Remote sound works fine these days. If people want to turn the
preference off, they probably want to do it in all cases, and can
'customize before install' to alter the rest.
If the host-model is selected, disable the cpu model drop down
and features list. They still show what exact configuration the
host-model is using.
For the old libvirt which doesn't support <cpu mode='host-model'/>
virt-manager still copy cpu configs from caps XML to domain XML.
(crobinso: Fix some minor pylint)
With this patch, basic IPv6 support has been added to
the network creation wizard. It includes changes to
both the glade-3 ui and the related python code. There
have been some significant changes made to both files for
IPv6 support and some additional capabilities.
This update includes the fix so color will work in the
network creation wizard.
Besides basic IPv6 support, this includes optionally
specifying a DNS domain name and enabling IPv6 internal
routing if no IPv6 address is specified.
.
Signed-off-by: Gene Czarcinski <gene@czarc.net>
The purpose of this update is:
1. replace use of IPy with ipaddr since ipaddr has needed
functionality and IPy does not.
2. Update the glade-3 ui (vmm-host.ui) to provide
for IPv6 as well as IPv4. If either IPv4 or IPv6
is not defined, its respective frame is hidden.
3. The DNS Domain Name is added to the basic frame.
4. IPv4 forwarding is moved to the basic frame and ipv6
forwarding is added.
5. If an IPv4 address is not defined then the IPv4
is set to Isolated network, internal rout only.
6. IPv6 network has three values for Forwarding:
Isolated network, Isolated network with internal forwarding,
and Routed network.
7. Add network definitions to tests/testdriver.xml which
include IPv6 and other new parameters now being handled.
This patch includes the fix for getting a KeyError exception
when deleting a network definition.
In this update, createnet.py has been changed to use
ipaddr but it still only handles IPv4 network creation.
.
Signed-off-by: Gene Czarcinski <gene@czarc.net>
(crobinso: Add Gene to AUTHORS)
Despite being a known quantity, autotools is so overkill for our needs,
so let's drop it and replace it with a much simpler and easy to customize
system.
Cole Robinson