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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This was raised here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
Quoting from that:
"""
virt-convert takes an ovf/ova or vmx file and spits
out libvirt XML. It started as a code drop a long time ago that could
translate back and forth between vmx, ovf, and virt-image, a long dead
appliance format. In 2014 I converted it to do vmx -> libvirt and ovf ->
libvirt which was a CLI breaking change, but I never heard a peep of a
complaint. It doesn't seem to do a particularly thorough job at its
intended goal, I've seen 2-3 bug reports in the past 5 years and
generally it doesn't seem to have any users. Let's kill it. If anyone
has the desire to keep it alive it could live as a separate project
that's a wrapper around virt-install but there's no compelling reason to
keep it in virt-manager.git IMO
"""
Nothing has changed since then, so here is the removal.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Removing this was discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
This is the old default, where we would try to determine a static
keymap value from host graphics config files, and set that in the
XML.
We haven't defaulted to this for a long time, setting a static keymap
is suboptimal generally, and the file parsing code is not up to date
for modern host config. So let's remove it
The hostkeymap module is now unused, so remove it and all the custom
testing for it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Removing this was discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
For a decade, qemu and xen and virt-manager work together to
make setting a manual keymap redundant. Advertising it in the UI does
more harm than good, because users may think they need to specify
one when in the vast majority of cases it will give worse behavior.
With the XML editing UI, users still have a way to do this by hand
if they really know what they are doing.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We shouldn't be validating against a static list of keymaps,
instead we should let libvirt or the hypervisor throw and error.
Also the accompanying code is about to be removed.
It's possible this will break command line usage for some users, like
if they were passing keymap=US and depending on our logic to lower()
it for them. I think this should be rare, and IMO it's acceptable to
tell users to just fix their command line, which should work correctly
with older versions too, so it should be a one time fix.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
My previous patch was misguided as pointed out by Pavel:
https://github.com/virt-manager/virt-manager/issues/73#issuecomment-574680435
And it was setting incorrect memory, which I missed because the tests
are busted here. Add a hack to work around that
Bump up the default to 1024, and print it, so the user can tell if
the default is not to their liking
Signed-off-by: Cole Robinson <crobinso@redhat.com>
AFAICT the driver doesn't really do anything with it, but libvirt
XML requires it. So just default to --memory 64
Fixes: #73
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We need to restore logging after calling the cli tools. Centralize
the logging reset behavior since we need that too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Libvirt is able to figure this out and it will make usage of the CLI
options more user-friendly.
For example if users wants to add a new pcie-root-port to existing VM
they have to figure out the latest controller index and call it like
this:
virt-xml \
--add-device \
--controller pci,model=pcie-root-port,index=$nextIndex \
$VM
After this change it will be simply:
virt-xml \
--add-device \
--controller pci,model=pcie-root-port \
$VM
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Cloud images all work nicely with text output, and it's likely
the preferred native way to connect to the guest vs graphical.
Plus it simplifies generated password copy+paste
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Now --cloud-init defaults to root-password-generate=yes,disable=yes.
Option for plaintext password given through the cli is completely removed.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: Athina Plaskasoviti <athina.plaskasoviti@gmail.com>
Tests now cover default --cloud-init behavior, and
root-password=(generate and given password),disable=no.
Signed-off-by: Athina Plaskasoviti <athina.plaskasoviti@gmail.com>
When running virt-install as root, user-login would be automatically set
to "root", causing an installation failure in the most part of the
distros (if not all of them).
In order to avoid such failures, let's raise a runtime error in case the
user-login used is "root".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's allow setting the login of the guest user.
Using the user from the system is a quite good fallback, but would break
unattended installations when running virt-install as root. Thus, for
those cases, it makes sense to have the option of setting the user
login.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As some OSes, as Fedora, have variants (which we rely to be standardised
on osinfo-db side), let's select the most appropriate variant according
to the selected profile of the unattended installation.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Some OSes, as Fedora, have variants (which we rely to be standardised on
osinfo-db side), which we can use to return the most generic tree
possible, in case no profile is specified, in order to avoid failing to
install a "Workstation" system because a "Server" variant tree was used.
https://bugzilla.redhat.com/show_bug.cgi?id=1749865
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
QEMU version 2.12.1 introduced a performance feature under commit
be7773268d98 ("target-i386: add KVM_HINTS_DEDICATED performance hint").
Support for this performance hint was added in libvirt 5.7.0 by commit
cb12c59dac04 ("qemu: support for kvm-hint-dedicated performance hint").
This patch extends virt-install's existing --features option to insert the
appropriate XML into the guest definition if this feature is specified
on the command line.
E.g. --features='kvm.hint-dedicated.state=on' would result
in the following XML:
<features>
...
<kvm>
<hint-dedicated state='on'/>
</kvm>
...
</features>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
Some osed have multiple short-ids, like debian10 also has debianbuster.
Use the API if it's available. This will make it easier to remove
our back compat aliases eventually
This was originally added so we had stable paths in the XML. It's
not required anymore, and if it becomes an issue we should fix it
by scrubbing the compared xml
