The Windows unattended installation is quite similar to the Linux one
with a few major differences:
- It uses floppy injection instead of initrd injection
- Yes, it does. Then we have to create a floppy, add the device and,
when finishing the installation, remove the device;
- There's no InstallerTreeMedia in the game making us end up duplicating
some code in the Installer class as:
- keeping track of files that have to be cleanup up;
- actually cleaning up the files;
- generating the install script
Apart from that, some obvious differences in the scripts where already
done in a previous commit, but those were basically:
- Not using /dev/*da as a target disk, but use "C" instead;
- Set the product-key
- Explicitly set the injection method as "floppy"
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
s390x guests usually detect the sclp or virtio console. The current
warning might actually break setups. Let us disable the warning.
Reported-by: Andre Wild <wild1@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
When dealing with unattended installation, we safely can assume that
"--cdrom" can be treated as "--location". The reason for that is that
we'll need to, under the hooks, extract its kernel/initrd and perform an
initrd injection.
This commit makes "--unattended" work properly when combined with
"--cdrom".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
--unattedend now can be used to perform tree based installations.
The way it's implemented, it takes advantage of the code we currently
have for setting --os-variant install="location|cdrom".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As --unattended will take care of generating the install script to be
inject in the initrd and also of the kernel command line to be used
during the installation, we should not mix whatever user is passing as
--initrd-inject or --extra-args when using --unattended.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
--unattended is currently a no-op parameter that will be used to perform
unattended installations.
For now, if someone tries to use --unattended virt-install will fail as
the option is still not supported.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As os-variant has a new "install" parameter that can be passed, let's
take advantage of it and automatically fill options.location with data
from osinfo-db whenever install=location is passed (and, of course,
osinfo-db has the information).
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Commit 45ab922b2c moved the code to the way it was before the libosinfo
default changes. However, by not setting "options.disk" the parser will
error out and bail the installation as this option must be set. Only
parsing the disk doesn't seem to be enough as the check is actually done
against "options.disk".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This could break some command line invocations, but there's no
guarantee libosinfo might not add capitalized IDs in the future,
and there's an easy workaround to just lowercase the passed value
So we validate the CDROM disk contents too. This revealed we were
using a cdrom path in the test driver that was assigned as a
writeable disk to another test VM, which is a correct warning, so
fix the fallout, and ensure that we don't warn when colliding with
another cdrom device
This is how it was before the libosinfo defaults changes. In general
this pattern is more sensible: we serialize all the Guest data, then
create the installer which acts on a Guest, then fill in any missing
config with libosinfo bits.
We need to manually parse a disk option string now which is a bit funky
There's two cases: for an explicitly requested --os-variant, we
want to set it ASAP, since more things will depend on it in the
future, like grabbing install media from libosinfo. For the
'auto' case, we need to wait until the installer is setup.
Add kernel= and initrd= --location suboptions. These can be
used to override the default kernel/initrd and specify new
paths, relative to LOCATION.
For example, if you have an ISO that libosinfo doesn't know
about called my-unknown.iso, with a kernel at 'kernel/fookernel'
and initrd at +'kernel/fooinitrd', you can make this work with:
--location my-unknown.iso,kernel=kernel/fookernel,initrd=kernel/fooinitrd
If no disk options are passed, let's fallback to the libosinfo
recommended disk size for the OS variant.
The guest.set_capabilities_default(), build_installer() and the set of
the distro variant have been moved earlier in the code in order to fetch
the correct information from libosinfo and then set the recommended disk
size without changing much of build_guest_instance() logic.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
With this patchset, the general options completion is available. ex:
$ virt-install -<TAB><TAB>
...
--arch --check --cpu --dry-run -h
--autostart --clock --cputune --events --help
...
$ virt-install --a<TAB><TAB>
--arch --autostart
Signed-off-by: Lin Ma <lma@suse.com>
The --os-variant option doesn't quite fit perfectly into
its current "Installation method" group, plus we want to
add the same option to virt-xml which can't have that
group for obvious reasons.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Now we have only one Installer class, and callers don't need to
worry about choosing a particular class type depending on their
needs, just pass cdrom vs. location to the installer init and
we figure out everything behind the scenes.
Besides simplifying the callers this makes the control flow a
lot easier to follow whether looking at InstallerTreeMedia or
Installer classes
Rather than forcing API users to go through the capabilities APIs.
This lets us simplify things in virt-install quite a bit, and is
needed for smarter machine type defaults
This changes all the callers to invoke start_install directly on the
Installer object. We still stash the installer instance inside the
guest object in create.py, just for simplicity
The validation is already handled by libvirt, and setting q35 for
smm=on is overkill and just hardcoding some libvirt logic here.
I think the 'secboot' detection in Guest.py is the preferred
magic here, otherwise let users specify all the correct values.
The copyright headers in every file were chjanged in this previous commit
commit b6dcee8eb7
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Mar 20 15:00:02 2018 -0400
Use consistent and minimal license header for every file
Where before this they said "
"either version 2 of the License, or (at your option) any later version."
Now they just say
"GNU GPLv2"
This fixes it to say "GNU GPLv2 or later" again.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The way we enumerate devices doesn't conform with the way all
other XMLBuilder instances expose child objects. Move more towards
that direction.
This requires some virt-xml and cli.py hacks but we will remove those
in future patches
Previously os-variant was not being set before performing location
checks. This lead to a sitation where the os-variant data could not be
acted on. This commit re-orders the process to ensure that the correct
ordering happens.
Previous behavior:
```
[Thu, 11 May 2017 12:28:30 virt-install 19296] DEBUG (distroinstaller:180) DistroInstaller location is a network source.
[Thu, 11 May 2017 12:28:30 virt-install 19296] DEBUG (distroinstaller:181) Sanitized value is https://example.com/repo/rhel/7/rhel-7-server-rpms/
[Thu, 11 May 2017 12:28:30 virt-install 19296] DEBUG (urlfetcher:57) Using scratchdir=/home/bharrington/.cache/virt-manager/boot
[Thu, 11 May 2017 12:28:30 virt-install 19296] DEBUG (urlfetcher:477) Finding distro store for location=https://example.com/repo/rhel/7/rhel-7-server-rpms/
[Thu, 11 May 2017 12:28:30 virt-install 19296] DEBUG (urlfetcher:484) Using os-variant=generic
[Thu, 11 May 2017 12:28:30 virt-install 19296] DEBUG (urlfetcher:486) Supplying urldistro=None
[Thu, 11 May 2017 12:28:34 virt-install 19296] DEBUG (urlfetcher:186) HTTP hasFile request failed: 404 Client Error: Not Found for url: https://example.com/repo/rhel/7/rhel-7-server-rpms/Fedora
[Thu, 11 May 2017 12:28:34 virt-install 19296] DEBUG (urlfetcher:145) hasFile(https://example.com/repo/rhel/7/rhel-7-server-rpms/Fedora) returning False
[Thu, 11 May 2017 12:28:34 virt-install 19296] DEBUG (urlfetcher:1114) No treearch found in uri, defaulting to arch=i386
...
```
Current behavior:
```
[Thu, 11 May 2017 13:20:37 virt-install 22335] DEBUG (distroinstaller:180) DistroInstaller location is a network source.
[Thu, 11 May 2017 13:20:37 virt-install 22335] DEBUG (guest:250) Setting Guest.os_variant to 'rhel7.3'
[Thu, 11 May 2017 13:20:37 virt-install 22335] DEBUG (urlfetcher:57) Using scratchdir=/home/bharrington/.cache/virt-manager/boot
[Thu, 11 May 2017 13:20:37 virt-install 22335] DEBUG (urlfetcher:477) Finding distro store for location=https://example.com/repo/rhel/7/rhel-7-server-rpms/
[Thu, 11 May 2017 13:20:38 virt-install 22335] DEBUG (urlfetcher:499) Prioritizing distro store=<class 'virtinst.urlfetcher.RHELDistro'>
```
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>
Fabiano Fidêncio