virt: allow defining the VM type and arch when creating it #49510
Conversation
|
@cachedout @rallytime this one PR should be fairly straight forward |
salt/modules/virt.py
Outdated
| type of virtualization as found in the ``//os/type`` element of the libvirt definition. | ||
| The default value is taken from the host capabilities, with a preference for ``hvm``. | ||
|
|
||
| .. versionadded:: Fluorine |
salt/modules/virt.py
Outdated
| architecture of the virtual machine. The default value is taken from the host capabilities, | ||
| but ``x86_64`` is prefed over ``i686``. | ||
|
|
||
| .. versionadded:: Fluorine |
salt/modules/virt.py
Outdated
| @@ -1200,6 +1197,8 @@ def _get_merged_nics(hypervisor, profile, interfaces=None, dmac=None): | |||
| def init(name, | |||
| cpu, | |||
| mem, | |||
| os_type=None, | |||
There was a problem hiding this comment.
These new parameters need to go at the end of the list so we don't break things for people if they are using positional arguments.
cbosdo
force-pushed
the
virt-arch-ostype
branch
2 times, most recently
from
5488afa
to
fd6404d
Compare
Some hypervisors can handle several CPU architectures or have different virtualization types. This is reflected in libvirt by the OS type (badly named, indeed) and the arch value. Allow users to set them when creating a VM using either virt.init or virt.running. Signed-off-by: Cédric Bosdonnat <cbosdonnat@suse.com>
Not all disk target devices should start with 'vd' for non-vmware hypervisors. Map the bus type to the right device name prefix. While at it, also make sure the disks are created right for xen.
cbosdo
force-pushed
the
virt-arch-ostype
branch
from
fd6404d
to
2c456f5
Compare
|
The second commit being a bug fix, may be backported to Fluorine. |
|
Hey @rallytime , the changes on this PR are part of @cbosdo's work around the virt module which has been already included in Some of the related PRs are #48736, #48421, #48261, #48262, etc. which are all included on Since this PR is still related with the previous ones and also contains a bugfix, it would be really nice to get this PR also into Would that be even possible at this point in time? Thanks! |
|
@cachedout I don't expect any other backports: the other ones can wait for a future release |
|
@cbosdo That sounds good. In the future let's keep the feature additions and bug fixes in separate PRs so it's easier to get the bug fixes in the right place. I am OK with backporting this one, but just in the future to make it simpler. :D |
|
@rallytime noted |
rallytime
added
the
bugfix-bckport
|
Thanks! I'll get this backported right now. |
|
Thanks @rallytime ! 👍 |
|
@cbosdo Actually, this isn't backporting cleanly and is including more changed files than it should because of some additional work it's pulling in from a kwarg addition around the |
rallytime
removed
the
bugfix-bckport
|
@rallytime sure |
|
@rallytime Should I change the versionadded back to Fluorine, then? |
|
@cbosdo Yeah! Thanks for catching that. |
|
@rallytime I changed them in the backport PR, how should I handle that for develop? open a new PR? |
|
@cbosdo No need to do anything for develop. I will merge forward and there will be a conflict on those lines. I'll take the |
Fluorine backport of pr #49510
What does this PR do?
Some hypervisors can handle several CPU architectures or have different
virtualization types. This is reflected in libvirt by the OS type (badly
named, indeed) and the arch value. Allow users to set them when creating
a VM using either virt.init or virt.running.
What issues does this PR fix or reference?
None
Previous Behavior
virt.initandvirt.runningwhere forcing x86_64 HVM virtual machines when creating them.New Behavior
User can choose the architecture and VM type to be created
Tests written?
Yes
Commits signed with GPG?
Yes