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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* Move browse_reason handling entirely into storagebrowser.py
* Open code some of the browse_local logic at the few callers
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Using the source.socket of virtiofs needs a virtiofsd daemon launched
outside of libvirtd, So the filesystem UI doesn't support it yet. If
users need it they can set it manually in the XML editor.
But if we view the filesystem info of such a VM on the details page,
It fails with this error message:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/details/details.py", line 1713, in _refresh_page
self._refresh_filesystem_page(dev)
File "/usr/share/virt-manager/virtManager/details/details.py", line 2241, in _refresh_filesystem_page
self.fsDetails.set_dev(dev)
File "/usr/share/virt-manager/virtManager/device/fsdetails.py", line 193, in set_dev
self.widget("fs-source").set_text(dev.source)
TypeError: Argument 1 does not allow None as a value
This patch fixes above issue by leaving the 'source path' info blank in
case of source.socket.
In this case, Considering that showing 'target path' info without source
info is kind of meaningless, So this patch leaves the 'target path' info
blank as well.
Signed-off-by: Lin Ma <lma@suse.com>
If the user selects virtiofs when editting or adding a new VM, and
we don't detect that they have shared memory enabled, show
a warning label in the UI pointing them to the Memory screen.
It would be nicer if we did this for them, but to get that totally
correct would require both duplicating libvirt's shared memory
detection logic, and some surgery to the addhw wizard. This is good
enough for now
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We only ever show mapped vs squashed, and the difference is pretty
advanced, so if users need it they can use the XML editor. Upcoming
virtiofs support will also make handling this field more complicated
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Split out tpmdetails.py, following the pattern of fsdetails.py. This
adds more UI editing fields for an already attached TPM.
Move the model and version under an 'Advanced options' expander,
since we should be getting this correct by default.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
After checking with qemu devs, this option is not really recommended
for common usage and doesn't get used much in practice. So I don't
think it is suitable for the UI
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I removed Portgroup UI in 4c3c53f773 release 3.0.0, but there's been
a steady stream of requests to bring it back. It seems it's commonly
used with some certain openvswitch config.
Maint burden isn't too bad. Let's bring it back
Fixes: https://github.com/virt-manager/virt-manager/issues/169
Signed-off-by: Cole Robinson <crobinso@redhat.com>
... with the 'hypervisor default' address. In this case, we need to
force set port=-1 in the XML, to make the changes actually stick
Signed-off-by: Cole Robinson <crobinso@redhat.com>
So if the user chooses a different value from Preferences, or
app is built with a different value, default to that in Add Hardware
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Make it work more like gfxdetails. The problem with the current
approach is that it requires effectively rebuilding the whole device
to match the original device when we want to edit a single field,
which is error prone.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
If something would normally be shown only in a label, just
hide the row entirely. This was interesting for viewer XML
properties before we had the XML editor, but now it doesn't
add much
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This makes it more clear that 'path' is really a special designation
with a bunch of complicated logic behind it. It's also easier to
grep for
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We were leaving the ISO field populated with whatever the old value
was. This is likely useful in some cases but it's consistent with
how we handle fields in the rest of the wizard, and has some weird
interaction with OS detection
Fixes: #159
Signed-off-by: Cole Robinson <crobinso@redhat.com>
And absord device building from addhardware. This moves all the
knowledge to gfxdetails, which saves sprinkling it around in other
places
Signed-off-by: Cole Robinson <crobinso@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1759454
See 15a6a7e210
The idea behind virt-manager's sparse vs nonsparse default, is that if
the user selected 'raw' for as the default image format, assume they
want to maximize performance, so fully allocate the disk.
qcow2 didn't support anything except sparse, so the sparse=True vs
sparse=False made no difference. So we always set sparse=False
Then qcow2 grows non-sparse support, and virt-manager is suddenly
defaulting to it, which is not the intention.
Default to sparse when requested format isn't raw
Signed-off-by: Cole Robinson <crobinso@redhat.com>
coreos is going to start using disk serial for ignition disk, so
setting this in the UI for distro testing will become more common
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Share the UI for changing all these disk properties:
- shareable
- readonly
- removable
- cache
- discard
- detect zeroes
Move them all under the 'Advanced options' expander in details, and
add the checkbox options to the addhardware wizard.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Refactor the internals to cleanly separate the pieces that fill in
the UI, and the pieces that react to UI state to dynamically show/hide
fields.
Improve spice GL warnings while he are here, and several other minor
fixes
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Make it explicit that all uses of this is actually the object
name. We already leaked this abstraction in several places so better
to make it explicit. This also communicates to users that this is a
field that is not immutable so it shouldn't be used as a unique key
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Otherwise early 'change' signals can give inconsistent
behavior WRT default 'advanced' expander state
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Unset rendernode when spicegl is de-selected
* Set rendernode by default when spicegl is first selected
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Always force a network selection. If we have to fall back to
manual bridge UI because nothing else exists, show a warning.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The versions we are warning about are all over 4 years old, and
these warnings were initially just informative to help users know
when the config wasn't going to work. Drop most of it. Still warn
in the UI when a VM misconfig will prevent spice GL from working
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We need to wire up some craziness to make path permission
searching fail, but this is a critical area to get correct
so it is worth it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Don't have the caller call a validate function, they all catch
errors anyways. Let the build step raise error if there's a problem
Drop some validation checks that libvirt should be performing for us
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I don't think many, if any, people are using virt-manager with
openvz. Drop the specific handling the filesystem UI, users can use
the raw XML editor if they need special behavior
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Do not split the error messages and the error details, but rather use a
single string with proper placeholders. This avoids string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
When updating the checkbox aobut the automatic port, set a full string
(without or with the port) instead of "cutting" an existing label.
Not only it avoids to manipulate a UI string, it also allows translators
to properly translate the whole string that includes a port.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
