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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Commint 0ddec919 updated the details page. Now the detail page of
existing domain cannot update the 'machine' value, only prints that
value. If we cannot get the machine from domain XML, don't pass a None,
but "Unknown" instead. This can happen if you are connecting with
virt-manager to really old libvirt, the machine value is present in
domain XML since libvirt v0.9.5.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1238981
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This issue was fixed for few years but only in virt-manager,
virt-install has the same bug. If you have two USB devices with same
vendor and product ID, you need to use also address element to create
a valid XML to define that device into a guest.
This patch moves the logic from vmmAddHardware into VirtualHostDevice in
order to not duplicate that code for virt-manager and virt-install.
Also update the tests files to properly check this functionality. I've
changed the USB device according the 'tests/testdriver.xml' and picked
one of the USB HUBs, because they have the same vendor and product ID.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1230611
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We need to update/initialize the capsinfo sooner in that function to be
able to call has_install_options().
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1244566
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Each guest type can have its own capabilities and we should always ask
only for those capabilities.
The old approach was to get capabilities from libvirt and then for
example cycle trough all guests and return True, if any guest type
supports kvm or pae, etc.
Now we check those capabilities only for the correct guest type
according to defaults and input from user.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
For architecture "s390x",the disk and the network device are base
on "virtio" bus.The cdrom is based on "scsi".So set the default
cdrom bus as "scsi",the default bus as "virtio".Also the default
machine type is set to "s390-ccw-virtio" as it is the only supported
in "s390x".Also add a test cast of virt-install by cdrom in s390x.
(crobinso: Tweak test suite and minor formatting stuff)
All the strings have to be at first translated and then we can fill the
formated and translated string.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
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
commit 938060ae53 moved default devices
setup to happen before UEFI is set invalidating what the commit
5acfccf6032abb9e8be89130d05b661e8b3f42c7 does.
Add another check to happen before installing the guest to disable
HYPER-V when not supported.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1185253
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Repopulating the ostype/variant list triggers a bunch of change events,
which causes us to enter an infinite loop due to some minor behavior
change in the uiutil helpers.
The uiutil helpers are still correct, the root problem is we should be
disabling change events when repopulating those UI lists (we already
have to do a similar trick in a few other places, like host.py)
This is really only useful for building default XML internally, and
for virt-install stuff like --watchdog default. Instead just select
the 'default' value in the wizard
commit 5357b91402 changed the semantic of
conn.get_(vm|pool|interface|nodedev|net), to return None instead of
raising KeyError. Leave the exception handling code in case the
semantic is going to be reverted.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1219427
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
memory doesn't have a separate input/output stats, so we shouldn't use
the in_out_vector_helper. This resulted in shutoff VMs appearing to still
use memory in the manager window.
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.
