cdrom device handling
by Olaf Hering
Is there a way for the tools to provide a configured cdrom as cdrom to
the temporary guest? Right now both disk and cdrom retrived from libvirt
will showup as disks in the temporary guest.
This happens for bus ide and scsi. It seems on my test system the guest
can not start from a scsi disk, but the scsi cdrom appears as scsi cdrom
in the guest. So I think its maybe just a matter of generating '<disk
type='file' device='cdrom'>' instead of '<disk type='file'
device='disk'>'?
I'm using this command, which works ok for me:
virt-rescue -v -c qemu+ssh:///system -d opensuse12 -r
Olaf
12 years, 1 month
[PATCH] launch: show hint to resolve authentication failure from libvirt
by Olaf Hering
Signed-off-by: Olaf Hering <olaf(a)aepfle.de>
---
Switching from attach-method "appliance" to "libvirt" has surprising
side effects, so show a hint how to resolve the "authentication failed"
error from libvirt.
Patch is not compile tested.
src/libvirtdomain.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/libvirtdomain.c b/src/libvirtdomain.c
index eecea26..110ee86 100644
--- a/src/libvirtdomain.c
+++ b/src/libvirtdomain.c
@@ -104,6 +104,8 @@ guestfs__add_domain (guestfs_h *g, const char *domain_name,
err = virGetLastError ();
error (g, _("could not connect to libvirt (code %d, domain %d): %s"),
err->code, err->domain, err->message);
+ if (err->code == VIR_ERR_AUTH_FAILED)
+ error (g, _("Possible fix: 'polkit-auth --user <username> --grant org.libvirt.unix.manage'"));
goto cleanup;
}
--
1.7.12.2
12 years, 1 month
v2v vmware converter
by Francesco Vollero
Hi Matt,
I was taking a look on v2v to implement vSphere and I have few questions:
1) the converter should be in: Sys::VirtConvert::Converter::VMWare ( or Vsphere) ?
2) What you think if instead to mess up with the xml converter we gonna use
a XSL file that take the OVF file and transform it in KVM like xml file ?
Cheers,
Francesco
12 years, 1 month
Fwd: hivex: patch for read support of "li"-records from "ri" intermediate
by Richard W.M. Jones
[The bug which this fixes is:
https://bugzilla.redhat.com/show_bug.cgi?id=717583 ]
----- Forwarded message from Peter Fokker <peter(a)berestijn.nl> -----
Date: Thu, 8 Mar 2012 11:37:06 +0100 (CET)
From: Peter Fokker <peter(a)berestijn.nl>
To: rjones(a)redhat.com
Cc: Peter Fokker <peter(a)berestijn.nl>
Subject: hivex: patch for read support of "li"-records from "ri"
intermediate
User-Agent: SquirrelMail/1.4.9a
Richard,
Thank you for creating the hivex-library. Studying your source code helped
me a great deal to better understand the internals of the Windows Registry.
However, while I was browsing a real-world SOFTWARE-hive (XP, SP3) I
could not browse to the '\Classes' key. Instead I got this (debug)-message:
get_children: returning ENOTSUP because ri-record offset does not
point to lf/lh (0x49020)
I tracked this issue down and I discovered that the intermediate
"ri"-record may not only contain offsets to "lf" and "lh" but to
"li"-records too.
Attached is a patch against hivex.c v1.3.3 that recognises
"li"-records referenced from "ri"-records. For me this fixed the issue
with browsing the '\Classes' key.
Note that I have not fixed the related problem of rewriting
"li"-records when inserting a new subkey or deleting an
existing one. This sure would cause problems when I were to
add/delete a subkey to/from '\Classes'.
I would very much appreciate it if would be so kind to take a look at
my patch, allthough I cannot blame you if you immediately dump this
unsollicited message+patch from some random stranger from The Netherlands.
Kind regards,
--Peter Fokker
--
Peter Fokker <peter(a)berestijn.nl>
Ingenieursbureau PSD +31 35 695 29 99 / +31 644 238 568
Stargardlaan 7 1404 BC Bussum, The Netherlands
----- End forwarded message -----
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
12 years, 1 month
NOTE: Relaunching handles (don't do it!)
by Richard W.M. Jones
It's possible through the API to do a sequence of calls like this:
g = guestfs_create ();
guestfs_add_drive (g, "foo");
guestfs_launch (g);
guestfs_shutdown (g);
guestfs_launch (g); # relaunch the handle
The question is, what should be the state of the handle at the second
launch? Would the verbose flag still be set if it had been set
earlier? (I think fairly obviously yes). Would drives added the
first time be automatically added the second time?
Since we added hotplugging the answer to the drives question has
changed[1]. Previously, any drives added before the first launch are
still there, and added implicitly before the second call to launch.
Now, the list of drives held in the handle is completely cleared
during shutdown, so in the code above, the second launch is called
with no drives added[2].
The reason this changed is that hotplugging makes it much more
difficult to track drives in the handle across multiple launches.
Should drives which were hot-added after launch be added before the
second launch? What about drives which have been removed from the
list (guestfs_remove_drive) -- should we remember those and magically
reinstate them?
I should note that neither behaviour was/is documented.
The best advice of all is: DO NOT CALL LAUNCH MORE THAN ONCE ON THE
SAME HANDLE! Handles are very cheap to create (guestfs_create is
basically a malloc). There is no reason not to close the handle after
shutdown and start fresh with a new one. ie. to write:
g = guestfs_create ();
guestfs_add_drive (g, "foo");
guestfs_launch (g);
guestfs_shutdown (g);
guestfs_close (g);
g = guestfs_create (); /* start with a fresh handle */
guestfs_add_drive (g, "foo");
guestfs_launch (g);
/* etc. */
Because of our commitment to ABI compatibility (where the behaviour is
documented), I'm not going to stop people from re-launching the
handle. But it's still best to avoid it.
Rich.
[1] https://github.com/libguestfs/libguestfs/commit/ed7fda161e1f3d0beb02a368f...
https://github.com/libguestfs/libguestfs/commit/33f49d85c2a82e66f33cedccb...
[2] This may or may not cause an error depending on the backend --
with the libvirt backend you're now allowed to launch a handle with no
drives.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
12 years, 1 month
[PATCH][RFC] launch: appliance is optional
by Olaf Hering
# virt-filesystems -v -d 6326ad4e-5805-2ab4-1338-d1dad8c76162 --all
libguestfs: libvirt version = 10002
libguestfs: [00000ms] connect to libvirt
libguestfs: [00001ms] get libvirt capabilities
libguestfs: [00234ms] build appliance
libguestfs: [00234ms] create libvirt XML
libguestfs: error: error constructing libvirt XML at "xmlTextWriterWriteAttribute (xo, BAD_CAST "file", BAD_CAST appliance)": No such file or directory
libguestfs: closing guestfs handle 0x656270 (state 0)
# ls -lh /usr/lib64/guestfs/*
-rw-r--r-- 1 root root 13M Oct 8 16:15 /usr/lib64/guestfs/initramfs.x86_64.img
-rw-r--r-- 1 root root 3.7M Oct 6 09:25 /usr/lib64/guestfs/vmlinuz.x86_64
Signed-off-by: Olaf Hering <olaf(a)aepfle.de>
---
perhaps the if (!appliance) check should be somewhere else?
src/launch-libvirt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c
index d678266..5914642 100644
--- a/src/launch-libvirt.c
+++ b/src/launch-libvirt.c
@@ -936,6 +936,10 @@ construct_libvirt_xml_appliance (guestfs_h *g, xmlTextWriterPtr xo,
char drive_name[64] = "sd";
char scsi_target[64];
+ /* appliance is optional */
+ if (appliance == NULL)
+ return 0;
+
guestfs___drive_name (drv_index, &drive_name[2]);
snprintf (scsi_target, sizeof scsi_target, "%zu", drv_index);
--
1.7.12.1
12 years, 1 month
Support for qemu snapshot=on drives in libvirt
by Richard W.M. Jones
I notice that the qemu driver doesn't support snapshot drives
(-drive file=foo,snapshot=on). This is important for libguestfs.
Currently libguestfs hacks this using <qemu:arg>. That works fine for
static disks in the libvirt XML, but lack of direct support in libvirt
is a blocker for adding hotplugging to libguestfs.
In qemu, the snapshot=on feature does several things:
(a) It creates a temporary qcow2 disk in $TMPDIR.
(b) It sets the backing file of the temporary disk to the real disk.
(c) When running, writes to the disk go to the temporary overlay, and
not to the real disk.
(d) I believe it also lets you commit changes from the temporary disk
to the backing file using a monitor command ("commit"? "save"?).
However we don't need or use this feature.
(e) When qemu exits, the temporary qcow2 disk is deleted.
So note that when you use snapshot=on there is an implicit dependency
on the $TMPDIR environment variable. I don't know of a way to create
the snapshot in another directory (at least, not using snapshot=on
.. possibly one can do it by creating an explicit overlay disk in
libvirt).
A simple implementation therefore would be to add a <snapshot/>
element to <disk>. It would just add snapshot=on and ignore concerns
about $TMPDIR.
Or reuse the <readonly/> flag? Note that these disks are writable.
A more complex implementation would create an explicit overlay disk in
libvirt and clean it up afterwards. This would let us control where
the temporary disk is created. XML might look like this:
<snapshot [tmp=...] />
I'm also concerned about the time is takes to run the external
'qemu-img create' command, which is non-trivial in some versions
of qemu. In libguestfs, every millisecond counts.
$ time qemu-img create -f qcow2 test.qcow2 10M
Formatting 'test.qcow2', fmt=qcow2 size=10485760 encryption=off cluster_size=65536
real 0m0.610s
user 0m0.022s
sys 0m0.009s
Or, can this be done using existing libvirt features?
Any thoughts on this before I implement something ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
12 years, 1 month
