* Renaming HACKING.md to CONTRIBUTING.md, special github naming
* Point to modern virt-manager.org bug link
* Mention option to use github issue tracker
* Point to the github wiki for more contribution docs
* Many minor updates
The <domain> XML it alters is called <seclabel>, and security is
really generic sounding. Add the alias and switch the documentation
over to prefer --seclabel
There is a new security feature 'md-clear' that mitigates recent CPU
Microarchitectural Store Buffer Data vulnerability.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* backend_connect_host -> backend.source.connect_host
* backend_connect_service -> backend.source.connect_service
* backend_host -> backend.source.host
* backend_mode -> backend.source.mode
* backend_service -> backend.source.service
* backend_type -> backend.type
* rate_bytes -> rate.bytes
* rate_period -> rate.period
'type', and 'device' are kept as advertised options,
due to them being commonly specified and documented
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* protocol -> protocol.type
* target_address -> target.address
* name -> target.name
* target_type -> target.type
'host', 'path', 'mode', and 'bind_host' are kept as advertised options,
due to them being commonly specified and documented
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* cid -> cid.address
* auto_cid -> cid.auto
Add man docs for --vsock while we are at it, since they are missing
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* driver_queues -> driver.queues
* master -> master.startport
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* suspend_to_disk -> suspend_to_disk.enabled
* suspend_to_mem -> suspend_to_mem.enabled
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* cell[0-9]*.cpus -> numa.cell[0-9]*.cpus
* cell[0-9]*.distances.sibling[0-9]*.id -> numa.cell[0-9]*.distances.sibling[0-9]*.id
* cell[0-9]*.distances.sibling[0-9]*.value -> numa.cell[0-9]*.distances.sibling[0-9]*.value
* cell[0-9]*.id -> numa.cell[0-9]*.id
* cell[0-9]*.memory -> numa.cell[0-9]*.memory
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
- device_path -> device.path
- device_weight -> device.weight
We shouldn't be duplicating libvirt documentation here. If someone
needs <virtualport> config, they are likely working backwards from
working XML and trying to figure out the command line. Drop most
of the details
Sort out the memory property naming ambiguity on the command line.
* memory -> currentMemory
* maxmemory -> memory
* hotplugmemorymax -> maxMemory
* hotplugmemoryslots -> maxMemory.slots
To maintain back compat, we need to do some funky handling with
memory and maxmemory values. Basically if currentMemory is specfied,
we interpret them as new style, otherwise preserve the old behavior.
This will allow users to override the default behavior of virt-install
which copies CPU security features available on the host to the guest
XML if specific CPU model is configured.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add kernel= and initrd= --location suboptions. These can be
used to override the default kernel/initrd and specify new
paths, relative to LOCATION.
For example, if you have an ISO that libosinfo doesn't know
about called my-unknown.iso, with a kernel at 'kernel/fookernel'
and initrd at +'kernel/fooinitrd', you can make this work with:
--location my-unknown.iso,kernel=kernel/fookernel,initrd=kernel/fooinitrd
The --os-variant option doesn't quite fit perfectly into
its current "Installation method" group, plus we want to
add the same option to virt-xml which can't have that
group for obvious reasons.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Add vcpupin support to virt-install so that it can create guest
domains with statically allocated vcpu pinning towards a given cpuset.
Syntax: to pin vcpu=0 to cpuset="1,3" and vcpu=1 to cpuset=2
--cputune vcpupin0.vcpu=0,vcpupin0.cpuset=1,3,vcpupin1.vcpu=1,vcpupin1.cpuset=2
generates below XML description for the guest domain.
<cputune>
<vcpupin vcpu="0" cpuset="1,3"/>
<vcpupin vcpu="1" cpuset="2"/>
</cputune>
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
libvirt supports guest CPU cache by commit df13c0b, So add this feature
to virt-install to configure cpu L3 cache mode.
Currently, The valid values are 'passthrough', 'emulate' or 'disable'.
say:
--cpu host-passthrough,cache.mode=passthrough
or
--cpu $CPU,cache.mode=emulate,cache.level=3
or
--cpu $CPU,cache.mode=disable
Signed-off-by: Lin Ma <lma@suse.com>
There are multiple models of the panic device, the address type is only
one and is valid only for "isa" model.
To not break the virt-install/virt-xml the command line parser needs to
be updated. Before this patch there was only one parameter that
configured the "iobase". Now the first parameter configures a model
but to keep it backward compatible it follows these rules:
1. there is only one parameter and it matches known model:
--panic isa
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
2. there is only one parameter and it doesn't match any model:
--panic 0x505
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
3. there are two parameters:
--panic isa,iobase=0x505
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Cole Robinson