hivexregedit doc - unix2dos command
by Skippy VonDrake
On the page: http://libguestfs.org/hivexregedit.1.html#encoding
Under "ENCODING" section is this command:
unix2dos linux.reg | iconv -f utf-8 -t utf-16le > win.reg
I couldn't get that to work without placing a redirection operator
('<') after "unix2dos".
Could this be due to my version of unix2dos? Or just a typo.
I'm a Linux n00b so my apologies for any "stupid" questions.
12 years, 1 month
Convert a locally stored copy of an esxi virtual machine to libvirt using virt-v2v?
by Curtis C.
Hi,
Is there a way to use a locally stored copy of an exsi created virtual
machine to convert to libvirt via virt-v2v? I don't want to have to
download the image from the esxi server each time I run virt-v2v as that
copy takes a long time. Perhaps I'm just missing the command line option.
What I would like to do is copy the image manually to the virt-v2v server
and work on it locally with virt-v2v, for example in situations where I
don't have access to the esxi host.
Thanks,
Curtis.
--
Twitter: @serverascode
Blog: serverascode.com
12 years, 1 month
Libguest Problem
by 王健
Hi Richard,
I am a user of LibguestFS.
I have a problem in using LibguestFS to get the OS type of the virtual machine with Xenserver virtual environment.
But when I use the command in Linux likes the figure1. I know that this disk file could add in libguestfish.
My code is in the figure2. I can't get the OS info from GuestFs.
Could you give me some suggests?
James
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------
12 years, 1 month
[PATCH] sysprep: remove crash data generated by kexec-tools
by Wanlong Gao
Remove the kdump generated kernel crash data.
Signed-off-by: Wanlong Gao <gaowanlong(a)cn.fujitsu.com>
---
sysprep/Makefile.am | 1 +
sysprep/sysprep_operation_crash_data.ml | 47 +++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)
create mode 100644 sysprep/sysprep_operation_crash_data.ml
diff --git a/sysprep/Makefile.am b/sysprep/Makefile.am
index a747929..fafb929 100644
--- a/sysprep/Makefile.am
+++ b/sysprep/Makefile.am
@@ -43,6 +43,7 @@ operations = \
bash_history \
blkid_tab \
ca_certificates \
+ crash_data \
cron_spool \
dhcp_client_state \
dhcp_server_state \
diff --git a/sysprep/sysprep_operation_crash_data.ml b/sysprep/sysprep_operation_crash_data.ml
new file mode 100644
index 0000000..2150e52
--- /dev/null
+++ b/sysprep/sysprep_operation_crash_data.ml
@@ -0,0 +1,47 @@
+(* virt-sysprep
+ * Copyright (C) 2012 Fujitsu Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *)
+
+open Sysprep_operation
+open Sysprep_gettext.Gettext
+
+module G = Guestfs
+
+let crash_data_perform g root =
+ let typ = g#inspect_get_type root in
+ if typ <> "windows" then (
+ let paths = g#glob_expand "/var/crash/*" in
+ Array.iter (
+ fun path -> g#rm_rf path;
+ ) paths;
+ []
+ )
+ else []
+
+let crash_data_op = {
+ name = "crash-data";
+ enabled_by_default = true;
+ heading = s_"Remove the crash data generated by kexec-tools";
+ pod_description = Some (s_"\
+Remove the automatically generated kdump kernel crash data in
+C</var/crash/>.");
+ extra_args = [];
+ perform_on_filesystems = Some crash_data_perform;
+ perform_on_devices = None;
+}
+
+let () = register_operation crash_data_op
--
1.8.0
12 years, 1 month
Re: [Libguestfs] Cannot import converted vm to ovirt with virt-p2v
by Matthew Booth
On 20/11/12 13:36, Matthew Booth wrote:
> On 20/11/12 11:42, Tim Scharner - 123domain.eu - Die Domainmanager wrote:
>> Hello!
>>
>> I convirted a physical machine with virt-p2v successfully. But now I
>> have problems with the import to oVirt.
>> Event log says: "Failed to import Vm convirttest to data-cluster-1"
>>
>> Also in the engine.log I got the following error:
>> http://pastebin.com/yWgB8NTL
>>
>> I already tried to generate a new UUID for the image of the harddrive,
>> but that has no effect.
>>
>> Any help is much appreciated!
>
> Looks like you virt-v2v and ovirt are disagreeing on the OVF. Can you
> open a BZ and attach:
>
> * the complete, generated OVF file
> * the version of virt-v2v you are using
> * the version of ovirt/RHEV you are using
>
> Can you let me know the BZ number when you're done?
I forgot to mention: also the contents of the above pastebin. Please
don't just post the pastebin link, because there's a good chance it will
expire before the BZ does!
Thanks,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
12 years, 1 month
Cannot import converted vm to ovirt with virt-p2v
by Tim Scharner - 123domain.eu - Die Domainmanager
Hello!
I convirted a physical machine with virt-p2v successfully. But now I
have problems with the import to oVirt.
Event log says: "Failed to import Vm convirttest to data-cluster-1"
Also in the engine.log I got the following error:
http://pastebin.com/yWgB8NTL
I already tried to generate a new UUID for the image of the harddrive,
but that has no effect.
Any help is much appreciated!
Best regards,
Tim
12 years, 1 month
[PATCH] daemon: wipefs: Use --force option if available.
by Richard W.M. Jones
From: "Richard W.M. Jones" <rjones(a)redhat.com>
See https://bugzilla.redhat.com/show_bug.cgi?id=872831
and https://bugzilla.redhat.com/show_bug.cgi?id=865961
---
daemon/zero.c | 42 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/daemon/zero.c b/daemon/zero.c
index 1a66881..4997583 100644
--- a/daemon/zero.c
+++ b/daemon/zero.c
@@ -82,14 +82,52 @@ optgroup_wipefs_available (void)
return prog_exists (str_wipefs);
}
+/* See RHBZ#872831 */
+static int
+wipefs_has_force_option (void)
+{
+ static int flag = -1;
+ int r;
+ char *out, *err;
+
+ if (flag == -1) {
+ r = command (&out, &err, "wipefs", "--help", NULL);
+ if (r == -1) {
+ reply_with_error ("%s", err);
+ free (out);
+ free (err);
+ return -1;
+ }
+ free (err);
+ flag = strstr (out, "--force") != NULL;
+ free (out);
+ }
+
+ return flag;
+}
+
int
do_wipefs (const char *device)
{
+ int force;
int r;
char *err = NULL;
+ const size_t MAX_ARGS = 16;
+ const char *argv[MAX_ARGS];
+ size_t i = 0;
+
+ force = wipefs_has_force_option ();
+ if (force == -1)
+ return -1;
+
+ ADD_ARG (argv, i, str_wipefs);
+ ADD_ARG (argv, i, "-a");
+ if (force)
+ ADD_ARG (argv, i, "--force");
+ ADD_ARG (argv, i, device);
+ ADD_ARG (argv, i, NULL);
- const char *wipefs[] = {str_wipefs, "-a", device, NULL};
- r = commandv (NULL, &err, wipefs);
+ r = commandv (NULL, &err, argv);
if (r == -1) {
reply_with_error ("%s", err);
free (err);
--
1.7.11.4
12 years, 1 month
Notes on compiling libguestfs 1.19.59 on Debian 7 (Wheezy) beta
by Richard W.M. Jones
In no particular order. Some of these need further investigation.
----------------------------------------------------------------------
I had to patch libguestfs not to use febootstrap-supermin-helper
--copy-kernel option. See attachment #1. This could be avoided by
providing a newer febootstrap in Wheezy.
I had to patch libguestfs to make it not use the (not working)
virtio-scsi in old kvm. See attachment #2.
mdadm is missing as a dependency from the Debian package.
test_mke2fs_0 fails: this seems to be a bug in libguestfs block
device renaming code:
libguestfs: trace: mke2fs "/dev/sda2" "blocksize:4096" "journaldevice:/dev/sda1" "fstype:ext2"
libguestfs: send_to_daemon: 276 bytes: 00 00 01 10 | 20 00 f5 f5 | 00 00 00 04 | 00 00 01 70 | 00 00 00 00 | ...
guestfsd: main_loop: proc 368 (mke2fs) took 4.52 seconds
guestfsd: main_loop: new request, len 0x110
/dev/sda2: No such file or directory
mke2fs -b 4096 -J device=/dev/sda1 -t ext2 /dev/vda2
mke2fs 1.42.5 (29-Jul-2012)
test_tune2fs* fail because the output (username) expected by the
test script is different from what the test expects. This is not
important and this test should just be skipped.
For some reason, the behaviour of vfat with the utf8 option is
different from the same driver in the Fedora kernel. The Debian
kernel prints this warning:
[ 65.576097] FAT-fs (vda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
and indeed the resulting filesystem is case sensitive, which is
definitely not expected or correct for vfat. It's probably some
kernel config option.
The udev rule (appliance/99-guestfs-serial.rules) either isn't being
installed or doesn't work for some reason. I didn't look into it, but
this breaks /dev/disk/guestfs/<label> disk names (see 7786d56db8c2241).
tests/regressions/rhbz690819.sh fails, because either the kernel or
qemu doesn't support the IDE interface. This will break virt-v2v.
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
One possible plan for remote support
by Richard W.M. Jones
John,
It's probably worth setting out from what the problem is / what we are
trying to solve here.
At the moment if you run a command like:
virt-inspector -d Guest
then libguestfs asks libvirt [-d option] for the XML corresponding to
the libvirt guest called 'Guest'. This will contain disk sections
like this:
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source dev='/dev/vg_data/guest'/>
<target dev='vda' bus='virtio'/>
</disk>
libguestfs then directly opens the local disk [/dev/vg_data/guest in
the example above] and analyzes it.
libvirt can also run remotely, eg:
virsh -c qemu://remote/system list --all
If you ran a command like:
virt-inpector -c qemu://remote/system -d Guest
then libguestfs connects to libvirtd on the remote server gets the
XML, parses out the disks, tries to open them, and usually that's
going to fail: files and devices can't be opened by name remotely.
Well, unless you've got cluster LVM, but we'll assume that you don't.
The idea of remote support is to make this work as seemlessly as
possible. Now [since libguestfs 1.19.xx] that we have a libvirt
backend to libguestfs [src/launch-libvirt.c], it could be made to
work.
What we do is we start the libguestfs appliance remotely. Obviously
since it is now running remotely, it has access to the guest's disks
directly.
Now we have two problems:
(a) How do we start the libguestfs appliance remotely?
(b) How do we redirect the library <-> appliance serial connection
back to the library (which is running on a different machine)?
Ideally this would be forwarded over the libvirt connection.
[http://libguestfs.org/guestfs.3.html#architecture]
Both require some development work in libvirt & libguestfs.
The background to problem (a) is that currently we run a helper
program to create the appliance. This runs locally [src/appliance.c].
It needs to be changed to run remotely (to be more precise: the
existing local code needs to be left in place, since it is very robust
and required for the non-libvirt case, but we need additional code so
it can be done remotely). libvirt already has a mechanism which can
be used to run a process on the remote server which is responsible for
creating the kernel/initrd, however it has some limitations and it
currently only works for Xen:
http://libvirt.org/formatdomain.html#elementsOSBootloader
Problem (b) is really a shortcoming of libvirt. If you define a
virtio-serial socket in libvirt
[http://libvirt.org/formatdomain.html#elementCharChannel] then it's a
bit stupid that these only work locally. It should be possible (Dan
assures me "easy") to make these be forwarded over the libvirt secure
connection.
Then there's fixing up the libguestfs side of things so this all works
in the remote case, ie. so that the correct XML is generated for (a),
and that we are able to use the remoted serial socket created in (b).
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
using fuse with libguestfs
by Skippy VonDrake
Upon seeing RWM Jones article "Using mount-local API from C" I became
curious because I thought there WAS a way to combine aspects of FUSE
with the tools provided by libguestfs. So if I wanted to create my own
filesystem using callbacks placed in the 'fuse_operations' struct
(parameter to 'fuse_main()'), I could do so using guestfs.
But after reading the article and looking at the 'guestmount' api it
appears that fuse support is limited.
Only the '-o' FUSE options can be passed and "only some of them are a
good idea".
So how would one use guestfs with a filesystem "made" with Fuse?
For example - using Jones module
'https://github.com/libguestfs/libguestfs/blob/master/examples/mount_local.c'
could I combine it with the Fuse defined filesystem detailed in the
BBFS tutorial (http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/)?
Or would that be a futile effort?
12 years, 1 month
