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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
virtManager/createvm.py:982:8: W0128: Redeclared variable 'ignore' in assignment (redeclared-assigned-name)
tests/uitests/lib/app.py:12:0: C0411: third party import "from gi.repository import Gio" should be placed before "import dogtail.rawinput" (wrong-import-order)
Signed-off-by: Chen Hanxiao <chenhx.fnst@cn.fujitsu.com>
If specified, this errors if no OS name was detected or manually set.
So --os-variant detect=on,require=on will error if no OS is detected.
name= can be used as a fallback, so test and document this case
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds the following --os-variant suboptions
* name=, short-id=
* id=
* detect=on|off
Functionally this does not change behavior, just adds explicit
sub options for behavior we already support
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The --os-variant option naming is pretty crappy and mostly a historical
artifact. Ideally this would be named just `--os` but I'm afraid that
would cause confusion with libvirt's <os> XML
Add --osinfo as an alternate commandline naming. If we ever want to
transition documented use of --os-variant it will help to have the
alternative around for a few releases
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The --xml option allows users to request raw XML edits to virt-install
or virt-xml generated XML. This gives users a bit of a workaround
incase we don't have proper support for some XML property. The --xml
option can gain more features in the future if it makes sense, like
setting XML namespaces for example.
Basic usage is like: virt-install --xml ./@foo=bar ...
Which will change the generated <domain> XML to have
<domain foo='bar' ...
virt-xml works similarly. It can only be combined with --edit currently.
This only works with xpaths rooted against the entire document.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Break utils.py apart into a whole uitests/lib/ directory with
* lib/_dogtailinit.py: all the dogtail library init we need
* lib/_node.py: extending our dogtail node class with more functions
* lib/app.py: VMMDogtailApp
* lib/util.py: util functions plus all the special helpers previously
in our custom TestCase
* lib/testcase.py: The TestCase that sets and tears down self.app
Adjust callers to match and make it easier to eventually convert to
native pytest usage
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This uncovered some areas in details.py we weren't handling that
the search view unselects the current selection
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Similar to behavior we have in virt-manager, if the user destroys the
VM during the VM install process, don't invoke the post install
reboot.
https://bugzilla.redhat.com/show_bug.cgi?id=1818089
Signed-off-by: Cole Robinson <crobinso@redhat.com>
As part of making virt-manager cooperate better with external viewers,
add an option to disable console autoconnect. When opening a VM window
for a running VM, you'll see a 'Connect to console' button in place
of the spice/vnc viewer. Click that and things proceed like normal.
This is useful to prevent virt-manager from disconnecting a virt-viewer
instance that's already attached to a VM
https://bugzilla.redhat.com/show_bug.cgi?id=1793876
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When a VM window is launched for the first for a VM, currently we
set the top window size to 800x600 which is small and arbitrary and
is universally shrinks the viewer too much to fit any OS installer
I can find.
Instead do some hacks to resize the window to accomodate a viewer
widget of 1024x768 which seems to be what QXL graphics give us for
win10 and Fedora 32 installers. So for new VMs hitting the OS installer
we don't see scrollbars.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Right now this is tied to widget focus, which is too strong. This
changes it so that say clicking on the window title or toolbar then
allows the user to use Alt+F to trigger the File menu for example.
This roughly matches how virt-viewer works
https://bugzilla.redhat.com/show_bug.cgi?id=1824480
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Move all the menu building to its own class, for clarity
* Rename the menu 'Consoles' since it contains graphical choice as well
* Strip out the VM console duplicate if it exists
* Simplify the code a bit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* rename kernelupload.py to volumeupload.py and make the entrypoint
more generic
* move all upload invocation to the Installer class
* use it with cloudinit and unattended ISO generation if required
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a quirk of libvirt that the first <device> is usually a
logical duplicate of the first <serial> device. Adjust virt-xml to
understand this quirk and remove both devices at the same time,
like we already do in virt-manager
https://bugzilla.redhat.com/show_bug.cgi?id=1685541
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>
Allows the user to tweak the XML at the destination, which is already
something that libvirt supports
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Drop the network editing, users can use the details window
* Drop the combo box approach in favor of a regular treeview
* Drop a lot validation checks which are redundant with modern
virtinst. We probably lose some checks but I don't think it's
too important
* Use the cloner API
* Add uitest coverage
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This let's us move more of the preserve logic to virtclone.py
and prep more things to share with virt-manager
Signed-off-by: Cole Robinson <crobinso@redhat.com>
test:///default saves changes for the lifetime of the connecting
process, which can cause weird interdependent issues in the test
suite. Duplicating it with driver XML will avoid those issues
popping up.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Centralize lots of disk building
* Open code virt-clone specific behavior at the source
* Drop a lot or properties
* Move most testing to test_cli.py
* Generally a ton of cleanup
virt-manager clone wizard has not been converted yet so is totally
broken after this commit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Cover more cases via the virt-clone CLI testing, than just the
test_cloner.py unit style testing.
Change most of the virt-clone --print-xml testing to also attempt the
clone operation as well via a hidden cli option, to ensure we aren't
testing XML of any bogus operations
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is just a test suite hack from before we had other methods
of specifying cloneable guests. It will be removed soon
We need to tweak some test XML to fix code coverage after
Signed-off-by: Cole Robinson <crobinso@redhat.com>
