List of valid arch's for virt-install
Hi Everyone, I'm converting about 150 Virtual Box vm's to QEMU/KVM using `qemu-img convert` followed by a `virt-install`. The vm's are a mix of amd64, i686 and mx32, and they will run on a amd64 machine. I want to use the `virt-install --arch` option during the conversion. 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? 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? Thanks in advance. [1] https://manpages.org/virt-install
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' - name="alpha" name="armv6l" name="armv7l" name="aarch64" name="cris" name="i686" name="m68k" name="microblaze" name="microblazeel" name="mips" name="mipsel" name="mips64" name="mips64el" name="ppc" name="ppc64" name="ppc64le" name="riscv32" name="riscv64" name="s390x" name="sh4" name="sh4eb" name="sparc" name="sparc64" name="x86_64" name="xtensa" name="xtensaeb"
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.) Someone more knowledgeable will probably weigh in with a more conclusive answer. -- Connor
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
On 12/13/24 2:18 AM, Andrea Bolognani wrote:
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 ;)
Cool! TIL. My distro version must be too old but I'll keep that one in mind. $ virsh capabilities --xpath '//arch/@name' error: command 'capabilities' doesn't support option --xpath -- Connor
On Fri, Dec 13, 2024 at 07:12:04AM -0800, Connor Kuehl wrote:
On 12/13/24 2:18 AM, Andrea Bolognani wrote:
I think something like this is a reasonable fallback:
$ virsh capabilities | xmllint --xpath '//arch/@name' -
Or
$ virsh capabilities --xpath '//arch/@name'
even ;)
Cool! TIL. My distro version must be too old but I'll keep that one in mind.
$ virsh capabilities --xpath '//arch/@name' error: command 'capabilities' doesn't support option --xpath
It was introduced in 9.3.0 (May 2023) so if you're on some slow-moving distro like Debian stable you won't have it yet. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Connor Kuehl -
Jeffrey Walton