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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
has_install_phase is an ambiguous name for its intended purpose.
Really this is so API users have a way of knowing if the VM `install`
process requires 2 XML phases or not. Make that naming explicit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This basically reverts this commit from virt-manager 4.0.0
```
commit 825ec644b8
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Mar 1 10:32:01 2022 -0500
installer: Do not force reboot with --cloud-init
Resolves: https://github.com/virt-manager/virt-manager/issues/189
```
After that commit, using `--cloud-init` or `--unattended` would
basically imply `--noreboot`
For some usage of `--cloud-init`, like in the initial report, this
makes sense to do. virt-install will drop you into the cloud image,
you mess without, run `poweroff`, and are surprised when virt-install
reboots the VM. I agreed, and made the change
But changing this was a bad idea.
cloud-init and unattended VMs have 2 XML phases. First XML is booting
off temporary media (the generated cloudinit iso), second XML is the
permanent boot config (booting off disk). We need to force the VM
to fully poweroff, so that the second XML config takes effect. We
make that happen with `<on_reboot>destroy</on_reboot>`, which tells
libvirt/qemu to poweroff the VM when it receives a guest reboot
notification. virt-install then defaults to restarting the VM when
it detects shutdown, to manually replicate the VM requested reboot,
but still get the second XML config to take effect.
The perennial problem with this is that, from outside the VM, we
don't know if the user inside the VM requested `poweroff` or `reboot`.
virt-install emulates the reboot behavior, and provides `--noreboot`
to override it. It's still confusing if a user puts a `poweroff`
command at the end of an anaconda kickstart file, and sees the VM
reboot, but it's been that way forever.
Except with that commit above, we flipped it for --cloud-init and
--unattended. Now, users who do `poweroff` are getting expected
behavior, but users who request `reboot` are not.
We could go further and add a `--yesreboot` option or similar. But
for consistency sake I think we should just revert that behavior,
and tell users to use --noreboot like usual.
Resolves: https://github.com/virt-manager/virt-manager/issues/497
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fix the cloud-init config file for --clouduser-ssh key.
Also change ssh_authorized_keys to `ssh_authorized_keys`, and make sure
default user is not deleted when setting ssh key for root.
Fixes commit 22478f307d (virt-install: Add --cloud-init clouduser-ssh-key=)
Resolves: https://github.com/virt-manager/virt-manager/issues/452
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
This won't make any difference on x86, where either SATA or IDE
is used depending on the machine type, but on other architectures
we want virtio-scsi for a reasonable chance that the guest OS
will recognize the disk.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
When shim in the guest sees unpopulated EFI NVRAM, like when
we create a new UEFI VM, it invokes fallback.efi to populate
initial NVRAM boot entries. When the guest also has a TPM device,
shim will do a one time VM reset. This reset throws off the
reboot detection that is central to virt-install's install
process.
The main install case that this will usually be relevant is
the combo of UEFI and --cloud-init. The latter usually implies
use of a distro cloud image, which will be using shim, and the
--cloud-init process requires a multi stage install compared
to just a plain import install.
For that case, we disable the default TPM device for the first
boot.
https://bugzilla.redhat.com/show_bug.cgi?id=2133525
Signed-off-by: Cole Robinson <crobinso@redhat.com>
`sudo` throws errors and is not even required to write the `disable`
file. Also add a message to the file that it was created by us
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Originally we thought it would be for the clouduser, but then
we changed it, and now it's ambiguous. Rename it to make the
usage clear, and add an alias to keep any users working
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The Guest object passed in by the user is no longer altered in place,
instead we act on copies of the original XML. We need to rework how
unattended/cloudinit device altering works a bit to handle this.
There's some XML churn because working on parsexml gives different
output ordering, but this is expected.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Previously we tried to use a combination of distro class and version
number to produce a correct ordering that was independent of the
osinfo short ID. The original intent was to have correct ordering
for Windows entries in the virt-manager UI, since the short ID
values are all over the place.
Nowadays that doesn't really matter, since we weed out old
unsupported entries by default. And in the mean time, our current
sort method gives some weird results like interspersing silverblue
entries with fedora entries.
Using a natural/human sort is simpler and handles things pretty well.
Change the UI to sort by the OS label too which preserves some of
the good behavior of original method
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Any of the commands involved in injecting files into an initrd
could fail, and if that happens we should interrupt the
installation instead of proceeding as if nothing had happened.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Commit c6b5f22fa6 started passing the --owner argument to
cpio when injecting files into the initrd to comply with the
more strict requirements introduced by systemd starting with
Fedora 30.
However, cpio only started accepting the +uid:+gid syntax in
version 2.12, which means that the fix actually broke the
initrd inject functionality completely in RHEL 7 and other
distros that don't include a recent enough cpio.
Use the user:group syntax instead, which is understood by
all versions of cpio, including non-GNU ones.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Fixes: #291
The `text=` keyword was added in Python 3.7 "as a more readable
alias for `universal_newlines=`". This commit switches to the
old form of the name, for backwards compatibility with Python 3.6,
the default Python3 version on Ubuntu 18.04 and RHEL 8.
When support for Python 3.6 is no longer needed, this change can
be reverted.
* Simplify start() and end() function signature
* Drop use of 'basename' and standardize on 'text'
* Add vmmMeter.is_started()
* Add vmmMeter.set_text()
* Fix asyncjob UI to show text in the progress bar
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We didn't delete this in the last commit, mostly to make it easier
to revert this commit if it turns out we need to support both isoinfo
and xorriso. Right now I don't know of any reason why that should
be necessary but time will tell.
If we do go that route it will take more work to teach urlfetcher
to dynamically detect the presence of one or the other, along with
similar tweaks.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
xorisso is the still maintained isoinfo alternative, and may be
the only iso reading tool in RHEL9, so we need to support it.
Make it the default for our spec file and test suite too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Apparently it's the most likely version to exist in distros these
days. Particularly the other options may not be shipped in stock
RHEL9
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Rather than 1K. This drastically speeds up the volumeupload case
for a local URI for the cost of some higher runtime memory but
I think that's worth it
Fixes: #221
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This makes it more clear that 'path' is really a special designation
with a bunch of complicated logic behind it. It's also easier to
grep for
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We do this by faking an install phase whenever cloudinit media is
specified, which isn't really the right abstraction and will leak
into virt-install behavior (like doing 2 boots), but it's the simplest
fix for now
Fixes: #178
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When starting many virt-install processes in parallel, some often crash
with
ERROR [Errno 17] File exists: '/home/kstest/.cache/virt-manager/boot'
Fix that by ignoring existing directories instead of explicitly testing
for existence.
The `exist_ok` parameter exists since Python 3.2, and the minimum
supported version is 3.4 now.
* rename kernelupload.py to volumeupload.py and make the entrypoint
more generic
* move all upload invocation to the Installer class
* use it with cloudinit and unattended ISO generation if required
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Use the VERSION file not only to detect whether the tree is a Mageia
tree, but also to detect the version.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Add data/urldetect with a bunch of distro tree content to trigger
full code coverage of virtinst/install/urldetect.py
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I can't find any publicly available media to test this case, I'm
not sure it does anything useful anyways, so just drop it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Do not split the error messages and the error details, but rather use a
single string with proper placeholders. This avoids string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Ubuntu 20.04 has a new installer, which is yet not supported by
virt-install / osinfo-db, and this made ubuntu switch their URLs
for the old installer to current/legacy-images/... instead of
current/images/...
Let's adapt URL detect so it can deal with this new "legacy"
style.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Rather than build a guest and installer instance depending on where
we are in the UI, track each input property in an explicit class, so
we can rebuild the guest/installer on demand with data accumulated
up to that point.
This makes the flow easier to follow and simplifies a lot of hacks we
have to do when backing up through the wizard, because we are trying
to unwind changes from an existing object, rather than just blowing
it away and easily reassembling it with updated info.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
