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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Similar to the virt-install change, we only do this with default storage
if the installed failed in such a way that we never left the wizard.
It isn't going to cover all cases, but should handle the common issue
of stranded disk images
https://bugzilla.redhat.com/show_bug.cgi?id=799721
It's not consistently applied. If I had a setup to test against old xen
that still listed dom0, I'd make it so we never even show dom0 so we
can sidestep the problem entirely.
This has been supported for a long time now, and is more tested these
days, so let's use it rather than the old style AttachDevice method
It also works around a libvirt issue described in bz 1229819
Libvirt commit#742d49f introduces vgamem attribute to set the VGA
framebuffer size for QXL device of qemu, So we use vgamem instead
of vram here for qxl.
Signed-off-by: Lin Ma <lma@suse.com>
This feature has been added few years ago. I don't think, that it's a
good feature, as it can ask a user to use different storage than he
actually wants to use. One thing is automatically create a new storage
for user, if he let as do that, but we shouldn't annoy a user with this
question as he probably don't want to use the proposed storage. For
example he would like to use different storage pool or while importing
existing storage.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1232599
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
There is no virtio-scsi or spapr-vscsi bus, but only 'scsi' bus. There
are several types of SCSI controllers, but the SCSI storage don't care
about the SCSI controller and there is also no difference in address
specification or address type. Use only 'scsi' bus for all SCSI storages
to correspond the reality and also the libvirt domain XML. The only
difference is in the type of SCSI controller
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
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 938060ae5340f6e28dc9669ba1ab79a1aa3d615e 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
