If qemudDomainRestore fails to open the domain save file, create a
pipe, then fork a process that does setuid(qemu_user) and opens the
file, then reads this file and stuffs it into the pipe. the parent
libvirtd process will use the other end of the pipe as its fd, then
reap the child process after it's done reading.

This makes domain restore work on a root-squash NFS share that is only
visible to the qemu user.

* src/qemu/qemu_driver.c: add new qemudOpenAsUID() helper function,
  and use it in qemudDomainRestore() if reading as root directly failed.

The USB/PCI device hotplug code for the QEMU driver was forgetting
to allocate a unique device alias.

* src/qemu/qemu_driver.c: Fill in device alias for USB/PCI devices

The code assumed that 'device_add' returned an empty string upon
success. This is not true, it sometimes prints random debug info.
THus we need to check for an explicit fail string

* src/qemu/qemu_monitor_text.c: Fix error checking of the device_add
  monitor command

Another warning caught by coverity.  Continue to perform best-effort
closing and resource release, but warn the caller about the failure.

* src/esx/esx_driver.c (esxClose): Return an error on failure to close.

Coverity detected a potential dereference of uninitialized memory
if recvfrom got cut short.

* src/uml/uml_driver.c (umlMonitorCommand): Validate complete read
prior to dereferencing res.

Various safezero() implementations used either -1, errno or -errno
return values. This patch fixes them all to return -1 and set errno
appropriately.

There was also a bug in size parameter passed to safewrite() which could
result in an attempt to write gigabytes out of a megabyte buffer.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When a VM save attempt failed, the VM would be left in a paused
state. It is neccessary to resume CPU execution upon failure
if it was running originally

* src/qemu/qemu_driver.c: Resume CPUs upon save failure

This supports cancellation of jobs for the QEMU driver against
the virDomainMigrate, virDomainSave and virDomainCoreDump APIs.
It is not yet supported for the virDomainRestore API, although
it is desirable.

* src/qemu/qemu_driver.c: Issue 'migrate_cancel' command if
  virDomainAbortJob is issued during a migration operation
* tools/virsh.c: Add a domjobabort command

This defines the wire protocol for the new API

* src/remote/remote_protocol.x: Wire protocol definition
* src/remote/remote_driver.c,daemon/remote.c: Client and server
  side implementation
* daemon/remote_dispatch_args.h, daemon/remote_dispatch_prototypes.h,
  daemon/remote_dispatch_table.h, src/remote/remote_protocol.c,
  src/remote/remote_protocol.h: Re-generate from remote_protocol.x

This provides the internal glue for the driver API

* src/driver.h: Internal API contract
* src/libvirt.c, src/libvirt_public.syms: Connect public API
  to driver API
* src/esx/esx_driver.c, src/lxc/lxc_driver.c, src/opennebula/one_driver.c,
  src/openvz/openvz_driver.c, src/phyp/phyp_driver.c,
  src/qemu/qemu_driver.c, src/remote/remote_driver.c,
  src/test/test_driver.c src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
  src/xen/xen_driver.c: Stub out entry points

Introduce support for  virDomainGetJobInfo in the QEMU driver. This
allows for monitoring of any API that uses the 'info migrate' monitor
command. ie virDomainMigrate, virDomainSave and virDomainCoreDump

Unfortunately QEMU does not provide a way to monitor incoming migration
so we can't wire up virDomainRestore yet.

The virsh tool gets a new command 'domjobinfo' to query status

* src/qemu/qemu_driver.c: Record virDomainJobInfo and start time
  in qemuDomainObjPrivatePtr objects. Add generic shared handler
  for calling 'info migrate' with all migration based APIs.
* src/qemu/qemu_monitor_text.c: Fix parsing of 'info migration' reply
* tools/virsh.c: add new 'domjobinfo' command to query progress

* src/remote/remote_protocol.x: Define wire protocol format
  for virDomainGetJobInfo API
* src/remote/remote_driver.c, daemon/remote.c: Implement client
  and server marshalling code for virDomainGetJobInfo()
* daemon/remote_dispatch_args.h, daemon/remote_dispatch_prototypes.h
  daemon/remote_dispatch_ret.h, daemon/remote_dispatch_table.h,
  src/remote/remote_protocol.c, src/remote/remote_protocol.h: Rebuild
  files from src/remote/remote_protocol.x

The internal glue layer for the new pubic API

* src/driver.h: Define internal driver API contract
* src/libvirt.c, src/libvirt_public.syms: Wire up public
  API to internal driver API
* src/esx/esx_driver.c, src/lxc/lxc_driver.c, src/opennebula/one_driver.c,
  src/openvz/openvz_driver.c, src/phyp/phyp_driver.c,
  src/qemu/qemu_driver.c, src/remote/remote_driver.c,
  src/test/test_driver.c, src/uml/uml_driver.c, src/vbox/vbox_tmpl.c,
  src/xen/xen_driver.c: Stub new entry point

All other uses of get_str_prop in this file that ignored
failure explicitly cast to void.

* src/node_device/node_device_hal.c (dev_create): Silence coverity
warning.

A number of the error messages raised when parsing USB devices
refered to PCI devices by mistake

* src/qemu/qemu_conf.c: s/PCI/USB/ in qemuParseCommandLineUSB()

The USB hotplug method was mistakenly generating a PCI address
string

* src/qemu/qemu_driver.c: Fix USB hotplug device string

when the underlying qemu supports the drive/device model and the
controller has been added this way.
* src/qemu/qemu_driver.c: use qemuMonitorDelDevice() when detaching
  PCI controller and if supported
* src/qemu/qemu_monitor.[ch]: add new qemuMonitorDelDevice() function
* src/qemu/qemu_monitor_json.[ch]: JSON backend for DelDevice command
* src/qemu/qemu_monitor_text.[ch]: Text backend for DelDevice command

* src/qemu/qemu_driver.c: in qemudDomainDetachPciControllerDevice()
  when a controller is not present in the system anymore, the PCI
  address must be deleted from libvirt's hashtable because it can
  be re-used for other purposes.

* src/qemu/qemu_driver.c: in qemudDomainAttachDevice(), one must not
  delete the data part when the operation succeeds because it is
  required later on. The correct pattern to handlethe parsed
  representation of the device information on success
  is dev->data.controller = NULL; virDomainDeviceDefFree(dev);,
  which leaves the structure pointed at by data in memory.

* src/cpu/cpu_x86.c (x86Decode): Don't dereference NULL when passed
a NULL "models" pointer, or when passed a nonzero "nmodels" value
and a corresponding NULL models[i].

* src/phyp/phyp_driver.c (phypUUIDTable_Push): Move incr/decr
of ptr/nread into the loop where those variables are used.
Also, remove "exit" label and just-preceding "goto".

* src/openvz/openvz_driver.c (openvzDomainDefineCmd): Remove
useless increment of "max_veid".

Allow an arbitrary timezone with QEMU by setting the $TZ environment
variable when launching QEMU

* src/qemu/qemu_conf.c: Set TZ environment variable if a timezone
  is requested
* tests/qemuxml2argvtest.c: Add test case for timezones
* tests/qemuxml2argvdata/qemuxml2argv-clock-france.xml,
  tests/qemuxml2argvdata/qemuxml2argv-clock-france.args: Data
  for timezone tests

This extends the XML to allow for

  <clock offset='timezone' timezone='Europe/Paris'/>

This is useful if the admin has not configured any timezone on the
host OS, but still wants to synchronize a guest to a specific one.

* src/conf/domain_conf.h, src/conf/domain_conf.c: Support extra
  'timezone' attribute on clock configuration
* docs/schemas/domain.rng: Add 'timezone' attribute
* src/xen/xend_internal.c, src/xen/xm_internal.c: Reject configs
  with a configurable timezone

This allows QEMU guests to be started with an arbitrary clock
offset

The test case can't actually be enabled, since QEMU argv expects
an absolute timestring, and this will obviously change every
time the test runs :-( Hopefully QEMU will allow a relative
time offset in the future.

* src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Use the -rtc arg
  if available to support variable clock offset mode
* tests/qemuhelptest.c: Add QEMUD_CMD_FLAG_RTC for qemu 0.12.1
* qemuxml2argvdata/qemuxml2argv-clock-variable.args,
  qemuxml2argvdata/qemuxml2argv-clock-variable.xml,
  qemuxml2argvtest.c: Test case, except we can't actually enable
  it yet.

This introduces a third option for clock offset synchronization,
that allows an arbitrary / variable adjustment to be set. In
essence the XML contains the time delta in seconds, relative to
UTC.

  <clock offset='variable' adjustment='123465'/>

The difference from 'utc' mode, is that management apps should
track adjustments and preserve them at next reboot.

* docs/schemas/domain.rng: Schema for new clock mode
* src/conf/domain_conf.c, src/conf/domain_conf.h: Parse
  new clock time delta
* src/libvirt_private.syms, src/util/xml.c, src/util/xml.h: Add
  virXPathLongLong() method

The XML will soon be extended to allow more than just a simple
localtime/utc boolean flag. This change replaces the plain
'int localtime' with a separate struct to prepare for future
extension

* src/conf/domain_conf.c, src/conf/domain_conf.h: Add a new
  virDomainClockDef structure
* src/libvirt_private.syms: Export virDomainClockOffsetTypeToString
  and virDomainClockOffsetTypeFromString
* src/qemu/qemu_conf.c, src/vbox/vbox_tmpl.c, src/xen/xend_internal.c,
  src/xen/xm_internal.c: Updated to use new structure for localtime

* src/node_device/node_device_udev.c (udevEnumerateDevices): Remove
unnecessary call to udev_list_entry_get_name.

* src/qemu/qemu_conf.c (qemudNetworkIfaceConnect): Remove extraneous
virSaveLastError call, whose result was unused.

* src/qemu/qemu_monitor_text.c: qemuMonitorTextGetMigrationStatus: Check for
  failed strchr, to silence a coverity warning.

* src/conf/domain_conf.c: forgot to free the attribute value in
  virDomainNetDefParseXML()

* We are reverting this patch pending a discussion of the right way to implement.

While building under RHEL-5, I got a compile warning because
virDomainObjFormat was defined but not used.  That came about
because in RHEL-5 we build with "#define PROXY", and
virDomainObjFormat is only used with !PROXY.  Move the
define.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

* src/openvz/openvz_conf.c (openvzGetVEID): Always call fclose.
Diagnose parse failure also when vzlist output is empty.
If somehow we read a -1, diagnose that (albeit as a parse failure).

Kind of minor, but it annoys me that the default auth callback
doesn't put a space between the prompt and the input, like a typical
terminal, ssh, etc. This patch changes the current prompt:

Please enter your authentication name:myuser

to

Please enter your authentication name: myuser

While this could lead people in the wrong direction, people most commonly
hit this error when libvirtd isn't running, so let's mention a possible
fix.

In bug 567931 we found that virt-top would exit occasionally
when the terminal window was resized.  Tracking this down it
turned out that SIGWINCH was being delivered to the process at
exactly the point where the libvirt remote driver was calling
poll(2) waiting for a reply from libvirtd.

This caused the poll(2) call to be interrupted (returning errno
EINTR).  However handling EINTR the same way as EAGAIN was not
the solution to this problem since we found previously that this
would break Ctrl-C handling (commit 47fec8ea).

The correct solution is to mask out SIGWINCH for the duration
of the poll(2) system call.  The per-thread mask is changed and
restored immediately after the call.  Since we are using
pthread_sigmask, this should not affect other threads, and
since we restore the signal mask immediately afterwards it should
not affect the current thread visibly either.  Other possibly
problematic signals are SIGCHLD and SIGPIPE and these are
masked too.

Note use of ignore_value: It's not fatal if we cannot mask out
SIGWINCH, and in any case pthread_sigmask never fails on Linux
as long as you supply the correct arguments.

I tested this patch and it cures the original problem with
virt-top.

Create the filesystem on the partition used by the pool
* configure.ac: check for mkfs availability
* libvirt.spec.in: add extra require on util-linux for mkfs
* src/storage/storage_backend_fs.c: run mkfs with the expected
  fs type when creating a filesystem pool