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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Fix all E125:
Continuation line with same indent as next logical line
Also remove ignore options of E125
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
If we detect that the UEFI image is build to require SMM feature we
should configure the guest to enable SMM feature and set q35 machine
type. Without this user wouldn't be able to boot the guest.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1387479
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This element controls hot(un)plugable memory for the guest in
addition to the initial memory configured by <memory> element.
One has to configure <maxMemory> and guest numa nodes using <numa>
element to enable hot(un)plug of memory modules.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When an error occurs when the VM creation wizard tries to start the VM,
it's then not possible to press again the "Finish" button to try again
to start it, as this errors out with:
Traceback (most recent call last):
File "/home/teuf/redhat/virt/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/home/teuf/redhat/virt/virt-manager/virtManager/create.py", line 2341, in _do_async_install
guest.start_install(meter=meter)
File "/home/teuf/redhat/virt/virt-manager/virtinst/guest.py", line 457, in start_install
raise RuntimeError(_("Domain has already been started!"))
RuntimeError: Domain has already been started!
This is caused by code introduced in commit fc6778 which does not reset
self.domain to None when an exception is caught.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
This is for xml like:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
</devices>
<qemu:commandline>
<qemu:arg value='-newarg'/>
<qemu:env name='QEMU_ENV' value='VAL'/>
</qemu:commandline>
</domain>
Requires some extensions to the xmlbuilder infrastructure
Since we only attempt to add a default USB controller for x86, match
it by only trying to add redir devices on x86 as well. Fixes a uitests
failure for ppc testing, since the test:/// driver doesn't add an
implied USB controller, and libvirt now validates that one was provided.
Currently we hardcode these defaults for installing VMs:
<on_poweroff>destroy</on_poweroff>
<on_reboot>destroy</on_reboot>
<on_crash>destroy</on_crash>
And these for post-install config:
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
But this has some issues. on_crash=restart is problematic in that most
configs don't support it, and some like virtuozzo actively reject it.
Additionally this we should leave as much to libvirt defaults as we
can, which are more sensible in this case.
Drop everything except setting on_reboot=destroy for the install time
case (which is required for our config changes). Since on_poweroff
and on_crash already default to 'destroy', the install time config
is unchanged, and the post-install config now on_crash=destroy instead
of 'restart'.
The s390 on_crash=preserve workaround is dropped, which was intended
to avoid a reboot loop caused by on_crash=reboot
This includes adding an smbios sub-element to the guest os element and a
sysinfo sub-element to the guest. The sysinfo sub-element contains the SMBios
specific data.
If this flag is specified, --import|--boot will create a transient
libvirt domain, ie. one which goes away when the guest shuts down or
the host is rebooted.
(crobinso: some tweaks and tests)
continue_install is intended to facilitate windows XP style 3 stage
installs:
stage 1: initial dos style disk setup, reboot
stage 2: actual full installer, reboot
stage 3: OS is functional, virt-install is done
The code assumed that we needed to keep the cdrom as the primary
boot device for the second stage, so virt-install/virt-manager needed
to hang around through the second stage run, wait until the VM shutdown,
then encode the final XML to boot of the disk.
Windows is and always has been smart enough to handle that case though...
after the initial boot, if we set the hd as the primary boot device
for stage 2, the disk bits that windows already installed will make
use of the cdrom as necessary. So the entire premise of continue_install
is irrelevant. Maybe back when it was added, when xen didn't even have
working ACPI support, this served a purpose, but I'm pretty sure we
can safely drop it nowadays.
Commit f6322c9e changed the default bus type for disks to virtio.
That changed it for both disks and cdroms. The CD-ROMs dont work
if on virtio on pSeries. So, change the cdrom bus type to scsi as
before.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Extend virt-install-ppc64-pseries-f20 test to cover this case.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When booting from empty disk image or none bootdev, its leads
system IPL enter into infinite loop with message on s390x.
This patch sets preserve when on_crash to avoid the loop
Signed-off-by: Leno Hou <lenohou@gmail.com>
pSeries doesn't support ide and so was changed to use the scsi. virtio works
better on pSeries with better performance outcomes. Change the default to
virtio for disks
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Use virtio+accel3d by default whenever spice+gl is chosen. This allows
to easily set up accelerated gpu VM.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Originally we didn't add this since arm vexpress virtio only had 4
virtio-mmio slots. But the now-common -M virt target has 32 slots,
so we aren't starved.
