Re: List of valid arch's for virt-install
On Wed, Dec 11, 2024 at 08:32:55PM -0800, Connor Kuehl wrote:
On 12/11/24 7:43 AM, Jeffrey Walton wrote:
> The man page for virt-install [1] does not list valid arch's. (I can't
> find a page for virt-install at libvirt.org).
> Where can I find the list of valid arch's for virt-install?
Hmm, yeah, it seems the --arch argument doesn't support the usual method
for enumerating possible values (which to be fair, the man page says *some*
suboptions support that):
$ virt-install --arch=?
ERROR Host does not support any virtualization options for architecture '?'
I think something like this is a reasonable fallback:
$ virsh capabilities | xmllint --xpath '//arch/@name' -
Or
$ virsh capabilities --xpath '//arch/@name'
even ;)
Note that in general --foo=? only lists the various options that are
available as arguments for --foo, not the values that those options
can take.
For example, --controller=? will mention that --controller accepts a
model option, but won't list all the valid models. So the handling of
--arch=? is consistent.
It would be fantastic if virt-install would list values as well.
Might be hard or even impossible to implement, but opening an issue
suggesting that couldn't hurt.
> A related question is, if I also specify `--cpu host` to ensure
the
> host cpu's ISA's are available to the vm, then will that conflict with
> the `--arch arch` option?
I don't know for certain, as I haven't tried, but I'd guess that'd be
fine if the host and the guest are the same (e.g., amd64 host, amd64 guest.)
In general, 32-bit x86 guests will run just fine on 64-bit x86
hardware. So using the host CPU model shouldn't be a problem.
In fact, you could likely go further and just use x86_64 hardware
across the board. Same as you could, if you wanted, install a 32-bit
OS on your 64-bit x86 laptop.
That said, I've encountered issues in the past when running Debian
GNU/Hurd (at the time only available in a 32-bit variant) with
host-passthrough CPU on my AMD host.
The filesytem would get fairly reliably corrupted, which I initially
brushed off as the OS simply not being that stable. But then I
noticed that the same wasn't happening at all on a different host
with an Intel CPU...
Long story short, I configured the guest to use the qemu64 CPU model
and it has been running with zero issues on my AMD host ever since.
That's probably a bit heavy handed and I could have gotten away with
a more recent Intel CPU model, but I didn't have much reason to go
back and revisit the choice.
--
Andrea Bolognani / Red Hat / Virtualization