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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- use a single translatable message, instead of splitting the text in
two; it helps translators to have the full context/text
- improve the language a bit
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
This is essentially what it has always behaved as, but making it
explicit in the code will now trigger the extra warnings when
detect=on is also used.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Using `detect=on,name=OSNAME` is good for CI safety, incase
a new distro tree has a regression with detection, or if testing
against a new distro that osinfo-db doesn't know about.
But virt-install should still try to inform the user that detection
failed, and suggest filing a bug if the user expected it to work.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It's kinda hard to follow the logic here. cli require= can only be
on|off or unset, but we use an internal 'auto' value which seems
like it can come from the cli.
Try to clean it up with enum like values.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
We can make `--xml` fit the common xml cli option paradigm, which
less us drop a whole bunch of special handling in virt-xml
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Adjust cli.py `run_parser` and similar functions to take the
parservalue directly, rather than passing in the whole `options`
structure.
This makes it easier to reason about what the virt-xml action
functions are actually working with.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Nowadays it could be as simple as `virt-install --install fedora36`.
Trying to represent the interdepencies here is not worth it, but
let's keep a simple string around to avoid the default parser
usage string, which is huge
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Anything passed to --boot should imply --install no_install=yes
in the absence of other --install options. This is historically
what we've done but we regressed in 4.1.0
Resolves: https://github.com/virt-manager/virt-manager/issues/426
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Each bit here is part of the CLI API, we need to be sure we are
covering each one. Extend the test suite to hit one case we are missing
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We need to change the flow from
* parse all the strings
* set capabilities defaults
* build installer
* fill in all guest defaults
To
* parse boot and metadata strings
* set capabilities defaults
* build installer
* set --name default
* parse all the remaining strings
* fill in all guest defaults
Because --disk parsing depends on --name for some path generation.
So this fixes --disk names when --name is implicitly specified by
--install or --osinfo
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It's generally not as valuable for non-x86 where we don't have the
history of supporting non-virtio OSes, but as time goes on it will
likely become more relevant for non-x86 arches, so let's make this
change now to get ahead of it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was previously discussed here:
https://listman.redhat.com/archives/virt-tools-list/2020-September/msg00017.html
For the x86 + hvm case, failure to specify an --osinfo/--os-variant
OS, and failure to detect an OS from install media, will now throw
a big error:
```
--os-variant/--osinfo OS name is required, but no value was
set or detected.
This is now a fatal error. Specifying an OS name is required
for modern, performant, and secure virtual machine defaults.
If you expected virt-install to detect an OS name from the
install media, you can set a fallback OS name with:
--osinfo detect=on,name=OSNAME
You can see a full list of possible OS name values with:
virt-install --osinfo list
If your Linux distro is not listed, try one of generic values
such as: linux2020, linux2018, linux2016
If you just need to get the old behavior back, you can use:
--osinfo detect=on,require=off
Or export VIRTINSTALL_OSINFO_DISABLE_REQUIRE=1
```
The thread goes into more detail, but basically, for x86 VMs at least,
it's unlikely you will _ever_ want the default 'generic' behavior,
which gives gives no virtio, no PCIe, no usb3, IDE disks, slow
network devices, etc.
Many people use virt-install in scripts and CI, and this may now
cause breakage. The environment variable is there to help them
get things back to normal as quick as possible, but it will still
noisy up their logs with the warning to hopefully get them to make
a useful change to their virt-install invocations.
This is limited to x86, since that's where most of our defaults
historically differ, and where we can depend on libosinfo to give
the most accurate device info. This may be relevant to change for
other KVM architectures in the future.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently we skip the warning if the user explicitly requests
`--osinfo generic`. Upcoming changes to the defaults here will make
it tempting to specify `--osinfo generic` just to make things work,
and we want to dissuade that, so enable the warning for that case too.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We are about to change the some defaults around os handling. Let's
start recommending the nicer named --osinfo more, since new error
messages are going to promote it a bit as well
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I'm still seeing blog posts that recommend using
--os-type linux --os-variant XXX
Which has been a no op for a long time but is mostly harmless.
Current git would make this an error condition, but that's too
disruptive IMO. Just print a warning
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The canonical tool for this is `osinfo-query os`, which we still
reference in the man pages and in the list output.
However, we are about to make missing --os-variant fatal for common
usage, and I don't want to force users to install an extra tool just
to figure out what an acceptable --os-variant value is.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The sync_vcpus_topology method will sometimes set the self.vcpus prop,
but other times leave it unset. This is confusing an unhelpful
behaviour. Both callers have logic to set the self.vcpus prop
to a default value of sync_vcpus_topology failed to do so. It makes
more sense to just pass this default value in.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Make use of the new helper for showing a standard error message for two
conflicting cli options. This also catches one untranslatable message.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
If specified, this errors if no OS name was detected or manually set.
So --os-variant detect=on,require=on will error if no OS is detected.
name= can be used as a fallback, so test and document this case
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds the following --os-variant suboptions
* name=, short-id=
* id=
* detect=on|off
Functionally this does not change behavior, just adds explicit
sub options for behavior we already support
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The --xml option allows users to request raw XML edits to virt-install
or virt-xml generated XML. This gives users a bit of a workaround
incase we don't have proper support for some XML property. The --xml
option can gain more features in the future if it makes sense, like
setting XML namespaces for example.
Basic usage is like: virt-install --xml ./@foo=bar ...
Which will change the generated <domain> XML to have
<domain foo='bar' ...
virt-xml works similarly. It can only be combined with --edit currently.
This only works with xpaths rooted against the entire document.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Similar to behavior we have in virt-manager, if the user destroys the
VM during the VM install process, don't invoke the post install
reboot.
https://bugzilla.redhat.com/show_bug.cgi?id=1818089
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Use plural forms for strings that depend on a runtime value, like a
count. This way they will get the proper string for the actual value.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use two different strings in case there is a timeout and there is none.
Also add a "the" article to make it slightly better.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
There's valid cases where a VM can be defined with a conflicting MAC
address. Prior to ebd6091cc8 and related refactorings we were more
lax here if the conflicting VM wasn't running, but now we are blocking
some valid usage.
Hoist the validation check up to cli.py and add --check mac_in_use=off
to skip the validation. Advertise it like we do for other checks, so
now a collision error will look something like:
The MAC address '22:11:11:11:11:11' is in use by another virtual
machine. (Use --check mac_in_use=off or --check all=off to override)
Reported-by: Pino Toscano <ptoscano@redhat.com>
Signed-off-by: Cole Robinson <crobinso@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>
Googling for 'Graphics requested but DISPLAY is not set' shows there's
some confusion about virt-install's behavior in this area. This gives
more output in several related cases about what commands we are
running and the state of the VM
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This layout is closer to what most python modules have nowadays.
It also simplifies testing and static analysis setup.
Keep virt-* wrappers locally, for ease of running these commands
from a git checkout.
Adjust the wrapper binaries we install on via packaging to be
pure python, which makes things like running gdb easier.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
