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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
All our virt-install/virt-clone compare tests aren't actually
attempting to define the XML, meaning we could be generating bogus
output. Enable it, then fix the fallout, mostly some places we are
triggering libvirt XML validation
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
