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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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)
It's been around for seven years, and even RHEL5 has it... I don't think
we need to work around platforms that don't have support for it.
Use this as an opportunity to simplify the surrounding code
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.
Only initialize VirtCLIParser at actual parse time. The data that's
passed to __init__ is the particular data for that parse task, like
the option string, and the Guest object we are editing.
As a result we can drop the whole parsermap handling, since the
parserlist is immutable.
There's a bunch of other reworks mixed in like dropping the
VirtOptionString abstraction...
So far we used only the last --extra-args argument from virt-install
command line, but it makes more sense to use all occurrences of
--extra-args and pass them to kernel.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Kernel for ppc64 automatically enables serial console, there is no need
to report any warning.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1247434
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
- Drop the warnings about incorrect console=, that's a little too fine
grained and was really only about virtio-console default confusion
which doesn't apply anymore
- Skip the check for xenpv which seems to always 'just work'
- Drop the opencoded arm check, use is_arm
- Fix an error when xen HVM is used (reported on virt-tools-list)
We are conservative here, only cleaning up disk images if libvirt
fails to even accept the XML. Otherwise the VM may already be
running or defined, and the user has to do some cleanup anyways.
Fix a regression where we used to report an error message if user
specified pxe installation without any network (--nonetworks or
--network none).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250382
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
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>
Try to use --boot uefi if the user hasn't already specified loader params,
or a kernel to boot. If we can't determine a UEFI setup, just print a
warning.
This was a weird bit of logic that tries to be smart, but there isn't
a clear corrolation between DISPLAY being unset and whether the user
wants graphics or not.
Make the default consistent, some people may need to adjust to
--nographics
This streamlines virt-manager and virt-install implementations, requiring
installer.distro_detect to be called if we want distro detection. As
a side effect, we now get CDROM detection for free.
Confusingly real ARM hardware can have either PC-like 8250 devices,
which the Linux kernel calls /dev/ttyS0, or ARM-only PL011-based
/dev/ttyAMA0.
qemu can emulate either, but the default for `-M virt' is the PL011
so /dev/ttyAMA0.
Change the warning message so it uses ttyAMA0 instead.
