| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Not that I'm paranoid about qemu breaking snapshots of anything like
that ...
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This API returns the guest's favicon if found, else an icon
representing the guest operating system. Currently supported by this
patch: Fedora, RHEL and derivatives, Debian (but not Ubuntu),
Windows XP, Windows 7.
This also updates virt-inspector to include an <icon> element
containing the icon in base64 encoding.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous guestfs___download_to_tmp function did not handle
multiboot correctly. In particular it used the same cache name
for downloaded files from different roots, which could have caused
things like applications in each root to be confused.
This changes the function so that the cache filename is prefixed
with the root / fs number, eg. $tmpdir/0-Name instead of $tmpdir/Name.
This change also requires the function to return the new name, so
all places in the code which called this function had to be
updated.
This updates and fixes commit 3c1f762abed92f7a358f3bc93e3396d0606b18ad.
|
| |
|
|
| |
The updated patch makes 'options' into an optional parameter.
|
| | |
|
| | |
|
| |
|
|
|
| |
Make this error more informative, since it is a common error when the
appliance fails to start up.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Because of the previous change to size_t, when pos == 0 the loop would
wrap around and cause a segmentation fault.
This fixes a regression introduced by
commit 10167cea98f93a74abe63f0a54d3a662997e7489.
|
| |
|
|
|
|
| |
This makes a backwards-compatible change to the add-domain API. If
the optional allowuuid flag is true then UUIDs can be used instead of
names in the domain name parameter.
|
| |
|
|
|
|
|
|
|
|
|
| |
Install an error handler on the libvirt error connection so that
errors are not printed on stderr (instead they go up through the usual
libguestfs error mechanism).
Unfortunately this doesn't suppress initial connection error messages
to stderr. I cannot see how to do this without affecting the global
libvirt error handler, which is not acceptable for a library to be
doing.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Only the "first half" (ie. the call) is traced, because by the time
the function returns the handle has gone and there's no way to
generate events.
You should see:
libguestfs: trace: close
|
| | |
|
| |
|
|
| |
This is just code motion.
|
| | |
|
| | |
|
| |
|
|
|
| |
The virt-v2v transfer ISO had a /windows directory. The core
inspection code thought this was a Windows root filesystem.
|
| |
|
|
|
| |
virt-inspector would exit silently if list-applications failed along
this error path.
|
| |
|
|
| |
Previously we returned "rhel" for these, which was not accurate.
|
| |
|
|
|
|
|
|
|
|
| |
This commit downloads the Packages RPM database allowing us to find
other details about installed RPM packages (via
inspect-list-applications). This adds version and release. Epoch
cannot yet be found.
This commit also updates the Fedora example image so that it contains
a dummy RPM Packages database with some data.
|
| |
|
|
|
|
|
|
|
|
|
| |
There are two changes here:
(1) The code for listing RPM applications ran db_dump and parsed the
output. We abstract out that parsing code into a separate reusable
module (src/dbdump.c).
(2) The old db_dump parsing code used db_dump -p (printable) format.
Instead use db_dump -k (hex) format so we can read binary fields.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The src/inspect.c file had grown rather large -- 3,500 lines. Split
it across several files according to function.
This is just moving code.
After the split the files are more evenly divided:
536 src/inspect_apps.c
766 src/inspect.c
537 src/inspect_fs.c
404 src/inspect_fs_cd.c
785 src/inspect_fs_unix.c
535 src/inspect_fs_windows.c
3563 total
|
| |
|
|
| |
This is just moving code around.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During inspection we download various files such as the Windows
'software' and 'system' registries. Previously these were downloaded
as temporary files and discarded immediately after use. This meant
that the 'software' registry was being downloaded twice by
virt-inspector (it's required once for basic OS inspection, and a
second time to list Windows applications).
This commit changes this so that these files are cached in g->tmpdir,
and thus the second time we just reuse the file we've already
downloaded.
Callers shouldn't be relying on inspect-list-applications to reread
the actual registry from the VM (unless you close and reopen the
handle). It says in the documentation that the results of inspection
may be cached in the handle.
|
| |
|
|
|
|
|
|
| |
In preparation for caching inspection information in the temporary
directory (g->tmpdir), allow the temporary directory to contain
arbitrary files, and remove all of them when the handle is closed.
This just generalizes the previous method of cleaning up the tmpdir.
|
| |
|
|
| |
* src/events.c: Include <string.h>, for use of strlen.
|
| |
|
|
| |
We can now get drive letter mappings through the inspection API.
|
| |
|
|
| |
Found using valgrind.
|
| |
|
|
|
| |
rpcgen generates source which can't be safely compiled with strict-aliasing
enabled.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This returns the drive mappings from the Windows Registry.
virt-inspector displays the drive mappings, giving output
similar to this:
<drive_mappings>
<drive_mapping name="C">/dev/sda2</drive_mapping>
<drive_mapping name="E">/dev/sdb1</drive_mapping>
</drive_mappings>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This returns the actual registry key corresponding to
CurrentControlSet (eg. it might be "ControlSet001").
Previously the inspection code was hard-coding ControlSet001. Now we
use the correct control set, and also make it available to callers
through the API.
This commit also updates the virt-dhcp-address example so it uses this
new API.
virt-inspector displays the current control set when available.
|
| |
|
|
|
|
| |
A more accurate description of what this function does.
This is just code motion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new form of progress event, where we don't know how
much of the operation has taken place, but we nevertheless want to
send back some indication of activity. Some progress bar indicators
directly support this, eg. GtkProgressBar where it is known as "pulse
mode".
A pulse mode progress message is a special backwards-compatible form
of the ordinary progress message. No change is required in callers,
unless they want to add support for pulse mode.
The daemon sends:
- zero or more progress messages with position = 0, total = 1
- a single final progress message with position = total = 1
Note that the final progress message may not be sent if the call fails
and returns an error. This is consistent with the behaviour of
ordinary progress messages.
The daemon allows two types of implementation. Either you can just
call notify_progress (0, 1); ...; notify_progress (1, 1) as usual.
Or you can call the functions pulse_mode_start, pulse_mode_end and/or
pulse_mode_cancel (see documentation in daemon/daemon.h). For this
second form of call, the guarantee is very weak: it *just* says the
daemon is still capable of doing something, and it doesn't imply that
if there is a subprocess that it is doing anything. However this does
make it very easy to add pulse mode progress messages to all sorts of
existing calls that depend on long-running external commands.
To do: add a third variant that monitors a subprocess and only sends
back progress messages if it's doing something, where "doing
something" might indicate it's using CPU time or it's printing output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit generates approximate progress messages during the
guestfs_launch call. Currently this code generates:
0 / 12: launch clock starts
3 / 12: appliance created
6 / 12: detected that guest kernel started
9 / 12: detected that /init script is running
12 / 12: launch completed successfully
(Note this is not an ABI and may be changed or removed in a future
version).
Progress messages are only generated at all if 5 seconds have elapsed
since the launch, and they are only generated for the ordinary
appliance (not if using attach-method to attach to an existing virtio
serial port).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As explained in the comment:
/* QEMU's console emulates a 16550A serial port. The real 16550A
* device has a small FIFO buffer (16 bytes) which means here we see
* lots of small reads of 1-16 bytes in length, usually single
* bytes. Sleeping here for a very brief period groups reads
* together (so we usually get a few lines of output at once) and
* improves overall throughput, as well as making the event
* interface a bit more sane for callers. With a virtio-serial
* based console (not yet implemented) we may be able to remove
* this. XXX
*/
|
| |
|
|
| |
This is just code motion.
|
| |
|
|
| |
This is just code motion.
|
| |
|
|
|
| |
This should be obvious, and now it is documented to avoid any
confusion.
|
| | |
|
