When a domain is undefined, there are options to remove it's
managed save state or snapshots. However, there's another file
that libvirt creates per domain: the NVRAM variable store file.
Make sure that the file is not left behind if the domain is
undefined.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Coverity notes that after we VIR_ALLOC_N(params, nparams) a failed call to
virDomainGetCPUStats could result in nparams being set to -1. In that case,
the subsequent virTypedParamsFree in cleanup will pass -1 which isn't good.
Use the returned value as the number of stats to display in the loop as
it will be the value reported from the hypervisor and may be less than
nparams which is OK
Signed-off-by: John Ferlan <jferlan@redhat.com>
Coverity points out that if 'dom' isn't returned from virDomainQemuAttach,
then the code already jumps to cleanup, so there was no need for the
subsequent if (dom != NULL) check.
I moved the error message about failure into the goto cleanup on failure
and then removed the if (dom != NULL)
Signed-off-by: John Ferlan <jferlan@redhat.com>
Coverity points out that by using EMPTYSTR(type) we are guarding against
the possibility that it could be NULL; however, based on how 'type' was
initialized to NULL, then using nested ternary if-then-else's (?:?:)
setting either "ipv4", "ipv6", or "" - there is no way it could be NULL.
Since "-" is supposed to mean something empty in a field - modify the
nested ternary to an easier to read/process if-then-else leaving the
initialization to NULL to mean "-" in the formatted output.
Also changed the name from 'type' to 'typestr'.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Since 0766783abb
Coverity complains that the EDIT_FREE definition results in DEADCODE.
As it turns out with the change to use the EDIT_FREE macro the call to
vir*Free() wouldn't be necessary nor would it happen...
Prior code to above commitid would :
vir*Ptr foo = NULL;
...
foo = vir*GetXMLDesc()
...
vir*Free(foo);
foo = vir*DefineXML()
...
And thus the free was needed. With the change to use EDIT_FREE the
same code changed to:
vir*Ptr foo = NULL;
vir*Ptr foo_edited = NULL;
...
foo = vir*GetXMLDesc()
...
if (foo_edited)
vir*Free(foo_edited);
foo_edited = vir*DefineXML()
...
However, foo_edited could never be set in the code path - even with
all the goto's since the only way for it to be set is if vir*DefineXML()
succeeds in which case the code to allow a retry (and thus all the goto's)
never leaves foo_edited set
All error paths lead to "cleanup:" which causes both foo and foo_edited
to call the respective vir*Free() routines if set.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Tweak the messages so that they mention "title" rather than
"description" when operating in title mode. Also fixes one missing "%s"
before non-formatted gettext message.
Before:
$ virsh desc --title dom
No description for domain: dom
After:
$ virsh desc --title dom
No title for domain: dom
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140034
Total time of a migration and total downtime transfered from a source to
a destination host do not count with the transfer time to the
destination host and with the time elapsed before guest CPUs are
resumed. Thus, source libvirtd remembers when migration started and when
guest CPUs were paused. Both timestamps are transferred to destination
libvirtd which uses them to compute total migration time and total
downtime. Obviously, this requires the time to be synchronized between
the two hosts. The reported times are useless otherwise but they would
be equally useless if we didn't do this recomputation so don't lose
anything by doing it.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The parser accepts P and E, so the formatter should too.
* tools/virsh.c (vshPrettyCapacity): Handle larger units.
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit c1d75de caused this warning on 32-bit platforms (fatal when
-Werror is enabled):
virsh-domain.c: In function 'cmdBlockCopy':
virsh-domain.c:2003:17: error: comparison is always false due to limited range of data type [-Werror=type-limits]
Forcing the left side of the < to be ull instead of ul shuts up
the 32-bit compiler while still protecting 64-bit code from overflow.
* tools/virsh-domain.c (cmdBlockCopy): Add type coercion.
Signed-off-by: Eric Blake <eblake@redhat.com>
Expose the new power of virDomainBlockCopy through virsh (well,
all but the finer-grained bandwidth, as that is its own can of
worms for a later patch). Continue to use the older API where
possible, for maximum compatibility.
The command now requires either --dest (with optional --format
and --blockdev), to directly describe the file destination, or
--xml, to name a file that contains an XML description such as:
<disk type='network'>
<driver type='raw'/>
<source protocol='gluster' name='vol1/img'>
<host name='red'/>
</source>
</disk>
[well, it may be a while before the qemu driver is actually patched
to act on that particular xml beyond just parsing it, but the virsh
interface won't need changing at that time]
Non-zero option parameters are converted into virTypedParameters,
and if anything requires the new API, the command can synthesize
appropriate XML even if the --dest option was used instead of --xml.
The existing --raw flag remains for back-compat, but the preferred
spelling is now --format=raw, since the new API now allows us
to specify all formats rather than just a boolean raw to suppress
probing.
I hope I did justice in describing the effects of granularity and
buf-size on how they get passed through to qemu.
* tools/virsh-domain.c (cmdBlockCopy): Add new options --xml,
--granularity, --buf-size, --format. Make --raw an alias for
--format=raw. Call new API if new parameters are in use.
* tools/virsh.pod (blockcopy): Document new options.
Signed-off-by: Eric Blake <eblake@redhat.com>
I'm about to extend the capabilities of blockcopy. Hiding a few
common lines of implementation gets in the way of the new required
logic, and putting the new logic in the common implementation won't
benefit any of the other blockjob operations. Therefore, it is
simpler to just do the work inline. There should be no semantic
change in this patch.
* tools/virsh-domain.c (blockJobImpl): Move block copy guts...
(cmdBlockCopy): ...into their lone caller.
Signed-off-by: Eric Blake <eblake@redhat.com>
To date, anyone performing a block copy and pivot ends up with
the destination being treated as <disk type='file'>. While this
works for data access for a block device, it has at least one
noticeable shortcoming: virDomainGetBlockInfo() reports allocation
differently for block devices visited as files (the size of the
device) than for block devices visited as <disk type='block'>
(the maximum sector used, as reported by qemu); and this difference
is significant when trying to manage qcow2 format on block devices
that can be grown as needed.
Of course, the more powerful virDomainBlockCopy() API can already
express the ability to set the <disk> type. But a new API can't
be backported, while a new flag to an existing API can; and it is
also rather inconvenient to have to resort to the full power of
generating XML when just adding a flag to the older call will do
the trick. So this patch enhances blockcopy to let the user flag
when the resulting XML after the copy must list the device as
type='block'.
* include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_REBASE_COPY_DEV):
New flag.
* src/libvirt.c (virDomainBlockRebase): Document it.
* tools/virsh-domain.c (opts_block_copy, blockJobImpl): Add
--blockdev option.
* tools/virsh.pod (blockcopy): Document it.
* src/qemu/qemu_driver.c (qemuDomainBlockRebase): Allow new flag.
(qemuDomainBlockCopy): Remember the flag, and make sure it is only
used on actual block devices.
* tests/qemuxml2argvdata/qemuxml2argv-disk-mirror.xml: Test it.
Signed-off-by: Eric Blake <eblake@redhat.com>
Expose the new flag just added to virDomainGetBlockJobInfo.
With --raw, the presence or absence of --bytes determines which
flag to use in the single API call. Without --raw, the use of
--bytes forces an error if the server doesn't support it,
otherwise, the code tries to silently fall back to scaling the
MiB/s value.
My goal is to eventually also support --bytes in bandwidth mode;
but that's a bit further down the road (and needs a new API flag
added in libvirt.h first).
This changes the human output, but the previous patch added
raw output precisely so that we can have flexibility with the
human output. For this commit, I used qemu-monitor-command to
force an unusual bandwidth, but the same will be possible once
qemu implements virDomainBlockCopy:
Before:
Block Copy: [100 %] Bandwidth limit: 2 MiB/s
After:
Block Copy: [100 %] Bandwidth limit: 1048577 bytes/s (1.000 MiB/s)
The cache avoids having to repeatedly checking whether the flag
works when talking to an older server, when multiple blockjob
commands are issued during a batch session and the user is
manually polling for job completion.
* tools/virsh.h (_vshControl): Add a cache.
* tools/virsh.c (cmdConnect, vshReconnect): Initialize the cache.
* tools/virsh-domain.c (opts_block_job): Add --bytes.
* tools/virsh.pod (blockjob): Document this.
Signed-off-by: Eric Blake <eblake@redhat.com>
The current output of 'blockjob [--info]' is a single line
designed for human consumption; it's not very nice for machine
parsing. Furthermore, I have plans to modify the line in
response to the new flag for controlling bandwidth units.
Solve that by adding a --raw parameter, which outputs
information closer to the C struct.
$ virsh blockjob testvm1 vda --raw
type=Block Copy
bandwidth=1
cur=197120
end=197120
The information is indented, because I'd like for a later patch
to add a mode that iterates over all the vm's disks with status
for each; in that mode, each block name would be listed unindented
before information (if any) about that block.
Now that we have a raw mode, we can guarantee that it won't change
format over time. Any app that cares about parsing the output can
try --raw, and if it fails, know that it was talking to an older
virsh and fall back to parsing the human-readable format which had
not changed until now; meanwhile, when not using --raw, we have
freed future virsh to change the output to whatever makes sense.
My first change to human mode: this command now guarantees a line
is printed on successful use of the API, even when the API did
not find a current block job (consistent with the rest of virsh).
Bonus: https://bugzilla.redhat.com/show_bug.cgi?id=1135441
complained that this message was confusing:
$ virsh blockjob test1 hda --async --bandwidth 10
error: conflict between --abort, --info, and --bandwidth modes
even though the man page already documents that --async implies
abort mode, all because '--abort' wasn't present in the command
line. Since I'm adding another case where options are tied
to or imply a mode, I changed that error to:
error: conflict between abort, info, and bandwidth modes
* tools/virsh-domain.c (cmdBlockJob): Add --raw parameter; tweak
error wording.
* tools/virsh.pod (blockjob): Document it.
Signed-off-by: Eric Blake <eblake@redhat.com>
I have plans to make future enhancements to the job list mode,
which will be easier to do if the common blockJobImpl function
is not mixing a query command with multiple modify commands.
Besides, it just feels weird that all callers to blockJobImpl
had to supply both a bandwidth input argument (unused for info
mode) and an info output argument (unused for all other modes);
not to mention I just made similar cleanups on the libvirtd
side.
The only reason blockJobImpl returned int was because of info
mode returning -1/0/1 (all other job API are -1/0), so that
can also be cleaned up. No user-visible changes in this commit.
* tools/virsh-domain.c (blockJobImpl): Change signature and return
value. Drop info handling.
(cmdBlockJob): Handle info here.
(cmdBlockCommit, cmdBlockCopy, cmdBlockPull): Adjust callers.
Signed-off-by: Eric Blake <eblake@redhat.com>
Add "domstats" command that excercises both of the new APIs depending if
you specify a domain list or not. The output is printed as a key=value
list of the returned parameters.
resolves https://bugzilla.redhat.com/show_bug.cgi?id=1132305:
The error message for an out-of-range argument was confusing:
virsh -k 9999999999
error: option --k requires a positive numeric argument
After this patch, it is:
error: Invalid value for option -k
Signed-off-by: Eric Blake <eblake@redhat.com>
While prepping for virDomainBlockJob patches, I found some dead code.
* tools/virsh-domain.c (blockJobImpl): Kill unused 'name'.
Signed-off-by: Eric Blake <eblake@redhat.com>
net-undefine doesn't only undefine an inactive network,
but also an active network(persistent), it just cannot
undefine a transient network.
Signed-off-by: Li Yang <liyang.fnst@cn.fujitsu.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
* tools/virsh.pod (migrate): Add --auto-converge flag
Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
A possible fix to issue:
http://www.redhat.com/archives/libvir-list/2014-August/thread.html#00227
While doing migration on KVM host, found problem sometimes:
VM is already running on the target host and disappears from source
host, but 'virsh migrate' command line hangs, cannot exit normally.
If pressing "ENTER" key, it will exit.
The code hangs at tools/virsh-domain.c: cmdMigrate
->vshWatchJob->poll():
poll() is trying to select pipe_fd, which is used to receive message
from doMigrate thread. In debugging, found that doMigrate finishes
and at the end it does call safewrite() to write the retval ('0' or
'1') to pipe_fd, and the write is completed. But cmdMigrate poll()
cannot get the event. If pressing "ENTER" key, poll() can get the
event and select pipe_fd, then command line can exit.
In current code, authentication thread which is called by vshConnect
will use stdin, and at the same time, in cmdMigrate main process,
poll() is listening to stdin, that probably affect poll() to get
pipe_fd event. Better to move authentication before vshWatchJob. With
this change, above problem does not exist.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Implement ZFS storage backend driver. Currently supported
only on FreeBSD because of ZFS limitations on Linux.
Features supported:
- pool-start, pool-stop
- pool-info
- vol-list
- vol-create / vol-delete
Pool definition looks like that:
<pool type='zfs'>
<name>myzfspool</name>
<source>
<name>actualpoolname</name>
</source>
</pool>
The 'actualpoolname' value is a name of the pool on the system,
such as shown by 'zpool list' command. Target makes no sense
here because volumes path is always /dev/zvol/$poolname/$volname.
User has to create a pool on his own, this driver doesn't
support pool creation currently.
A volume could be used with Qemu by adding an entry like this:
<disk type='volume' device='disk'>
<driver name='qemu' type='raw'/>
<source pool='myzfspool' volume='vol5'/>
<target dev='hdc' bus='ide'/>
</disk>
This makes the paragaph about attach-interface more descriptive and
correct, adding in a few bits of information that were previously
missing, e.g. --script is only allowed for bridge interfaces of Xen
domains, target name is regenerated if it starts with vnet, mac
address will be autogenerated if not specified.
(I did this in response to an email asking why a script couldn't be
specified for a bridge interface of a qemu domain, and why an
interface of type='ethernet' couldn't be created with
attach-interface)
We parse the bandwidth rates as unsinged long long,
then try to fit them in VIR_TYPED_PARAM_UINT.
Report an error if they exceed UINT_MAX instead of
quietly using wrong values.
https://bugzilla.redhat.com/show_bug.cgi?id=1043735
https://bugzilla.redhat.com/show_bug.cgi?id=1072653
Upon successful upload of a volume, the target volume and storage pool
were not updated to reflect any changes as a result of the upload. Make
use of the existing stream close callback mechanism to force a backend
pool refresh to occur in a separate thread once the stream closes. The
separate thread should avoid potential deadlocks if the refresh needed
to wait on some event from the event loop which is used to perform
the stream callback.
Commit id '0e2d7305' modified the code to allow a negative value to be
supplied for the bandwidth argument of the various block virsh commands
and the migrate-setspeed; however, it failed to update the man page to
describe the "feature" whereby a very large value could be interpreted
by the hypervisor to mean maximum value allowed. Although initially
designed to handle a -1 value, the reality is just about any negative
value could be provided and essentially perform the same feature.
https://bugzilla.redhat.com/show_bug.cgi?id=1087104
Commit id 'c6212539' explicitly allowed a negative value to be used for
offset and length as a shorthand for the largest value after commit id
'f18c02ec' modified virStrToLong_ui() to essentially disallow a negative
value.
However, allowing a negative value for offset ONLY worked if the negative
value was -1 since the eventual lseek() does allow a -1 to mean the end
of the file. Providing other negative values resulted in errors such as:
$ virsh vol-download --pool default qcow3-vol2 /home/vm-images/raw \
--offset -2 --length -1000
error: cannot download from volume qcow3-vol2
error: Unable to seek /home/vm-images/qcow3-vol2 to 18446744073709551614: Invalid argument
$
Thus, it seems unreasonable to expect or allow a negative value for offset
since the only benefit is to lseek() to the end of the file and then only
take advantage of how the OS would handle such a seek. For the purposes of
upload or download of volume data, that seems to be a no-op. Therefore,
disallow a negative value for offset.
Additionally, modify the man page for vol-upload and vol-download to provide
more details regarding the valid values for both offset and length.
In many places we define a variable as a 'const char *' when in fact
we modify it just a few lines below. Or even free it. We should not do
that.
There's one exception though, in xenSessionFree() xenapi_utils.c. We
are freeing the xen_session structure which is defined in
xen/api/xen_common.h public header. The structure contains session_id
which is type of 'const char *' when in fact it should have been just
'char *'. So I'm leaving this unmodified, just noticing the fact in
comment.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Assign the value we're comparing:
(val = func()) < 0
instead of assigning the comparison value:
(val = func() < 0)
Both were introduced along with the code,
the TLS tests by commit bd789df in 0.9.4
net events by commit de87691 in 1.2.2.
Note that the event id type fix is a no-op:
vshNetworkEventIdTypeFromString can only return
-1 (failure) and the event is never used or
0 (the only possible event) and the value of 0 < 0 is still 0.
Snapshots and block-copy have a flag that forces qemu to re-use existing
file. Our docs weren't exactly clear on what the existing file should
contain for this to actually work.
Re-word the docs a bit to state that the file needs to be pre-created in
the desired format and the backing chain metadata needs to be set prior
to handing it over to qemu.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1084360
According to the code, 'virsh numatune' supports integers for
specifying --mode as well as the string definitions "strict",
"interleave", and "preferred". However, this possibility was not
documented anywhere, so this patch adds it to both the man page and
command help.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1085706
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Introduce flag for the block rebase API to allow the rebase operation to
leave the chain relatively addressed. Also adds a virsh switch to enable
this behavior.
Introduce flag for the block commit API to allow the commit operation to
leave the chain relatively addressed. Also adds a virsh switch to enable
this behavior.
Similary to cmdDetachDisk fetch the inactive definition when --config
is specified as the active may not contain the network interface
if it was plugged with --config.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1056902
https://bugs.gentoo.org/show_bug.cgi?id=508336
At wireshark, they have this promise to change public dissector APIs
only with minor version number change. Which they did when releasing
the version of 1.12.
Firstly, they've changed tvb_memdup() in
a0c53ffaa1bb46d8c9db2ec739401aa411c9790e so now it takes four arguments
instead of three. The new argument is placed at the very beginning of
the list of arguments and basically says the scope where we'd like to
allocate the memory. According to the documentation NULL should be the
default value.
Then, the tcp_dissect_pdus() signature changed too. Well, the function
that actually dissects reassembled packets as tcp_dissect_pdus()
reorder TCP packets into one big chunk and then calls a user function
to dissect the PDU at once. The change is dated back to
8081cf1d90397cbbb4404f9720595e1537ed5e14.
Then, WS_DLL_PUBLIC_NOEXTERN was replaced with WS_DLL_PUBLIC_DEF in
5d87a8c46171f572568db5a47c093423482e342f.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The rationale is to not duplicate code which is done in
packet-libvirt.h for instance. Moreover, this way we can drop
__attribute_((unused)) used int packet-libvirt.c in favor of
ATTRIBUTE_UNUSED.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The API is exposed under 'domcapabilities' command. Currently, with
the variety of drivers that libvirt supports, none of the command
arguments is obligatory, but all are optional instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
By default, the bus type is inferred from the style of the device
name('target' in this command), e.g. a device named 'sda' will
typically be exported using a SCSI bus. Actually, not only SCSI bus,
but USB/SATA bus also use this kind of device name. So add '--bus'
option for attach-disk command to allow user specify the target bus.
Signed-off-by: Yanbing Du <ydu@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Instead of maintaining two very similar APIs, add the "@mac" parameter
to virNetworkGetDHCPLeases and kill virNetworkGetDHCPLeasesForMAC. Both
of those functions would return data the same way, so making @mac an
optional filter simplifies a lot of stuff.
The new VIR_CONNECT_COMPARE_CPU_FAIL_INCOMPATIBLE flag for
virConnectCompareCPU can be used to get an error
(VIR_ERR_CPU_INCOMPATIBLE) describing the incompatibility instead of the
usual VIR_CPU_COMPARE_INCOMPATIBLE return code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Let's just open the file right away and deal with errors. Moreover,
there's no reason to forbid logging to, e.g., a pipe.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Use virNetworkGetDHCPLeases and virNetworkGetDHCPLeasesForMAC in virsh.
The new feature supports the follwing methods:
1. Retrieve leases info for a given virtual network
2. Retrieve leases info for given network interface
tools/virsh-domain-monitor.c
* Introduce new command : net-dhcp-leases
Example Usage: net-dhcp-leases <network> [mac]
virsh # net-dhcp-leases --network default6
Expiry Time MAC address Protocol IP address Hostname Client ID or DUID
-------------------------------------------------------------------------------------------------------------------
2014-06-16 03:40:14 52:54:00:85:90:e2 ipv4 192.168.150.231/24 fedora20-test 01:52:54:00:85:90:e2
2014-06-16 03:40:17 52:54:00:85:90:e2 ipv6 2001:db8:ca2:2:1::c0/64 fedora20-test 00:04:b1:d8:86:42:e1:6a:aa:cf:d5:86:94:23:6f:94:04:cd
2014-06-16 03:34:42 52:54:00:e8:73:eb ipv4 192.168.150.181/24 ubuntu14-vm -
2014-06-16 03:34:46 52:54:00:e8:73:eb ipv6 2001:db8:ca2:2:1::5b/64 - 00:01:00:01:1b:30:c6:aa:52:54:00:e8:73:eb
tools/virsh.pod
* Document new command
src/internal.h
* Introduce new macro: EMPTYSTR
In the 404bac14 the @tmp variable was introduced. It's purpose is to
avoid typecasting when parsing --pagesize argument. However, if the
argument is not presented, tmp may be used uninitialized resulting in
bogus virNodeGetFreePages() API call:
virsh freepages --cellno 2
error: Failed to open file '/sys/devices/system/node/node2/hugepages/hugepages-4294967295kB/free_hugepages': No such file or directory
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Commit 9e3efe53 broke the build under valgrind or clang, by writing
8 bytes through an allocation of 4 bytes. It also risks multiplication
overflow when mallocing (that's a pervasive problem that needs an
audit in the rest of the code, but we might as well fix this one while
we are here), and had a typo.
* tools/virsh-host.c (cmdFreepages): Avoid integer overflow and
undefined behavior.
Signed-off-by: Eric Blake <eblake@redhat.com>
Add knobs to virsh to manage a 2-phase active commit of the top
layer, similar to knobs already present on blockcopy. While this
code will fail until later patches actually implement the new
knobs in the qemu driver, doing it now proves that the API is
usable and also makes it easier for testing the qemu changes as
they are made.
* tools/virsh-domain.c (cmdBlockCommit): Add --active, --pivot,
and --keep-overlay options, modeled after blockcopy.
(blockJobImpl): Support --active flag.
* tools/virsh.pod (blockcommit): Document new flags.
(blockjob): Mention 2-phase commit interaction.
Signed-off-by: Eric Blake <eblake@redhat.com>
When the block job event was first added, it was for block pull,
where the active layer of the disk remains the same name. It was
also in a day where we only cared about local files, and so we
always had a canonical absolute file name. But two things have
changed since then: we now have network disks, where determining
a single absolute string does not really make sense; and we have
two-phase jobs (copy and active commit) where the name of the
active layer changes between the first event (ready, on the old
name) and second (complete, on the pivoted name).
Adam Litke reported that having an unstable string between events
makes life harder for clients. Furthermore, all of our API that
operate on a particular disk of a domain accept multiple strings:
not only the absolute name of the active layer, but also the
destination device name (such as 'vda'). As this latter name is
stable, even for network sources, it serves as a better string
to supply in block job events.
But backwards-compatibility demands that we should not change the
name handed to users unless they explicitly request it. Therefore,
this patch adds a new event, BLOCK_JOB_2 (alas, I couldn't think of
any nicer name - but at least Migrate2 and Migrate3 are precedent
for a number suffix). We must double up on emitting both old-style
and new-style events according to what clients have registered for
(see also how IOError and IOErrorReason emits double events, but
there the difference was a larger struct rather than changed
meaning of one of the struct members).
Unfortunately, adding a new event isn't something that can easily
be broken into pieces, so the commit is rather large.
* include/libvirt/libvirt.h.in (virDomainEventID): Add a new id
for VIR_DOMAIN_EVENT_ID_BLOCK_JOB_2.
(virConnectDomainEventBlockJobCallback): Document new semantics.
* src/conf/domain_event.c (_virDomainEventBlockJob): Rename field,
to ensure we catch all clients.
(virDomainEventBlockJobNew): Add parameter.
(virDomainEventBlockJobDispose)
(virDomainEventBlockJobNewFromObj)
(virDomainEventBlockJobNewFromDom)
(virDomainEventDispatchDefaultFunc): Adjust clients.
(virDomainEventBlockJob2NewFromObj)
(virDomainEventBlockJob2NewFromDom): New functions.
* src/conf/domain_event.h: Add new prototypes.
* src/libvirt_private.syms (domain_event.h): Export new functions.
* src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Generate two
different events.
* src/qemu/qemu_process.c (qemuProcessHandleBlockJob): Likewise.
* src/remote/remote_protocol.x
(remote_domain_event_block_job_2_msg): New struct.
(REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_2): New RPC.
* src/remote/remote_driver.c
(remoteDomainBuildEventBlockJob2): New handler.
(remoteEvents): Register new event.
* daemon/remote.c (remoteRelayDomainEventBlockJob2): New handler.
(domainEventCallbacks): Register new event.
* tools/virsh-domain.c (vshEventCallbacks): Likewise.
(vshEventBlockJobPrint): Adjust client.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
Peter's review of an early version of my addition of active block
commit pointed out some issues that I was copying from the block
copy code; fix them up now before perpetuating them.
For virsh commands that manage a single API call, it's nice to have
a 1:1 mapping of options to flags, so that we can test that
lower-layer software handles flag combinations correctly. But where
virsh is introducing syntactic sugar to combine multiple API calls
into a single user interface, we might as well make that interface
compact. That is, we should allow the shorter command-line of
'blockcopy $dom $disk --pivot' without having to explicitly specify
--wait, because this isn't directly a flag passed to a single
underlying API call.
Also, my use of embedded ?: ternaries bordered on unreadable.
* tools/virsh-domain.c (cmdBlockCopy): Make --pivot, --finish,
and --timeout imply --wait. Drop excess ?: operators.
* tools/virsh.pod (blockcopy): Update documentation.
Signed-off-by: Eric Blake <eblake@redhat.com>
The vcpupin command allowed specifying a negative number for the --vcpu
argument. This would the overflow when the underlying virDomainPinVcpu
API was called.
$ virsh vcpupin r7 -1 0
error: numerical overflow: input too large: 4294967295
Switch the vCPU variable to a unsigned int and parse it using the
corresponding function.
Also improve the vcpupin test to cover all the defects.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1101059
Signed-off-by: Jincheng Miao <jmiao@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
To follow the new semantics of the vshCommandOptToU* functions convert
this one to reject negative numbers too. To allow using -1 for "maximum"
semantics for the vol-*load two bandwidth functions that use this helper
introduce vshCommandOptULongLongWrap.
To follow the new semantics of the vshCommandOptToU* functions convert
this one to reject negative numbers too. To allow using -1 for "maximum"
semantics for the two bandwidth functions that use this helper introduce
vshCommandOptULWrap. Although currently the migrate-setspeed function
for the qemu driver will reject -1 as maximum.
Use virStrToLong_uip instead of virStrToLong_ui to reject negative
numbers in the helper. None of the callers expects the wraparound
"feature" for negative numbers.
Also add a function that allows wrapping of negative numbers as it might
be used in the future and be explicit about the new semantics in the
function docs.
the 'migration_host' description may be a bit difficult to
understand for some users, so enhance the manual
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Now that qemu 2.0 allows commit of the active layer, people are
attempting to use virsh blockcommit and getting into a stuck
state, because libvirt is unprepared to handle the two-phase
commit required by qemu.
Stepping back a bit, there are two valid semantics for a
commit operation:
1. Maintain a 'golden' base, and a transient overlay. Make
changes in the overlay, and if everything appears to work,
commit those changes into the base, but still keep the overlay
for the next round of changes; repeat the cycle as desired.
2. Create an external snapshot, then back up the stable state
in the backing file. Once the backup is complete, commit the
overlay back into the base, and delete the temporary snapshot.
Since qemu doesn't know up front which of the two styles is
preferred, a block commit of the active layer merely gets
the job into a synchronized state, and sends an event; then
the user must either cancel (case 1) or complete (case 2),
where qemu then sends a second event that actually ends the
job. However, until commit e6bcbcd, libvirt was blindly
assuming the semantics that apply to a commit of an
intermediate image, where there is only one sane conclusion
(the job automatically ends with fewer elements in the chain);
and getting stuck because it wasn't prepared for qemu to enter
a second phase of the job.
This patch adds a flag to the libvirt API that a user MUST
supply in order to acknowledge that they will be using two-phase
semantics. It might be possible to have a mode where if the
flag is omitted, we automatically do the case 2 semantics on
the user's behalf; but before that happens, I must do additional
patches to track the fact that we are doing an active commit
in the domain XML. Later patches will add support of the flag,
and once 2-phase semantics are working, we can then decide
whether to relax things to allow an omitted flag to cause an
automatic pivot.
* include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_COMMIT_ACTIVE)
(VIR_DOMAIN_BLOCK_JOB_TYPE_ACTIVE_COMMIT): New enums.
* src/libvirt.c (virDomainBlockCommit): Document two-phase job
when committing active layer, through new flag.
(virDomainBlockJobAbort): Document that pivot also occurs after
active commit.
* tools/virsh-domain.c (vshDomainBlockJob): Cover new job.
* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Explicitly
reject active copy; later patches will add it in.
Signed-off-by: Eric Blake <eblake@redhat.com>
Report CPU affinities / online CPUs in human-readable form when
this flag is present:
Before:
CPU Affinity: y-yy
After:
CPU Affinity: 0,2-3 (out of 4)
https://bugzilla.redhat.com/show_bug.cgi?id=985980
Our public free functions explicitly don't accept NULL pointers
(sigh). Therefore, callers must do something like this:
if (dev)
virNodeDeviceFree(dev);
And we are not doing that on two places I've found. This leads to
dummy error message thrown by virsh:
virsh # nodedev-dumpxml nonexistent-device
error: Could not find matching device 'nonexistent-device'
error: invalid node device pointer in virNodeDeviceFree
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When looking up storage volumes virsh uses multiple lookup steps. Some
of the steps don't require a pool name specified. This resulted into a
possibility that a volume would be part of a different pool than the
user specified:
Let's have a /var/lib/libvirt/images/test.qcow image in the 'default'
pool and a second pool 'emptypool':
Currently we'd return:
$ virsh vol-info --pool emptypool /var/lib/libvirt/images/test.qcow
Name: test.qcow
Type: file
Capacity: 100.00 MiB
Allocation: 212.00 KiB
After the fix:
$ tools/virsh vol-info --pool emptypool /var/lib/libvirt/images/test.qcow
error: Requested volume '/var/lib/libvirt/images/test.qcow' is not in pool 'emptypool'
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1088667
Commit d5c86278 was incomplete; other functions also triggered
compiler warnings about collisions in the use of 'sync'.
* src/qemu/qemu_driver.c (qemuDomainSetTime): Fix another client.
* tools/virsh-domain-monitor.c (cmdDomTime): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
The VIR_ENUM_DECL/VIR_ENUM_IMPL helper macros already append 'Type'
to the enum name being converted; it looks silly to have functions
with 'TypeType' in their name. Even though some of our enums have
to have a 'Type' suffix, the corresponding string conversion
functions do not.
* src/conf/secret_conf.h (VIR_ENUM_DECL): Rename virSecretUsageType.
* src/conf/storage_conf.h (VIR_ENUM_DECL): Rename
virStoragePoolAuthType, virStoragePoolSourceAdapterType,
virStoragePartedFsType.
* src/conf/domain_conf.c (virDomainDiskDefParseXML)
(virDomainFSDefParseXML, virDomainFSDefFormat): Update callers.
* src/conf/secret_conf.c (virSecretDefParseUsage)
(virSecretDefFormatUsage): Likewise.
* src/conf/storage_conf.c (virStoragePoolDefParseAuth)
(virStoragePoolDefParseSource, virStoragePoolSourceFormat):
Likewise.
* src/lxc/lxc_controller.c (virLXCControllerSetupLoopDevices):
Likewise.
* src/storage/storage_backend_disk.c
(virStorageBackendDiskPartFormat): Likewise.
* src/util/virstorageencryption.c (virStorageEncryptionSecretParse)
(virStorageEncryptionSecretFormat): Likewise.
* tools/virsh-secret.c (cmdSecretList): Likewise.
* src/libvirt_private.syms (secret_conf.h, storage_conf.h): Export
corrected names.
Signed-off-by: Eric Blake <eblake@redhat.com>
These APIs are exposed under new virsh command 'domtime' which both gets
and sets (not at the same time of course :)).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
For now, if only '--wipe-storage' is assigned, user can undefine a
domain normally. But actually '--wipe-storage' doesn't do anything,
and this may confuse user. Better is to require that '--wipe-storage'
only works if the user specifies volumes to be removed.
Before:
$ virsh undefine virt-tests-vm1 --wipe-storage
Domain virt-tests-vm1 has been undefined
After:
$ virsh undefine virt-tests-vm1 --wipe-storage
error: '--wipe-storage' requires '--storage <string>' or '--remove-all-storage'
Signed-off-by: Li Yang <liyang.fnst@cn.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
In "src/conf/" there are many enumeration (enum) declarations.
Similar to the recent cleanup to "src/util" directory, it's
better to use a typedef for variable types, function types and
other usages. Other enumeration and folders will be changed to
typedef's in the future. Most of the files changed in this
commit are related to storage (storage_conf) enums.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit 9976c4b9a6 broke the output for VNC
displays as the port number is converted to VNC display number by
subtracting 5900. This yields port 0 for the first display and thus the
output would be skipped.
Before:
$ virsh domdisplay VM
vnc://localhost
After:
$ tools/virsh domdisplay VM
vnc://localhost:0
The original comment of vshCmdInfo:
"name" - command name
Actually it's 'help' and the short description
of command, not the command name.
Signed-off-by: Li Yang <liyang.fnst@cn.fujitsu.com>
For now 'virsh quit' action like this:
--------------------------------
[root@localhost /]# virsh quit
[root@localhost /]#
--------------------------------
And 'virsh exit' action:
--------------------------------
[root@localhost /]# virsh exit
[root@localhost /]#
--------------------------------
There is a small difference('/n') between them.
According to manual said:
quit, exit
quit this interactive terminal
And in the code they all called cmdQuit func,
They should get same actions.
Signed-off-by: Li Yang <liyang.fnst@cn.fujitsu.com>
