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
