Correcting the error reporting method by using VSH_REQUIRE_OPTION
instead of virReportError
Signed-off-by: Kothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1349898
Add the duration parameters to the virsh input/output for blkdeviotune
command and describe them in the pod file.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rework the repetitive lines to add iotune values into easier to read macros.
One to handle the SCALED values and one to handle the non scaled values.
Signed-off-by: John Ferlan <jferlan@redhat.com>
If the VM is offline virsh attempted to at least report the pinning
information for the VM. This would not work properly now that the vcpus
can be sparse. Fix it by getting the vcpu states from the XML.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1375920
The fallback code used if virDomainGetVcpusFlags is not supported used
wrong XPath queries and basically did not work at all. Fix them to point
to the <domain> <vcpu> element instead of <vcpus> which was not present
until lately.
For one VM, it could had more than one graphical display.
Such as we coud add both vnc and spice display to a VM.
This patch introduces '--all' for showing all
possible graphical display of a active VM.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
For compatibility reasons virDomainSetVcpus needs to add vcpus as non
hotpluggable which means that the users will not be able to unplug it
after the VM has started. Add a flag that will allow to tell the API
that the unpluggable vcpus are okay.
When using
virsh net-event non-existing-net
the error message says that 'either --list or event type is required'
This is misleading as 'virsh net-event $valid-event-type' is not going
to work either. What is expected is 'virsh net-event --event
$valid-event-type'
This commit fixes the string in pool-event, nodedev-event, event, and
net-event.
virVcpuInfo contains the vcpu number that the data refers to. Report
what's returned by the daemon rather than the sequence number as with
sparse vcpu topologies they won't match.
Turn various vshPrint() informative messages into vshPrintExtra(), so
they are not printed when requesting the quiet mode; neither XML/info
outputs nor the results of commands are affected.
Also change the expected outputs of the virsh-undefine test, since virsh
is invoked in quiet mode there.
Some informative messages might still be converted (and thus silenced
when in quiet mode), but this is an improvements nonetheless.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358179
The prettified JSON string already contains a newline so don't print
another one. This allows to pipe the json output (in conjunction with
the --quiet option) to files without having to truncate them afterwards.
They can be used to tune auto-convergence algorithm (which is enabled
with VIR_MIGRATE_AUTO_CONVERGE).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Thanks to our smart option parser which automatically assigns positional
parameters the following (previously working) command fails:
virsh migrate test qemu+ssh://1.2.3.4/system tcp://1.2.3.4/
error: invalid argument: Unsupported compression method
'tcp://1.2.3.4/'
We need to make sure new options are added at the end of the list rather
than where they logically belong.
Reported by Brian Rak.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Extend the lxc-enter-namespace command so that it joins the
containers' cgroups before starting new namespaces. This
ensures that the commands run have the normal resource
limits applied
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently if a guest has listen address 0.0.0.0 or [::] and you run
"virsh domdisplay $domain" you always get "spice://localhost:$port".
We want to print better address if someone is connected from a different
computer using "virsh -c qemu+ssh://some.host/system". This patch fixes the
behavior of virsh to print in this case "spice://some.host:$port".
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1332446
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=885380
Use vshCommandOptScaledInt instead of vshCommandOptULongLong so that
values with suffixes can be passed when bytes are being passed along.
Values for the iops parameters still need to be given in the absolute
form as they are not bytes but numbers.
Signed-off-by: Nishith Shah <nishithshah.2211@gmail.com>
cmdDetachInterface function checks for live config
flags and then passes the live/config domain xml
to virshDomainDetachInterface accordingly.
Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>
After failing to parse the perf event list, the code would return
failure without freeing the previously acquired object. Rearrange the
code to avoid the problem.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1329046
Since we didn't opt to use one single event for device lifecycle for a
VM we are missing one last event if the device removal failed. This
event will be emitted once we asked to eject the device but for some
reason it is not possible.
When using the --start option, the show_count should not be set to
max_id as the --start <cpu> means we dont need those many initial cpu
stats. Hence, show_count should be adjusted accordingly.
https://bugzilla.redhat.com/show_bug.cgi?id=1249441
Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Now that we have @flags we can support changing perf events just
in active or inactive configuration regardless of the other.
Previously, calling virDomainSetPerfEvents set events in both
active and inactive configuration at once. Even though we allow
users to set perf events that are to be enabled once domain is
started up. The virDomainGetPerfEvents API was flawed too. It
returned just runtime info.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Everywhere else we use a comma separated list. There's no good
reason to make 'perf' command an exception. Currently, it accepts
string list separated by '|'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
I've noticed that these APIs are missing @flags argument. Even
though we don't have a use for them, it's our policy that every
new API must have @flags.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
