We have a few of senarios that libvirtd would invoke qemuProcessStop
and leave a "shutting down" in /var/log/libvirt/qemu/$DOMAIN.log.

The shutoff reason showing in debug log is also very important
for us to know why VM shutting down in domain log,
as we seldom enable debug log of libvirtd.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1322717

During offline migration, no storage is copied. Nor disks, nor
NVRAM file, nor anything. We use qemu for that and because domain
is not running there's nobody to copy that for us.
We should document this to avoid confusing users.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Calling virDomainGetEmulatorPinInfo on a live VM with automatic NUMA
pinning and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning
data in some cases which is bogus. Use the autoCpuset property only when
called on a live definition.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1365779

Calling virDomainGetVcpuPinInfo on a live VM with automatic NUMA pinning
and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning data
in some cases which is bogus. Use the autoCpuset property only when
called on a live definition.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1365779

Sometimes adding a separate variable to access vm->privateData is not
necessary. Add a macro that will do the typecasting rather than having
to add a temp variable to force the compiler to typecast it.

Return whether the live or persistent definition was returned. Sometimes
it's necessary to base the decisions on this.

Old libvirt represents

    <graphics type='spice'>
      <listen type='none'/>
    </graphics>

as

    <graphics type='spice' autoport='no'/>

In this mode, QEMU doesn't listen for SPICE connection anywhere and
clients have to use virDomainOpenGraphics* APIs to attach to the domain.
That is, the client has to run on the same host where the domains runs
and it's impossible to tell the client to reconnect to the destination
QEMU during migration (unless there is some kind of proxy on the host).

While current libvirt correctly ignores such graphics devices when
creating graphics migration cookie, old libvirt just sends

    <graphics type='spice' port='0' listen='0.0.0.0' tlsPort='-1'/>

in the cookie. After seeing this cookie, we happily would call
client_migrate_info QMP command and wait for SPICE_MIGRATE_COMPLETED
event, which is quite pointless since the doesn't know where to connecti
anyway. We should just ignore such cookies.

https://bugzilla.redhat.com/show_bug.cgi?id=1376083Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Checking if a domain's definition or if it is active before we got a job
is pointless since the domain might have changed in the meantime.

Luckily libvirtd didn't crash when the API tried to talk to an inactive
domain:

debug : qemuDomainObjBeginJobInternal:2914 : Started job: modify
    (async=none vm=0x7f8f340140c0 name=ble)
debug : qemuDomainObjEnterMonitorInternal:3137 : Entering monitor
    (mon=(nil) vm=0x7f8f340140c0 name=ble)
warning : virObjectLock:319 : Object (nil) ((unknown)) is not a
    virObjectLockable instance
debug : qemuMonitorOpenGraphics:3505 : protocol=spice fd=27
    fdname=graphicsfd skipauth=1
error : qemuMonitorOpenGraphics:3508 : invalid argument: monitor must
    not be NULL
debug : qemuDomainObjExitMonitorInternal:3160 : Exited monitor
    (mon=(nil) vm=0x7f8f340140c0 name=ble)
debug : qemuDomainObjEndJob:3068 : Stopping job: modify (async=none
    vm=0x7f8f340140c0 name=ble)
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

We can receive NULL as sync reply in two situations. First
is garbage sync reply and this situation is handled by
resending sync message. Second is different cases
of rebooting guest, destroing domain etc and we can
give more meaningful error message. Actually we have
this error message in qemuAgentCommand already which checks
for the same sitatuion. AFAIK case with mon->running
is just to be safe on adding some future(?) cases of
returning NULL reply.

We can easily handle receiving garbage on sync. We don't
have to make client deal with this situation. We just
need to resend sync command but this time garbage is
not be possible.

When we wait for sync reply we can receive delayed
reply to syncs or commands that were sent erlier. We can
safely skip them until we receive sync reply with correct id.
There is no much sense report this situation to client.
Actually with a bit of "luck" if we involve client into
this the play can go on forever: send sync 0, receive
sync reply -1, send sync 1, receive reply 0 ...

After sync is sent we can receive garbare and this is not error.
Consider next regular case:

1. libvirtd sends sync
2. qga sends partial sync reply and die
3. libvirtd sends sync
4. qga sends sync reply
5. libvirtd receives garbage
  (half of first reply and second reply together)

We should handle this situation as it is recoverable.
Next sync can succeed. Let's report reply is NULL,
it will be converted to the VIR_ERR_AGENT_UNSYNCED
which signals client to retry.

Errors in qemuAgentIOProcessLine stop agent IO processing just
like any regular IO error, however some of current errors
that this functions spawns are false positives. Consider
next case for example:

1. send sync (unsynced state)
2. receive sync reply (sync established)
3. command send, but timeout occured (unsynced state)
4. receive command reply

Last IO triggers error because current code ignores
only delayed syncs when unsynced

We should not treat any delayed reply as error in unsynced
state. Until client and qga are not in sync delayed reply to any
command is possible. msg == NULL is the exact criterion
that we are not in sync.

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

There will be more backends in the future so let's not complicate it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Put it into qemuDomainPrepareShmemChardev() so it can be used later.
Also don't fill in the path unless the server option is enabled.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Always format id first so that we don't need to do that twice in
different code paths.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Some checks will need to be performed for newer device types as well, so
let's not duplicate them.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This will make sense after adding support for newer device types.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

It isn't used anywhere else.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit 839a0608 tied the lifecycle of virtlogd more
closely to that of libvirtd. Unfortunately, while starting
virtlogd when libvirtd is started is definitely a good idea,
restarting virtlogd or shutting it down at any time outside
of system poweroff is not.

Revert part of that commit by removing the PartOf= lines,
meaning that only startup requests will be propagated from
libvirtd to virtlogd.

Resolves: https://bugzilla.redhat.com/1372576

Make use of the new recently introduced alias handling for virt-admin srv-*
commands.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Change the logic in a way, so that VSH_CMD_FLAG_ALIAS behaves similarly to
how VSH_OT_ALIAS for command options, i.e. there is no need for code duplication
for the alias and the aliased command structures. Along with that change,
switch any existing VSH_CMD_FLAG_ALIAS occurrences to this new format. Also,
since this patch introduces a new command structure element, adjust the
virsh-self-test test to make sure we won't ever miss to specify the '.alias'
member for an aliased command because doing that would lead to an internal
error.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The command is deprecated due to being grammatically incorrect, but for
backwards compatibility reasons cannot be removed. However, we should not
document such commands.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Recent changes extracted the command internals validation routine from
vshCmddefOptParse method which now just calls vshCmddefOptFill. Therefore, make
vshCmddefOptFill the new vshCmddefOptParse and drop the unnecessary name.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Originally introduced by commit 2432521e which correctly split
vshCmddefOptParse into command's options validation and options parsing.
However, command's 'internals' are not tied solely to .options, rather it
should be about the overall structure, therefore the validation should be
extracted from vshCmddefOptParse and performed only within our test suite, i.e.
in vshSelfTest.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

If the initial check is true the function immediately returns so there's no
need to enclose the code following the check within an 'else' block.
Also, by removing the 'else' block, the declarations need to be moved to
beginning of the function block to conform with our guidelines.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since it's used on a single place only, it can easily be replaced by the right
side of the original assignment.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The intention is to move vshCmddefCheckInternals out of vshCmddefOptParse to
our test suite. First step to do that is to enforce checking for an existing
help string (that also means it's non-empty) in a command because a command
without a help is not much of a use.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The recent update to gnulib

  commit 9d7a37ec
  Author: Eric Blake <eblake@redhat.com>
  Date:   Thu Sep 15 15:12:52 2016 -0500

    build: update to latest gnulib

Pulled in a change that adds -fno-common to the default compiler
flags

  commit bf8e658ffadb95d444f56d222d04c9af955af765
  Author: Jim Meyering <meyering@fb.com>
  Date:   Fri Sep 2 09:16:16 2016 -0700

    manywarnings: add -fno-common

This caused libvirt Mingw build to break with the compiler
reporting 100's of definitions of virConnectAuthPtrDefault

./.libs/libvirt_util.a(libvirt_util_la-virarch.o):virarch.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):viralloc.c:(.bss+0x0): first defined here
./.libs/libvirt_util.a(libvirt_util_la-viratomic.o):viratomic.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87: first defined here
./.libs/libvirt_util.a(libvirt_util_la-viraudit.o):viraudit.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87: first defined here
./.libs/libvirt_util.a(libvirt_util_la-virauth.o):virauth.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
./.libs/libvirt_util.a(libvirt_util_la-viralloc.o):/home/berrange/src/virt/libvirt/src/util/viralloc.c:87: first defined here
./.libs/libvirt_util.a(libvirt_util_la-virauthconfig.o):virauthconfig.c:(.bss+0x0): multiple definition of `virConnectAuthPtrDefault'
...snip...

The cause is our VIR_EXPORT_VAR macro which has some
magic on win to add dllexport/dllimport to the variable
declaration. Unfortunately the dllexport branch missed
off the 'extern' keyword, so the header file was in
fact declaring an instance of the variable in every
source file.

Previously the linker would merge all these definitions
into one, but that no longer happens due to -fno-common
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>