8:27 a.m.
Dear libguestfs developers,
We are developing the protected enterprise system based on several Red Hat technologies
(Red Hat Enterprise Virtualisation, the IdM server and so on). Our current goal is to
prevent the booting of the virtual machine in case of integrity loss. So what we are
trying to do Is to intercept the event of the VM's start (using the RHEV Manager hook
scripts), mount the starting VM's disk image with libguestfs and check the hash sums
of the system files.
When we have a local storage of disk images (manager, hypervisor and storage - all in one
host), this approach works just perfect.
But even a little bit complex network (with at least one manager, one hypervisor and one
iSCSI/FC storage - three standalone physical hosts) blows our minds. RHEV Manager API
provides the list of disk images which are (in this configurations) are logical volumes on
the hypervisor and appear in hypervisor's /dev/mapper directory. But libguestfs from
RHEV manager cannot access them. Examples from libguestfs and guestfish guide (for
instance, over ssh) do not work. And even more, which host should we access - a hypervisor
(with a different logical volumes) or a storage (with a monolith volume group)?
Software version: RHEV 3.1, libguestfs 1.16.34, guest OS - RHEL 6.4, arch: x86_64.
P.S. May be I had to post this message directly to the support, but I'd suggest that
this topic would be useful for community.
Thank you,
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО <Финтех>
9:56 a.m.
[Adding Itamar: Any suggestions on where Vitaly could get help on this
RHEV-M API problem?]
On Thu, Nov 21, 2013 at 02:27:08PM +0000, Исаев Виталий Анатольевич wrote:
Dear libguestfs developers,
We are developing the protected enterprise system based on several
Red Hat technologies (Red Hat Enterprise Virtualisation, the IdM
server and so on). Our current goal is to prevent the booting of the
virtual machine in case of integrity loss. So what we are trying to
do Is to intercept the event of the VM's start (using the RHEV
Manager hook scripts), mount the starting VM's disk image with
libguestfs and check the hash sums of the system files.
When we have a local storage of disk images (manager, hypervisor and
storage - all in one host), this approach works just perfect.
But even a little bit complex network (with at least one manager,
one hypervisor and one iSCSI/FC storage - three standalone physical
hosts) blows our minds. RHEV Manager API provides the list of disk
images which are (in this configurations) are logical volumes on the
hypervisor and appear in hypervisor's /dev/mapper directory. But
libguestfs from RHEV manager cannot access them.
When you say "cannot access them" do you get an error message? Could
it be an SELinux denial?
I can tell you that libguestfs *should* be able to open any disk image
or block device. But libguestfs doesn't have a magic way to bypass
permissions: if the block device needs (for example) root permissions
or SELinux is stopping things, libguestfs won't be able to open the
file, in the same way that /bin/cat or vi couldn't open it.
Examples from libguestfs and guestfish guide (for instance, over
ssh)
Remote access over ssh isn't enabled in RHEL 6 (nor in RHEL 7, sadly).
Is this a remote disk? RHEL 7.0 will support NBD remote access only,
which probably doesn't help you.
Fedora of course enables every possible remote access method, but you
get to keep the pieces if it breaks.
do not work. And even more, which host should we access - a
hypervisor (with a different logical volumes) or a storage (with a
monolith volume group)?
Itamar can probably help better than me here.
Software version: RHEV 3.1, libguestfs 1.16.34, guest OS - RHEL 6.4,
arch: x86_64.
P.S. May be I had to post this message directly to the support, but I'd suggest that
this topic would be useful for community.
Thank you,
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО <Финтех>
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
10:09 a.m.
On 11/21/2013 05:56 PM, Richard W.M. Jones wrote:
[Adding Itamar: Any suggestions on where Vitaly could get help on
this
RHEV-M API problem?]
On Thu, Nov 21, 2013 at 02:27:08PM +0000, Исаев Виталий Анатольевич wrote:
> Dear libguestfs developers,
>
> We are developing the protected enterprise system based on several
> Red Hat technologies (Red Hat Enterprise Virtualisation, the IdM
> server and so on). Our current goal is to prevent the booting of the
> virtual machine in case of integrity loss. So what we are trying to
> do Is to intercept the event of the VM's start (using the RHEV
> Manager hook scripts), mount the starting VM's disk image with
> libguestfs and check the hash sums of the system files.
>
> When we have a local storage of disk images (manager, hypervisor and
> storage - all in one host), this approach works just perfect.
>
> But even a little bit complex network (with at least one manager,
> one hypervisor and one iSCSI/FC storage - three standalone physical
> hosts) blows our minds. RHEV Manager API provides the list of disk
> images which are (in this configurations) are logical volumes on the
> hypervisor and appear in hypervisor's /dev/mapper directory. But
> libguestfs from RHEV manager cannot access them.
When you say "cannot access them" do you get an error message? Could
it be an SELinux denial?
I can tell you that libguestfs *should* be able to open any disk image
or block device. But libguestfs doesn't have a magic way to bypass
permissions: if the block device needs (for example) root permissions
or SELinux is stopping things, libguestfs won't be able to open the
file, in the same way that /bin/cat or vi couldn't open it.
> Examples from libguestfs and guestfish guide (for instance, over
> ssh)
Remote access over ssh isn't enabled in RHEL 6 (nor in RHEL 7, sadly).
Is this a remote disk? RHEL 7.0 will support NBD remote access only,
which probably doesn't help you.
Fedora of course enables every possible remote access method, but you
get to keep the pieces if it breaks.
> do not work. And even more, which host should we access - a
> hypervisor (with a different logical volumes) or a storage (with a
> monolith volume group)?
Itamar can probably help better than me here.
> Software version: RHEV 3.1, libguestfs 1.16.34, guest OS - RHEL 6.4, arch: x86_64.
>
> P.S. May be I had to post this message directly to the support, but I'd suggest
that this topic would be useful for community.
>
> Thank you,
> Виталий Исаев
> Инженер-программист
> Группа разработки и внедрения ПСЗИ
> Департамент информационной безопасности
> ОАО <Финтех>
Rich.
i may be missing something, but wouldn't vdsm hooks be a better fit:
http://www.ovirt.org/VDSM-Hooks
for example, I think the "checkimages" one would cover what you are
trying to do already?
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;
you can also ask such questions on users(a)ovirt.org.
4:02 p.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
________________________________________
От: Itamar Heim [iheim(a)redhat.com]
Отправлено: 21 ноября 2013 г. 20:10
Кому: Richard W.M. Jones; Исаев Виталий Анатольевич
Копия: libguestfs(a)redhat.com
Тема: Re: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using libguestfs
On 11/21/2013 05:56 PM, Richard W.M. Jones wrote:
[Adding Itamar: Any suggestions on where Vitaly could get help on
this
RHEV-M API problem?]
On Thu, Nov 21, 2013 at 02:27:08PM +0000, Исаев Виталий Анатольевич wrote:
> Dear libguestfs developers,
>
> We are developing the protected enterprise system based on several
> Red Hat technologies (Red Hat Enterprise Virtualisation, the IdM
> server and so on). Our current goal is to prevent the booting of the
> virtual machine in case of integrity loss. So what we are trying to
> do Is to intercept the event of the VM's start (using the RHEV
> Manager hook scripts), mount the starting VM's disk image with
> libguestfs and check the hash sums of the system files.
>
> When we have a local storage of disk images (manager, hypervisor and
> storage - all in one host), this approach works just perfect.
>
> But even a little bit complex network (with at least one manager,
> one hypervisor and one iSCSI/FC storage - three standalone physical
> hosts) blows our minds. RHEV Manager API provides the list of disk
> images which are (in this configurations) are logical volumes on the
> hypervisor and appear in hypervisor's /dev/mapper directory. But
> libguestfs from RHEV manager cannot access them.
When you say "cannot access them" do you get an error message? Could
it be an SELinux denial?
Yes, when I am trying to open some logical volume on the hypervisor side, for instance:
$ guestfish -a /dev/mapper/dm-xx
libguestfs fails with an error message kind of that:
$ libguestfs-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
libguestfs use, you shouldn't boot the Xen guest with it).
So this is correct because hypervisor's file system is minimalist and therefore
contains
kernel files neither in /boot nor in /lib/modules.
And it is still not clear for me, how should I implement interaction between the RHEV-M
API,
which tells me what logical volume (disk image) belongs to the every VM, and the
hypervisor's, to which
all the logical volume (disk images) are mapped.
So can I access the VM's disk images directly from the RHEV Manager in case
if manager, hypervisor and storage are different hosts?
I can tell you that libguestfs *should* be able to open any disk image
or block device. But libguestfs doesn't have a magic way to bypass
permissions: if the block device needs (for example) root permissions
or SELinux is stopping things, libguestfs won't be able to open the
file, in the same way that /bin/cat or vi couldn't open it.
Oh, that's nice idea. I'll try to turn SELinux off.
> Examples from libguestfs and guestfish guide (for instance, over
> ssh)
Remote access over ssh isn't enabled in RHEL 6 (nor in RHEL 7, sadly).
Is this a remote disk? RHEL 7.0 will support NBD remote access only,
which probably doesn't help you.
Unfortunately, we cannot upgrade from 6.4 due to conditions beyond our control...
Fedora of course enables every possible remote access method, but
you
get to keep the pieces if it breaks.
> do not work. And even more, which host should we access - a
> hypervisor (with a different logical volumes) or a storage (with a
> monolith volume group)?
Itamar can probably help better than me here.
> Software version: RHEV 3.1, libguestfs 1.16.34, guest OS - RHEL 6.4, arch: x86_64.
>
> P.S. May be I had to post this message directly to the support, but I'd suggest
that this topic would be useful for community.
>
> Thank you,
> Виталий Исаев
> Инженер-программист
> Группа разработки и внедрения ПСЗИ
> Департамент информационной безопасности
> ОАО <Финтех>
Rich.
i may be missing something, but wouldn't vdsm hooks be a better
fit:
http://www.ovirt.org/VDSM-Hooks
for example, I think the "checkimages" one would cover what you are
trying to do already?
Thank you, this hook was useful, but "gemu-img check" command is slightly
different from our purposes,
because we are trying to prevent the booting from disk image with changed system binaries.
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;
you can also ask such questions on users(a)ovirt.org.
Thank you for your attention and advises.
Vitaly
4:08 p.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On 11/22/2013 12:02 AM, Исаев Виталий Анатольевич wrote:
...
> i may be missing something, but wouldn't vdsm hooks be a
better fit:
> http://www.ovirt.org/VDSM-Hooks
>
> for example, I think the "checkimages" one would cover what you are
> trying to do already?
Thank you, this hook was useful, but "gemu-img check" command is slightly
different from our purposes,
because we are trying to prevent the booting from disk image with changed system
binaries.
I'll leave the rest to rich, but on this last one:
you can implement any logic you want in a hook, including the libguestfs
one. it just removes the need to listen on rhev-m events iiuc.
> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;
>
> you can also ask such questions on users(a)ovirt.org.
Thank you for your attention and advises.
Vitaly
2:26 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Thanks, Itamar. Hooks are really great tool.
No doubt we will use them.
But I still need some clarification about interaction between hooks (on the manager's
side) and libguestfs (on the side of hypervisor/storage).
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО <Финтех>
-----Original Message-----
From: Itamar Heim [mailto:iheim@redhat.com]
Sent: Friday, November 22, 2013 2:09 AM
To: Исаев Виталий Анатольевич; Richard W.M. Jones
Cc: libguestfs(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
On 11/22/2013 12:02 AM, Исаев Виталий Анатольевич wrote:
...
> i may be missing something, but wouldn't vdsm hooks be a
better fit:
> http://www.ovirt.org/VDSM-Hooks
>
> for example, I think the "checkimages" one would cover what you are
> trying to do already?
Thank you, this hook was useful, but "gemu-img check" command is
slightly different from our purposes, because we are trying to prevent the booting from
disk image with changed system binaries.
I'll leave the rest to rich, but on this last one:
you can implement any logic you want in a hook, including the libguestfs one. it just
removes the need to listen on rhev-m events iiuc.
> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;
>
> you can also ask such questions on users(a)ovirt.org.
Thank you for your attention and advises.
Vitaly
3:11 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On 11/22/2013 10:26 AM, Исаев Виталий Анатольевич wrote:
Thanks, Itamar. Hooks are really great tool.
No doubt we will use them.
But I still need some clarification about interaction between hooks (on the manager's
side) and libguestfs (on the side of hypervisor/storage).
these are vdsm-hooks, they run on the host, not on the engine (manager).
the engine does allow you, if you want, to configure which custom
properties can be defined at the VM level for example.
then you could make this check optional, or allow to override it.
say your default is to perform the check.
you can add a UserDefinedCustomProperty of "ByPassImageCheck" that can
accept value of 'true'.
then if you want to bypass this check for a sepcific VM, you will set
this custom property for that VM (your hook should have an "if
!ByPassImageCheck" logic in it of course.
(we have other types of hooks for engine side, and uiplugins to embed
things in the gui).
My I ask for the bigger picture of what you are trying to do?
thanks,
Itamar
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО <Финтех>
-----Original Message-----
From: Itamar Heim [mailto:iheim@redhat.com]
Sent: Friday, November 22, 2013 2:09 AM
To: Исаев Виталий Анатольевич; Richard W.M. Jones
Cc: libguestfs(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
On 11/22/2013 12:02 AM, Исаев Виталий Анатольевич wrote:
...
>> i may be missing something, but wouldn't vdsm hooks be a better fit:
>> http://www.ovirt.org/VDSM-Hooks
>>
>> for example, I think the "checkimages" one would cover what you are
>> trying to do already?
>
> Thank you, this hook was useful, but "gemu-img check" command is
> slightly different from our purposes, because we are trying to prevent the booting
from disk image with changed system binaries.
I'll leave the rest to rich, but on this last one:
you can implement any logic you want in a hook, including the libguestfs one. it just
removes the need to listen on rhev-m events iiuc.
>
>> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;
>>
>> you can also ask such questions on users(a)ovirt.org.
>
> Thank you for your attention and advises.
> Vitaly
>
3:50 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 11:11:32AM +0200, Itamar Heim wrote:
My I ask for the bigger picture of what you are trying to do?
See:
https://www.redhat.com/archives/libguestfs/2013-November/msg00059.html
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5:15 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On 11/22/2013 11:50 AM, Richard W.M. Jones wrote:
On Fri, Nov 22, 2013 at 11:11:32AM +0200, Itamar Heim wrote:
> My I ask for the bigger picture of what you are trying to do?
See:
https://www.redhat.com/archives/libguestfs/2013-November/msg00059.html
Rich.
please note for ovirt-node/rhev-, custom hooks would also need
persisting (I don't recall if they are formally supported actually).
once you write the code as a custom hook for a RHEL node, you could
discuss merging it as a full blown feature at arch(a)ovirt.org, then it
won't be an issue and you won't need custom hooks, etc.
3:11 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
[CC to Fabian - can you comment on the ovirt-node problem below]
On Thu, Nov 21, 2013 at 10:02:46PM +0000, Исаев Виталий Анатольевич wrote:
On 11/21/2013 05:56 PM, Richard W.M. Jones wrote:
> When you say "cannot access them" do you get an error message? Could
> it be an SELinux denial?
Yes, when I am trying to open some logical volume on the hypervisor side, for instance:
$ guestfish -a /dev/mapper/dm-xx
libguestfs fails with an error message kind of that:
$ libguestfs-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
libguestfs use, you shouldn't boot the Xen guest with it).
So this is correct because hypervisor's file system is minimalist and therefore
contains
kernel files neither in /boot nor in /lib/modules.
Ah I see, this is a slightly different problem. If this is RHEV-H /
ovirt-node then that's a bug in ovirt-node since it is supposed to
have a working libguestfs.
Can you paste the full, unedited output of:
libguestfs-test-tool
on the hypervisor.
And it is still not clear for me, how should I implement interaction
between the RHEV-M API,
which tells me what logical volume (disk image) belongs to the every VM, and the
hypervisor's, to which
all the logical volume (disk images) are mapped.
So can I access the VM's disk images directly from the RHEV Manager in case
if manager, hypervisor and storage are different hosts?
I'm not sure about this, but I guess the hooks that Itamar pointed to
before should work.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
3:42 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Rich, you are right; the hypervisor is RHEV-H. As Itamar has just explained me, hooks are
executed on the hypervisor’s side (not on the RHEV-M, as I used to think), so properly
working libguestfs on the RHEV-H will resolve my issue.
Here is the output of the test tool:
************************************************************
* IMPORTANT NOTICE
*
* When reporting bugs, include the COMPLETE, UNEDITED
* output below in your bug report.
*
************************************************************
===== Test starts here =====
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
library version: 1.16.34rhel=6,release=2.el6
guestfs_get_append: (null)
guestfs_get_attach_method: appliance
guestfs_get_autosync: 1
guestfs_get_direct: 0
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib64/guestfs
guestfs_get_pgroup: 0
guestfs_get_qemu: /usr/libexec/qemu-kvm
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum
'/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null),
initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
febootstrap-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
febootstrap use, you shouldn't boot the Xen guest with it).
libguestfs: error: cannot find any suitable libguestfs supermin, fixed or old-style
appliance on LIBGUESTFS_PATH (search path: /usr/lib64/guestfs)
libguestfs-test-tool: failed to launch appliance
libguestfs: closing guestfs handle 0x231d260 (state 0)
Thank you,
Vitaly Isaev
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 1:12 PM
To: Исаев Виталий Анатольевич
Cc: Itamar Heim; libguestfs(a)redhat.com; fdeutsch(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
[CC to Fabian - can you comment on the ovirt-node problem below]
On Thu, Nov 21, 2013 at 10:02:46PM +0000, Исаев Виталий Анатольевич wrote:
On 11/21/2013 05:56 PM, Richard W.M. Jones wrote:
> When you say "cannot access them" do you get an error
message?
> Could it be an SELinux denial?
Yes, when I am trying to open some logical volume on the hypervisor
side, for instance:
$ guestfish -a /dev/mapper/dm-xx
libguestfs fails with an error message kind of that:
$ libguestfs-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
libguestfs use, you shouldn't boot the Xen guest with it).
So this is correct because hypervisor's file system is minimalist
and
therefore contains kernel files neither in /boot nor in
/lib/modules.
Ah I see, this is a slightly different problem. If this is RHEV-H / ovirt-node then
that's a bug in ovirt-node since it is supposed to have a working libguestfs.
Can you paste the full, unedited output of:
libguestfs-test-tool
on the hypervisor.
And it is still not clear for me, how should I implement interaction
between the RHEV-M API, which tells me what logical volume (disk
image) belongs to the every VM, and the hypervisor's, to which
all the logical volume (disk images) are mapped.
So can I access the VM's disk images directly from the RHEV
Manager in
case if manager, hypervisor and storage are different hosts?
I'm not sure about this, but I guess the hooks that Itamar pointed to before should
work.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v
converts physical machines to virtual machines. Boot with a live CD or over the network
(PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
3:49 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 09:42:28AM +0000, Исаев Виталий Анатольевич wrote:
Rich, you are right; the hypervisor is RHEV-H. As Itamar has just
explained me, hooks are executed on the hypervisor’s side (not on
the RHEV-M, as I used to think), so properly working libguestfs on
the RHEV-H will resolve my issue.
This is a bug. I have filed this:
https://bugzilla.redhat.com/show_bug.cgi?id=1033508
If you have Red Hat Support it would be helpful if you could get them
to escalate this so it gets the right attention.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
4:29 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Thanks a lot. Yes, we have a Support and we will ask them to help with this bug.
How do you think, maybe we can hack this issue quickly just putting the kernel file
(desired by libguestfs) manually to some directory on the RHEV-H file system? /boot and
/lib/modules do not contain kernels on RHEV-H.
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 1:50 PM
To: Исаев Виталий Анатольевич
Cc: Itamar Heim; libguestfs(a)redhat.com; fdeutsch(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
On Fri, Nov 22, 2013 at 09:42:28AM +0000, Исаев Виталий Анатольевич wrote:
Rich, you are right; the hypervisor is RHEV-H. As Itamar has just
explained me, hooks are executed on the hypervisor’s side (not on the
RHEV-M, as I used to think), so properly working libguestfs on the
RHEV-H will resolve my issue.
This is a bug. I have filed this:
https://bugzilla.redhat.com/show_bug.cgi?id=1033508
If you have Red Hat Support it would be helpful if you could get them to escalate this so
it gets the right attention.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora
Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over
100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5:08 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 10:29:08AM +0000, Исаев Виталий Анатольевич wrote:
Thanks a lot. Yes, we have a Support and we will ask them to help
with this bug.
How do you think, maybe we can hack this issue quickly just putting
the kernel file (desired by libguestfs) manually to some directory
on the RHEV-H file system? /boot and /lib/modules do not contain
kernels on RHEV-H.
A simpler plan would be to grab an appliance from here:
http://libguestfs.org/download/binaries/appliance/
**NB** The appliances there now will not work because they are too new
to work with libguestfs 1.16. I will prepare a 1.16 appliance and
upload it shortly.
Once you've got an appliance corresponding to your version of
libguestfs, uncompress it into (any) directory and then set:
export LIBGUESTFS_PATH=/path/to/directory
and run libguestfs-test-tool to make sure everything is working.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
5:14 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Am Freitag, den 22.11.2013, 10:29 +0000 schrieb Исаев Виталий
Анатольевич:
Thanks a lot. Yes, we have a Support and we will ask them to help
with this bug.
How do you think, maybe we can hack this issue quickly just putting the kernel file
(desired by libguestfs) manually to some directory on the RHEV-H file system? /boot and
/lib/modules do not contain kernels on RHEV-H.
Hey,
as you said, a workaround is to link the kernel into the right place,
e.g.:
$ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)
- fabian
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 1:50 PM
To: Исаев Виталий Анатольевич
Cc: Itamar Heim; libguestfs(a)redhat.com; fdeutsch(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
On Fri, Nov 22, 2013 at 09:42:28AM +0000, Исаев Виталий Анатольевич wrote:
> Rich, you are right; the hypervisor is RHEV-H. As Itamar has just
> explained me, hooks are executed on the hypervisor’s side (not on the
> RHEV-M, as I used to think), so properly working libguestfs on the
> RHEV-H will resolve my issue.
This is a bug. I have filed this:
https://bugzilla.redhat.com/show_bug.cgi?id=1033508
If you have Red Hat Support it would be helpful if you could get them to escalate this so
it gets the right attention.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora
Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over
100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5:31 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 12:14:24PM +0100, Fabian Deutsch wrote:
Am Freitag, den 22.11.2013, 10:29 +0000 schrieb Исаев Виталий
Анатольевич:
> Thanks a lot. Yes, we have a Support and we will ask them to help with this bug.
>
> How do you think, maybe we can hack this issue quickly just putting the kernel file
(desired by libguestfs) manually to some directory on the RHEV-H file system? /boot and
/lib/modules do not contain kernels on RHEV-H.
Hey,
as you said, a workaround is to link the kernel into the right place,
e.g.:
$ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)
Does libguestfs-test-tool run after this? (I don't have an ovirt-node
instance). I would have thought that /lib/modules/... would need to
be in place also.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
5:39 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Am Freitag, den 22.11.2013, 11:31 +0000 schrieb Richard W.M. Jones:
On Fri, Nov 22, 2013 at 12:14:24PM +0100, Fabian Deutsch wrote:
> Am Freitag, den 22.11.2013, 10:29 +0000 schrieb Исаев Виталий
> Анатольевич:
> > Thanks a lot. Yes, we have a Support and we will ask them to help with this
bug.
> >
> > How do you think, maybe we can hack this issue quickly just putting the kernel
file (desired by libguestfs) manually to some directory on the RHEV-H file system? /boot
and /lib/modules do not contain kernels on RHEV-H.
>
> Hey,
>
> as you said, a workaround is to link the kernel into the right place,
> e.g.:
>
> $ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)
Does libguestfs-test-tool run after this? (I don't have an ovirt-node
instance). I would have thought that /lib/modules/... would need to
be in place also.
Hey,
the modules directory exists, only the initrd and vmlinuz files are
missing in /boot. It seems that the test tool passes - at leats in my
nested testing env.
- fabian
5:40 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Unfortunately, placing the link into the /boot does not work. libguestfs-test-tool failes
with the same message:
************************************************************
* IMPORTANT NOTICE
*
* When reporting bugs, include the COMPLETE, UNEDITED
* output below in your bug report.
*
************************************************************
===== Test starts here =====
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
library version: 1.16.34rhel=6,release=2.el6
guestfs_get_append: (null)
guestfs_get_attach_method: appliance
guestfs_get_autosync: 1
guestfs_get_direct: 0
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib64/guestfs
guestfs_get_pgroup: 0
guestfs_get_qemu: /usr/libexec/qemu-kvm
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum
'/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null),
initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
febootstrap-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
febootstrap use, you shouldn't boot the Xen guest with it).
libguestfs: error: cannot find any suitable libguestfs supermin, fixed or old-style
appliance on LIBGUESTFS_PATH (search path: /usr/lib64/guestfs)
libguestfs-test-tool: failed to launch appliance
libguestfs: closing guestfs handle 0x69b2d0 (state 0)
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 3:33 PM
To: Fabian Deutsch
Cc: Исаев Виталий Анатольевич; Itamar Heim; libguestfs(a)redhat.com; fdeutsch(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
On Fri, Nov 22, 2013 at 12:14:24PM +0100, Fabian Deutsch wrote:
Am Freitag, den 22.11.2013, 10:29 +0000 schrieb Исаев Виталий
Анатольевич:
> Thanks a lot. Yes, we have a Support and we will ask them to
help with this bug.
>
> How do you think, maybe we can hack this issue quickly just
putting the kernel file (desired by libguestfs) manually to some directory on the RHEV-H
file system? /boot and /lib/modules do not contain kernels on RHEV-H.
Hey,
as you said, a workaround is to link the kernel into the right
place,
e.g.:
$ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)
Does libguestfs-test-tool run after this? (I don't have an ovirt-node instance). I
would have thought that /lib/modules/... would need to be in place also.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v
converts physical machines to virtual machines. Boot with a live CD or over the network
(PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
5:46 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 11:40:45AM +0000, Исаев Виталий Анатольевич wrote:
Unfortunately, placing the link into the /boot does not work.
libguestfs-test-tool failes with the same message:
[...]
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f
checksum '/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel =
(null), initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
febootstrap-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
That's odd because it didn't seem to find any kernels in /boot.
The normal behaviour is to try to find all files matching
/boot/vmlinuz-*.x86_64
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5:51 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Oh, you are right. Wrong filename - it's my fault. Now:
====== TEST FINISHED OK ======
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 3:48 PM
To: Исаев Виталий Анатольевич
Cc: Fabian Deutsch; libguestfs(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
On Fri, Nov 22, 2013 at 11:40:45AM +0000, Исаев Виталий Анатольевич wrote:
Unfortunately, placing the link into the /boot does not work.
libguestfs-test-tool failes with the same message:
[...]
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f
checksum '/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu =
x86_64, kernel = (null), initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
febootstrap-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
That's odd because it didn't seem to find any kernels in /boot.
The normal behaviour is to try to find all files matching
/boot/vmlinuz-*.x86_64
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora
Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over
100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5:56 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 11:51:51AM +0000, Исаев Виталий Анатольевич wrote:
Oh, you are right. Wrong filename - it's my fault. Now:
====== TEST FINISHED OK ======
OK, you should be all working now.
I'll note that 1033508 is still a bug, either in ovirt-node or in
libguestfs, but we have got to fix it one way or the other.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5:53 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Am Freitag, den 22.11.2013, 11:40 +0000 schrieb Исаев Виталий
Анатольевич:
Unfortunately, placing the link into the /boot does not work.
libguestfs-test-tool failes with the same message:
Could you provide
$ ls /boot
$ ls /dev/.initramfs/live/
$ ls /dev/.initramfs/live/isolinux/
I just realized that I provided the wrong path, it should be:
$ ln -s /dev/.initramfs/live/isolinux/vmlinuz0 /boot/vmlinuz-$(uname -r)
Please remove the old link in /boot and try to link it like given above.
- fabian
************************************************************
* IMPORTANT NOTICE
*
* When reporting bugs, include the COMPLETE, UNEDITED
* output below in your bug report.
*
************************************************************
===== Test starts here =====
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
library version: 1.16.34rhel=6,release=2.el6
guestfs_get_append: (null)
guestfs_get_attach_method: appliance
guestfs_get_autosync: 1
guestfs_get_direct: 0
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib64/guestfs
guestfs_get_pgroup: 0
guestfs_get_qemu: /usr/libexec/qemu-kvm
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f
checksum '/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu =
x86_64, kernel = (null), initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
febootstrap-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
febootstrap use, you shouldn't boot the Xen guest with it).
libguestfs: error: cannot find any suitable libguestfs supermin, fixed
or old-style appliance on LIBGUESTFS_PATH (search
path: /usr/lib64/guestfs)
libguestfs-test-tool: failed to launch appliance
libguestfs: closing guestfs handle 0x69b2d0 (state 0)
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 3:33 PM
To: Fabian Deutsch
Cc: Исаев Виталий Анатольевич; Itamar Heim; libguestfs(a)redhat.com;
fdeutsch(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the
RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 12:14:24PM +0100, Fabian Deutsch wrote:
> Am Freitag, den 22.11.2013, 10:29 +0000 schrieb Исаев Виталий
> Анатольевич:
> > Thanks a lot. Yes, we have a Support and we will ask them to help
with this bug.
> >
> > How do you think, maybe we can hack this issue quickly just
putting the kernel file (desired by libguestfs) manually to some
directory on the RHEV-H file system? /boot and /lib/modules do not
contain kernels on RHEV-H.
>
> Hey,
>
> as you said, a workaround is to link the kernel into the right
place,
> e.g.:
>
> $ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)
Does libguestfs-test-tool run after this? (I don't have an ovirt-node
instance). I would have thought that /lib/modules/... would need to
be in place also.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones virt-p2v converts physical machines
to virtual machines. Boot with a live CD or over the network (PXE)
and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
6:04 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Thanks to all. Symbolic link to vmlinuz image is a solution to my problem:
$ ll /boot
total 2536
drwxr-xr-x. 3 root root 60 2013-04-15 14:49 efi
lrwxrwxrwx. 1 root root 25 2013-09-18 15:50 grub -> /dev/.initramfs/live/grub
-rw-r--r--. 1 root root 185842 2013-03-29 20:59 symvers-2.6.32-358.6.1.el6.x86_64.gz
-rw-r--r--. 1 root root 2407872 2013-03-29 20:58 System.map-2.6.32-358.6.1.el6.x86_64
lrwxrwxrwx. 1 root root 29 2013-11-22 11:42 vmlinuz-2.6.32-358.6.1.el6.x86_64 ->
/dev/.initramfs/live/vmlinuz0
$ libguestfs-test-tool
************************************************************
* IMPORTANT NOTICE
*
* When reporting bugs, include the COMPLETE, UNEDITED
* output below in your bug report.
*
************************************************************
===== Test starts here =====
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
library version: 1.16.34rhel=6,release=2.el6
guestfs_get_append: (null)
guestfs_get_attach_method: appliance
guestfs_get_autosync: 1
guestfs_get_direct: 0
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib64/guestfs
guestfs_get_pgroup: 0
guestfs_get_qemu: /usr/libexec/qemu-kvm
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum
'/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null),
initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
checking modpath /lib/modules/2.6.32-358.6.1.el6.x86_64 is a directory
picked vmlinuz-2.6.32-358.6.1.el6.x86_64 because modpath
/lib/modules/2.6.32-358.6.1.el6.x86_64 exists
supermin helper [00000ms] finished creating kernel
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/base.img
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/daemon.img
supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/hostfiles
supermin helper [00017ms] visiting /usr/lib64/guestfs/supermin.d/init.img
supermin helper [00017ms] visiting /usr/lib64/guestfs/supermin.d/ntfs.hostfiles
supermin helper [00017ms] visiting /usr/lib64/guestfs/supermin.d/ntfs.img
supermin helper [00017ms] adding kernel modules
supermin helper [00043ms] finished creating appliance
libguestfs: [00047ms] begin testing qemu features
libguestfs: [00068ms] finished testing qemu features
libguestfs: accept_from_daemon: 0x1e09260 g->state = 1
[00068ms] /usr/libexec/qemu-kvm \
-global virtio-blk-pci.scsi=off \
-nodefconfig \
-nodefaults \
-nographic \
-drive file=/tmp/libguestfs-test-tool-sda-qkHPCC,format=raw,if=virtio \
-nodefconfig \
-machine accel=kvm:tcg \
-m 500 \
-no-reboot \
-device virtio-serial \
-serial stdio \
-device sga \
-chardev socket,path=/tmp/libguestfstbW5Up/guestfsd.sock,id=channel0 \
-device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
-kernel /var/tmp/.guestfs-0/kernel.10427 \
-initrd /var/tmp/.guestfs-0/initrd.10427 \
-append 'panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off
printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm ' \
-drive
file=/var/tmp/.guestfs-0/root.10427,snapshot=on,if=virtio,cache=unsafe\x1b[1;256r\x1b[256;256H\x1b[6n
Google, Inc.
Serial Graphics Adapter 07/26/11
SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $
(mockbuild(a)hs20-bc2-3.build.redhat.com) Tue Jul 26 15:05:08 UTC 2011
Term: 80x24
4 0
\x1b[2J
SeaBIOS (version seabios-0.6.1.2-26.el6)
Probing EDD (edd=off to disable)... ok \x1b[2JInitializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.32-358.6.1.el6.x86_64 (mockbuild(a)x86-022.build.eng.bos.redhat.com) (gcc
version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Fri Mar 29 16:51:51 EDT 2013
Command line: panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off printk.time=1
cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls
Disabled fast string operations
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009b800 (usable)
BIOS-e820: 000000000009b800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001f3fd000 (usable)
BIOS-e820: 000000001f3fd000 - 000000001f400000 (reserved)
BIOS-e820: 00000000fffbc000 - 0000000100000000 (reserved)
DMI 2.4 present.
SMBIOS version 2.4 @ 0xFDA30
last_pfn = 0x1f3fd max_arch_pfn = 0x400000000
PAT not supported by CPU.
init_memory_mapping: 0000000000000000-000000001f3fd000
RAMDISK: 1f1ab000 - 1f3ef000
No NUMA configuration found
Faking a node at 0000000000000000-000000001f3fd000
Bootmem setup node 0 0000000000000000-000000001f3fd000
NODE_DATA [0000000000009000 - 000000000003cfff]
bootmap [000000000003d000 - 0000000000040e7f] pages 4
(7 early reservations) ==> bootmem [0000000000 - 001f3fd000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
#2 [0001000000 - 000201b0a4] TEXT DATA BSS ==> [0001000000 - 000201b0a4]
#3 [001f1ab000 - 001f3ef000] RAMDISK ==> [001f1ab000 - 001f3ef000]
#4 [000009b800 - 0000100000] BIOS reserved ==> [000009b800 - 0000100000]
#5 [000201c000 - 000201c059] BRK ==> [000201c000 - 000201c059]
#6 [0000008000 - 0000009000] PGTABLE ==> [0000008000 - 0000009000]
found SMP MP-table at [ffff8800000fda50] fda50
kvm-clock: Using msrs 4b564d01 and 4b564d00
kvm-clock: cpu 0, msr 0:1c25681, boot clock
Zone PFN ranges:
DMA 0x00000001 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000001 -> 0x0000009b
0: 0x00000100 -> 0x0001f3fd
SFI: Simple Firmware Interface v0.7 http://simplefirmware.org
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: BOCHSCPU
MPTABLE: Product ID: 0.1
MPTABLE: APIC at: 0xFEE00000
Processor #0 (Bootup-CPU)
I/O APIC #0 Version 17 at 0xFEC00000.
Processors: 1
SMP: Allowing 1 CPUs, 0 hotplug CPUs
PM: Registered nosave memory: 000000000009b000 - 000000000009c000
PM: Registered nosave memory: 000000000009c000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 1f400000 (gap: 1f400000:e0bbc000)
Booting paravirtualized kernel on KVM
NR_CPUS:4096 nr_cpumask_bits:1 nr_cpu_ids:1 nr_node_ids:1
PERCPU: Embedded 31 pages/cpu @ffff880002200000 s94552 r8192 d24232 u2097152
pcpu-alloc: s94552 r8192 d24232 u2097152 alloc=1*2097152
pcpu-alloc: [0] 0
kvm-clock: cpu 0, msr 0:2216681, primary cpu clock
kvm-stealtime: cpu 0, msr 220e840
Built 1 zonelists in Node order, mobility grouping on. Total pages: 126041
Policy zone: DMA32
Kernel command line: panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off
printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm
[ 0.000000] Disabling memory control group subsystem
[ 0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Memory: 483960k/511988k available (5221k kernel code, 408k absent, 27620k
reserved, 7120k data, 1264k init)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] NR_IRQS:33024 nr_irqs:256
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [ttyS0] enabled
[ 0.000000] Detected 2400.084 MHz processor.
[ 0.001999] Calibrating delay loop (skipped) preset value.. 4800.16 BogoMIPS
(lpj=2400084)
[ 0.002004] pid_max: default: 32768 minimum: 301
[ 0.002522] Security Framework initialized
[ 0.002886] SELinux: Disabled at boot.
[ 0.003456] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[ 0.004126] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[ 0.005070] Mount-cache hash table entries: 256
[ 0.006010] Initializing cgroup subsys ns
[ 0.006352] Initializing cgroup subsys cpuacct
[ 0.006738] Initializing cgroup subsys memory
[ 0.007015] Initializing cgroup subsys devices
[ 0.007388] Initializing cgroup subsys freezer
[ 0.007764] Initializing cgroup subsys net_cls
[ 0.008003] Initializing cgroup subsys blkio
[ 0.008370] Initializing cgroup subsys perf_event
[ 0.009004] Initializing cgroup subsys net_prio
[ 0.009472] Disabled fast string operations
[ 0.010220] mce: CPU supports 10 MCE banks
[ 0.010615] alternatives: switching to unfair spinlock
[ 0.014076] SMP alternatives: switching to UP code
[ 0.029142] Freeing SMP alternatives: 35k freed
[ 0.029555] ftrace: converting mcount calls to 0f 1f 44 00 00
[ 0.030003] ftrace: allocating 21432 entries in 85 pages
[ 0.031043] Setting APIC routing to flat
[ 0.034365] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.034959] CPU0: Intel QEMU Virtual CPU version (cpu64-rhel6) stepping 03
[ 0.137032] Performance Events: Broken PMU hardware detected, using software events
only.
[ 0.137917] NMI watchdog disabled (cpu0): hardware events not enabled
[ 0.138005] Brought up 1 CPUs
[ 0.138301] Total of 1 processors activated (4800.16 BogoMIPS).
[ 0.139419] devtmpfs: initialized
[ 0.144074] regulator: core version 0.5
[ 0.144507] NET: Registered protocol family 16
[ 0.146035] PCI: Using configuration type 1 for base access
[ 0.147433] bio: create slab <bio-0> at 0
[ 0.147937] ACPI: Interpreter disabled.
[ 0.148023] vgaarb: loaded
[ 0.149058] SCSI subsystem initialized
[ 0.149505] usbcore: registered new interface driver usbfs
[ 0.150001] usbcore: registered new interface driver hub
[ 0.150532] usbcore: registered new device driver usb
[ 0.151064] PCI: Probing PCI hardware
[ 0.152713] pci 0000:00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 ACPI
[ 0.152994] pci 0000:00:01.3: quirk: [io 0xb100-0xb10f] claimed by PIIX4 SMB
[ 0.155836] pci 0000:00:01.0: PIIX/ICH IRQ router [8086:7000]
[ 0.156151] NetLabel: Initializing
[ 0.156485] NetLabel: domain hash size = 128
[ 0.156986] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.157469] NetLabel: unlabeled traffic allowed by default
[ 0.158025] Switching to clocksource kvm-clock
[ 0.166429] pnp: PnP ACPI: disabled
[ 0.166996] NET: Registered protocol family 2
[ 0.167475] IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.168653] TCP established hash table entries: 16384 (order: 6, 262144 bytes)
[ 0.169415] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[ 0.170090] TCP: Hash tables configured (established 16384 bind 16384)
[ 0.170708] TCP reno registered
[ 0.171089] NET: Registered protocol family 1
[ 0.171514] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 0.172097] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[ 0.172639] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 0.173262] Trying to unpack rootfs image as initramfs...
[ 0.175540] Freeing initrd memory: 2320k freed
[ 0.176288] platform rtc_cmos: registered platform RTC device (no PNP device found)
[ 0.177300] audit: initializing netlink socket (disabled)
[ 0.177829] type=2000 audit(1385121840.176:1): initialized
[ 0.188220] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 0.189428] VFS: Disk quotas dquot_6.5.2
[ 0.189836] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.190531] msgmni has been set to 949
[ 0.191089] alg: No test for stdrng (krng)
[ 0.191500] ksign: Installing public key data
[ 0.191917] Loading keyring
[ 0.192207] - Added public key CD7AEEA03C3767CE
[ 0.192629] - User ID: Red Hat, Inc. (Kernel Module GPG key)
[ 0.193179] - Added public key D4A26C9CCD09BEDA
[ 0.193604] - User ID: Red Hat Enterprise Linux Driver Update Program
<secalert(a)redhat.com
[ 0.194428] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
251)
[ 0.195155] io scheduler noop registered
[ 0.195527] io scheduler anticipatory registered
[ 0.195963] io scheduler deadline registered
[ 0.196478] io scheduler cfq registered (default)
[ 0.197060] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 0.197601] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 0.198237] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.198935] ipmi message handler version 39.2
[ 0.199376] IPMI System Interface driver.
[ 0.199774] ipmi_si: Adding default-specified kcs state machine
[ 0.200363] ipmi_si: Trying default-specified kcs state machine at i/o address 0xca2,
slave address 0x0, irq 0
[ 0.201310] ipmi_si: Interface detection failed
[ 0.201735] ipmi_si: Adding default-specified smic state machine
[ 0.202326] ipmi_si: Trying default-specified smic state machine at i/o address 0xca9,
slave address 0x0, irq 0
[ 0.203593] ipmi_si: Interface detection failed
[ 0.204061] ipmi_si: Adding default-specified bt state machine
[ 0.204620] ipmi_si: Trying default-specified bt state machine at i/o address 0xe4,
slave address 0x0, irq 0
[ 0.205568] ipmi_si: Interface detection failed
[ 0.206093] ipmi_si: Unable to find any System Interface(s)
[ 0.207670] Non-volatile memory driver v1.3
[ 0.208122] Linux agpgart interface v0.103
[ 0.208618] crash memory driver: version 1.1
[ 0.209065] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
\xff[ 0.454447] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 0.456134] brd: module loaded
[ 0.456895] loop: module loaded
[ 0.457253] input: Macintosh mouse button emulation as /devices/virtual/input/input0
[ 0.458034] Fixed MDIO Bus: probed
[ 0.458395] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.459041] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.459630] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.460296] PNP: No PS/2 controller found. Probing ports directly.
[ 0.461476] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.461954] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 0.462518] mice: PS/2 mouse device common for all mice
[ 0.463316] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input1
[ 0.464392] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[ 0.465083] rtc0: alarms up to one day, 114 bytes nvram
[ 0.465581] cpuidle: using governor ladder
[ 0.465975] cpuidle: using governor menu
[ 0.466359] EFI Variables Facility v0.08 2004-May-17
[ 0.469362] usbcore: registered new interface driver hiddev
[ 0.469910] usbcore: registered new interface driver usbhid
[ 0.470448] usbhid: v2.6:USB HID core driver
[ 0.471297] TCP cubic registered
[ 0.471611] Initializing XFRM netlink socket
[ 0.472046] NET: Registered protocol family 17
[ 0.472546] registered taskstats version 1
[ 0.473141] rtc_cmos rtc_cmos: setting system clock to 2013-11-22 12:03:59 UTC
(1385121839)
[ 0.473957] Initalizing network drop monitor service
[ 0.474463] Freeing unused kernel memory: 1264k freed
[ 0.475222] Write protecting the kernel read-only data: 10240k
[ 0.475973] Freeing unused kernel memory: 904k freed
[ 0.476746] Freeing unused kernel memory: 1676k freed
febootstrap: mounting /proc
febootstrap: uptime: 0.47 0.27
febootstrap: ext2 mini initrd starting up: 3.12 zlib
febootstrap: mounting /sys
febootstrap: internal insmod libcrc32c.ko
febootstrap: internal insmod crc32c-intel.ko
insmod: init_module: crc32c-intel.ko: No such device
febootstrap: internal insmod crc-itu-t.ko
febootstrap: internal insmod crc-t10dif.ko
febootstrap: internal insmod crc-ccitt.ko
febootstrap: internal insmod crc7.ko
febootstrap: internal insmod mbcache.ko
febootstrap: internal insmod cdrom.ko
febootstrap: internal insmod sr_mod.ko
febootstrap: internal insmod ata_piix.ko
[ 0.507273] scsi0 : ata_piix
[ 0.507635] scsi1 : ata_piix
[ 0.507954] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14
[ 0.508684] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15
febootstrap: internal insmod scsi_transport_spi.ko
febootstrap: internal insmod sym53c8xx.ko
febootstrap: internal insmod sd_mod.ko
febootstrap: internal insmod virtio_ring.ko
febootstrap: internal insmod virtio.ko
febootstrap: internal insmod virtio-rng.ko
febootstrap: internal insmod virtio_console.ko
febootstrap: internal insmod virtio_blk.ko
febootstrap: internal insmod virtio_scsi.ko
febootstrap: internal insmod virtio_net.ko
febootstrap: internal insmod virtio_pci.ko
[ 0.704317] virtio-pci 0000:00:02.0: PCI->APIC IRQ transform: INT A -> IRQ 10
[ 0.718732] virtio-pci 0000:00:03.0: PCI->APIC IRQ transform: INT A -> IRQ 11
[ 0.733126] vda: unknown partition table
[ 0.734315] virtio-pci 0000:00:04.0: PCI->APIC IRQ transform: INT A -> IRQ 11
[ 0.749079] vdb: unknown partition table
febootstrap: internal insmod virtio_balloon.ko
febootstrap: internal insmod jbd2.ko
febootstrap: internal insmod ext4.ko
febootstrap: internal insmod ext2.ko
febootstrap: picked /sys/block/vdb/dev as root device
febootstrap: creating /dev/root as block special 253:16
febootstrap: mounting new root on /root
febootstrap: chroot
/proc/uptime: No such file or directory
Starting /init script ...
Starting udev: [ 0.901065] input: ImExPS/2 Generic Explorer Mouse as
/devices/platform/i8042/serio1/input/input2
udevd[88]: specified group 'dialout' unknown
udevd[88]: specified group 'floppy' unknown
udevd[88]: specified user 'vcsa' unknown
udevd[88]: specified group 'cdrom' unknown
udevd[88]: specified group 'tape' unknown
/sbin/start_udev: line 291: /etc/sysconfig/network: No such file or directory
[ 0.952509] udev: starting version 147
[ OK ] SIOCSIFADDR: No such device
eth0: unknown interface: No such device
SIOCADDRT: No such process
mdadm: No arrays found in config file or automatically
[ 2.232739] device-mapper: uevent: version 1.0.3
[ 2.233580] device-mapper: ioctl: 4.23.6-ioctl (2012-07-25) initialised:
dm-devel(a)redhat.com
Reading all physical volumes. This may take a while...
No volume groups found
No volume groups found
/dev:
total 0
lrwxrwxrwx 1 root root 13 Nov 22 12:03 MAKEDEV -> /sbin/MAKEDEV
drwxr-xr-x 2 root root 560 Nov 22 12:04 block
drwxr-xr-x 2 root root 2140 Nov 22 12:04 char
crw------- 1 root root 5, 1 Nov 22 12:04 console
lrwxrwxrwx 1 root root 11 Nov 22 12:03 core -> /proc/kcore
drwxr-xr-x 3 root root 60 Nov 22 12:04 cpu
crw-rw---- 1 root root 10, 61 Nov 22 12:04 cpu_dma_latency
crw-rw---- 1 root root 10, 62 Nov 22 12:04 crash
drwxr-xr-x 4 root root 80 Nov 22 12:04 disk
lrwxrwxrwx 1 root root 13 Nov 22 12:03 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Nov 22 12:04 full
crw-rw-rw- 1 root root 10, 229 Nov 22 12:03 fuse
drwxr-xr-x 2 root root 40 Nov 22 12:03 hugepages
drwxr-xr-x 3 root root 180 Nov 22 12:04 input
crw-rw---- 1 root root 1, 11 Nov 22 12:04 kmsg
brw-rw---- 1 root disk 7, 0 Nov 22 12:04 loop0
brw-rw---- 1 root disk 7, 1 Nov 22 12:04 loop1
brw-rw---- 1 root disk 7, 2 Nov 22 12:04 loop2
brw-rw---- 1 root disk 7, 3 Nov 22 12:04 loop3
brw-rw---- 1 root disk 7, 4 Nov 22 12:04 loop4
brw-rw---- 1 root disk 7, 5 Nov 22 12:04 loop5
brw-rw---- 1 root disk 7, 6 Nov 22 12:04 loop6
brw-rw---- 1 root disk 7, 7 Nov 22 12:04 loop7
crw-rw---- 1 root lp 6, 0 Nov 22 12:03 lp0
crw-rw---- 1 root lp 6, 1 Nov 22 12:03 lp1
crw-rw---- 1 root lp 6, 2 Nov 22 12:03 lp2
crw-rw---- 1 root lp 6, 3 Nov 22 12:03 lp3
drwxr-xr-x 2 root root 60 Nov 22 12:04 mapper
crw-rw---- 1 root root 10, 227 Nov 22 12:04 mcelog
drwxr-xr-x 2 root root 60 Nov 22 12:04 md
crw-r----- 1 root kmem 1, 1 Nov 22 12:04 mem
drwxr-xr-x 2 root root 60 Nov 22 12:03 net
crw-rw---- 1 root root 10, 60 Nov 22 12:04 network_latency
crw-rw---- 1 root root 10, 59 Nov 22 12:04 network_throughput
crw-rw-rw- 1 root root 1, 3 Nov 22 12:04 null
crw-r----- 1 root kmem 10, 144 Nov 22 12:04 nvram
crw-rw---- 1 root root 1, 12 Nov 22 12:04 oldmem
crw-r----- 1 root kmem 1, 4 Nov 22 12:04 port
crw------- 1 root root 108, 0 Nov 22 12:03 ppp
crw-rw-rw- 1 root tty 5, 2 Nov 22 12:04 ptmx
drwxr-xr-x 2 root root 40 Nov 22 12:03 pts
brw-rw---- 1 root disk 1, 0 Nov 22 12:04 ram0
brw-rw---- 1 root disk 1, 1 Nov 22 12:04 ram1
brw-rw---- 1 root disk 1, 10 Nov 22 12:04 ram10
brw-rw---- 1 root disk 1, 11 Nov 22 12:04 ram11
brw-rw---- 1 root disk 1, 12 Nov 22 12:04 ram12
brw-rw---- 1 root disk 1, 13 Nov 22 12:04 ram13
brw-rw---- 1 root disk 1, 14 Nov 22 12:04 ram14
brw-rw---- 1 root disk 1, 15 Nov 22 12:04 ram15
brw-rw---- 1 root disk 1, 2 Nov 22 12:04 ram2
brw-rw---- 1 root disk 1, 3 Nov 22 12:04 ram3
brw-rw---- 1 root disk 1, 4 Nov 22 12:04 ram4
brw-rw---- 1 root disk 1, 5 Nov 22 12:04 ram5
brw-rw---- 1 root disk 1, 6 Nov 22 12:04 ram6
brw-rw---- 1 root disk 1, 7 Nov 22 12:04 ram7
brw-rw---- 1 root disk 1, 8 Nov 22 12:04 ram8
brw-rw---- 1 root disk 1, 9 Nov 22 12:04 ram9
crw-rw-rw- 1 root root 1, 8 Nov 22 12:04 random
drwxr-xr-x 2 root root 60 Nov 22 12:04 raw
lrwxrwxrwx 1 root root 4 Nov 22 12:04 rtc -> rtc0
crw-rw---- 1 root root 254, 0 Nov 22 12:04 rtc0
drwxr-xr-x 2 root root 40 Nov 22 12:03 shm
crw-rw---- 1 root root 10, 231 Nov 22 12:04 snapshot
lrwxrwxrwx 1 root root 15 Nov 22 12:03 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Nov 22 12:03 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Nov 22 12:03 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root tty 5, 0 Nov 22 12:04 tty
crw--w---- 1 root tty 4, 0 Nov 22 12:04 tty0
crw--w---- 1 root tty 4, 1 Nov 22 12:04 tty1
crw--w---- 1 root tty 4, 10 Nov 22 12:04 tty10
crw--w---- 1 root tty 4, 11 Nov 22 12:04 tty11
crw--w---- 1 root tty 4, 12 Nov 22 12:04 tty12
crw--w---- 1 root tty 4, 13 Nov 22 12:04 tty13
crw--w---- 1 root tty 4, 14 Nov 22 12:04 tty14
crw--w---- 1 root tty 4, 15 Nov 22 12:04 tty15
crw--w---- 1 root tty 4, 16 Nov 22 12:04 tty16
crw--w---- 1 root tty 4, 17 Nov 22 12:04 tty17
crw--w---- 1 root tty 4, 18 Nov 22 12:04 tty18
crw--w---- 1 root tty 4, 19 Nov 22 12:04 tty19
crw--w---- 1 root tty 4, 2 Nov 22 12:04 tty2
crw--w---- 1 root tty 4, 20 Nov 22 12:04 tty20
crw--w---- 1 root tty 4, 21 Nov 22 12:04 tty21
crw--w---- 1 root tty 4, 22 Nov 22 12:04 tty22
crw--w---- 1 root tty 4, 23 Nov 22 12:04 tty23
crw--w---- 1 root tty 4, 24 Nov 22 12:04 tty24
crw--w---- 1 root tty 4, 25 Nov 22 12:04 tty25
crw--w---- 1 root tty 4, 26 Nov 22 12:04 tty26
crw--w---- 1 root tty 4, 27 Nov 22 12:04 tty27
crw--w---- 1 root tty 4, 28 Nov 22 12:04 tty28
crw--w---- 1 root tty 4, 29 Nov 22 12:04 tty29
crw--w---- 1 root tty 4, 3 Nov 22 12:04 tty3
crw--w---- 1 root tty 4, 30 Nov 22 12:04 tty30
crw--w---- 1 root tty 4, 31 Nov 22 12:04 tty31
crw--w---- 1 root tty 4, 32 Nov 22 12:04 tty32
crw--w---- 1 root tty 4, 33 Nov 22 12:04 tty33
crw--w---- 1 root tty 4, 34 Nov 22 12:04 tty34
crw--w---- 1 root tty 4, 35 Nov 22 12:04 tty35
crw--w---- 1 root tty 4, 36 Nov 22 12:04 tty36
crw--w---- 1 root tty 4, 37 Nov 22 12:04 tty37
crw--w---- 1 root tty 4, 38 Nov 22 12:04 tty38
crw--w---- 1 root tty 4, 39 Nov 22 12:04 tty39
crw--w---- 1 root tty 4, 4 Nov 22 12:04 tty4
crw--w---- 1 root tty 4, 40 Nov 22 12:04 tty40
crw--w---- 1 root tty 4, 41 Nov 22 12:04 tty41
crw--w---- 1 root tty 4, 42 Nov 22 12:04 tty42
crw--w---- 1 root tty 4, 43 Nov 22 12:04 tty43
crw--w---- 1 root tty 4, 44 Nov 22 12:04 tty44
crw--w---- 1 root tty 4, 45 Nov 22 12:04 tty45
crw--w---- 1 root tty 4, 46 Nov 22 12:04 tty46
crw--w---- 1 root tty 4, 47 Nov 22 12:04 tty47
crw--w---- 1 root tty 4, 48 Nov 22 12:04 tty48
crw--w---- 1 root tty 4, 49 Nov 22 12:04 tty49
crw--w---- 1 root tty 4, 5 Nov 22 12:04 tty5
crw--w---- 1 root tty 4, 50 Nov 22 12:04 tty50
crw--w---- 1 root tty 4, 51 Nov 22 12:04 tty51
crw--w---- 1 root tty 4, 52 Nov 22 12:04 tty52
crw--w---- 1 root tty 4, 53 Nov 22 12:04 tty53
crw--w---- 1 root tty 4, 54 Nov 22 12:04 tty54
crw--w---- 1 root tty 4, 55 Nov 22 12:04 tty55
crw--w---- 1 root tty 4, 56 Nov 22 12:04 tty56
crw--w---- 1 root tty 4, 57 Nov 22 12:04 tty57
crw--w---- 1 root tty 4, 58 Nov 22 12:04 tty58
crw--w---- 1 root tty 4, 59 Nov 22 12:04 tty59
crw--w---- 1 root tty 4, 6 Nov 22 12:04 tty6
crw--w---- 1 root tty 4, 60 Nov 22 12:04 tty60
crw--w---- 1 root tty 4, 61 Nov 22 12:04 tty61
crw--w---- 1 root tty 4, 62 Nov 22 12:04 tty62
crw--w---- 1 root tty 4, 63 Nov 22 12:04 tty63
crw--w---- 1 root tty 4, 7 Nov 22 12:04 tty7
crw--w---- 1 root tty 4, 8 Nov 22 12:04 tty8
crw--w---- 1 root tty 4, 9 Nov 22 12:04 tty9
crw-rw---- 1 root root 4, 64 Nov 22 12:04 ttyS0
crw-rw---- 1 root root 4, 65 Nov 22 12:04 ttyS1
crw-rw---- 1 root root 4, 66 Nov 22 12:04 ttyS2
crw-rw---- 1 root root 4, 67 Nov 22 12:04 ttyS3
crw-rw-rw- 1 root root 1, 9 Nov 22 12:04 urandom
crw-rw---- 1 root root 250, 0 Nov 22 12:04 usbmon0
crw-rw---- 1 root tty 7, 0 Nov 22 12:04 vcs
crw-rw---- 1 root tty 7, 1 Nov 22 12:04 vcs1
crw-rw---- 1 root tty 7, 128 Nov 22 12:04 vcsa
crw-rw---- 1 root tty 7, 129 Nov 22 12:04 vcsa1
brw-rw---- 1 root disk 253, 0 Nov 22 12:04 vda
brw-rw---- 1 root disk 253, 16 Nov 22 12:04 vdb
crw-rw---- 1 root root 10, 63 Nov 22 12:04 vga_arbiter
drwxr-xr-x 2 root root 60 Nov 22 12:04 virtio-ports
crw-rw---- 1 root root 248, 1 Nov 22 12:04 vport0p1
crw-rw-rw- 1 root root 1, 5 Nov 22 12:04 zero
/dev/block:
total 0
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:0 -> ../ram0
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:1 -> ../ram1
lrwxrwxrwx 1 root root 8 Nov 22 12:04 1:10 -> ../ram10
lrwxrwxrwx 1 root root 8 Nov 22 12:04 1:11 -> ../ram11
lrwxrwxrwx 1 root root 8 Nov 22 12:04 1:12 -> ../ram12
lrwxrwxrwx 1 root root 8 Nov 22 12:04 1:13 -> ../ram13
lrwxrwxrwx 1 root root 8 Nov 22 12:04 1:14 -> ../ram14
lrwxrwxrwx 1 root root 8 Nov 22 12:04 1:15 -> ../ram15
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:2 -> ../ram2
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:3 -> ../ram3
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:4 -> ../ram4
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:5 -> ../ram5
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:6 -> ../ram6
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:7 -> ../ram7
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:8 -> ../ram8
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:9 -> ../ram9
lrwxrwxrwx 1 root root 6 Nov 22 12:04 253:0 -> ../vda
lrwxrwxrwx 1 root root 6 Nov 22 12:04 253:16 -> ../vdb
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:0 -> ../loop0
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:1 -> ../loop1
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:2 -> ../loop2
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:3 -> ../loop3
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:4 -> ../loop4
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:5 -> ../loop5
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:6 -> ../loop6
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:7 -> ../loop7
/dev/char:
total 0
lrwxrwxrwx 1 root root 8 Nov 22 12:04 10:144 -> ../nvram
lrwxrwxrwx 1 root root 9 Nov 22 12:04 10:227 -> ../mcelog
lrwxrwxrwx 1 root root 11 Nov 22 12:04 10:231 -> ../snapshot
lrwxrwxrwx 1 root root 17 Nov 22 12:04 10:58 -> ../mapper/control
lrwxrwxrwx 1 root root 21 Nov 22 12:04 10:59 -> ../network_throughput
lrwxrwxrwx 1 root root 18 Nov 22 12:04 10:60 -> ../network_latency
lrwxrwxrwx 1 root root 18 Nov 22 12:04 10:61 -> ../cpu_dma_latency
lrwxrwxrwx 1 root root 8 Nov 22 12:04 10:62 -> ../crash
lrwxrwxrwx 1 root root 14 Nov 22 12:04 10:63 -> ../vga_arbiter
lrwxrwxrwx 1 root root 15 Nov 22 12:04 13:32 -> ../input/mouse0
lrwxrwxrwx 1 root root 15 Nov 22 12:04 13:33 -> ../input/mouse1
lrwxrwxrwx 1 root root 13 Nov 22 12:04 13:63 -> ../input/mice
lrwxrwxrwx 1 root root 15 Nov 22 12:04 13:64 -> ../input/event0
lrwxrwxrwx 1 root root 15 Nov 22 12:04 13:65 -> ../input/event1
lrwxrwxrwx 1 root root 15 Nov 22 12:04 13:66 -> ../input/event2
lrwxrwxrwx 1 root root 13 Nov 22 12:04 162:0 -> ../raw/rawctl
lrwxrwxrwx 1 root root 6 Nov 22 12:04 1:1 -> ../mem
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:11 -> ../kmsg
lrwxrwxrwx 1 root root 9 Nov 22 12:04 1:12 -> ../oldmem
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:3 -> ../null
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:4 -> ../port
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:5 -> ../zero
lrwxrwxrwx 1 root root 7 Nov 22 12:04 1:7 -> ../full
lrwxrwxrwx 1 root root 9 Nov 22 12:04 1:8 -> ../random
lrwxrwxrwx 1 root root 10 Nov 22 12:04 1:9 -> ../urandom
lrwxrwxrwx 1 root root 12 Nov 22 12:04 202:0 -> ../cpu/0/msr
lrwxrwxrwx 1 root root 14 Nov 22 12:04 203:0 -> ../cpu/0/cpuid
lrwxrwxrwx 1 root root 11 Nov 22 12:04 248:1 -> ../vport0p1
lrwxrwxrwx 1 root root 10 Nov 22 12:04 250:0 -> ../usbmon0
lrwxrwxrwx 1 root root 7 Nov 22 12:04 254:0 -> ../rtc0
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:0 -> ../tty0
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:1 -> ../tty1
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:10 -> ../tty10
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:11 -> ../tty11
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:12 -> ../tty12
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:13 -> ../tty13
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:14 -> ../tty14
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:15 -> ../tty15
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:16 -> ../tty16
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:17 -> ../tty17
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:18 -> ../tty18
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:19 -> ../tty19
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:2 -> ../tty2
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:20 -> ../tty20
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:21 -> ../tty21
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:22 -> ../tty22
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:23 -> ../tty23
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:24 -> ../tty24
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:25 -> ../tty25
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:26 -> ../tty26
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:27 -> ../tty27
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:28 -> ../tty28
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:29 -> ../tty29
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:3 -> ../tty3
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:30 -> ../tty30
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:31 -> ../tty31
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:32 -> ../tty32
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:33 -> ../tty33
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:34 -> ../tty34
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:35 -> ../tty35
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:36 -> ../tty36
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:37 -> ../tty37
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:38 -> ../tty38
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:39 -> ../tty39
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:4 -> ../tty4
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:40 -> ../tty40
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:41 -> ../tty41
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:42 -> ../tty42
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:43 -> ../tty43
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:44 -> ../tty44
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:45 -> ../tty45
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:46 -> ../tty46
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:47 -> ../tty47
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:48 -> ../tty48
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:49 -> ../tty49
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:5 -> ../tty5
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:50 -> ../tty50
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:51 -> ../tty51
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:52 -> ../tty52
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:53 -> ../tty53
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:54 -> ../tty54
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:55 -> ../tty55
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:56 -> ../tty56
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:57 -> ../tty57
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:58 -> ../tty58
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:59 -> ../tty59
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:6 -> ../tty6
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:60 -> ../tty60
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:61 -> ../tty61
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:62 -> ../tty62
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:63 -> ../tty63
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:64 -> ../ttyS0
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:65 -> ../ttyS1
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:66 -> ../ttyS2
lrwxrwxrwx 1 root root 8 Nov 22 12:04 4:67 -> ../ttyS3
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:7 -> ../tty7
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:8 -> ../tty8
lrwxrwxrwx 1 root root 7 Nov 22 12:04 4:9 -> ../tty9
lrwxrwxrwx 1 root root 6 Nov 22 12:04 5:0 -> ../tty
lrwxrwxrwx 1 root root 10 Nov 22 12:04 5:1 -> ../console
lrwxrwxrwx 1 root root 7 Nov 22 12:04 5:2 -> ../ptmx
lrwxrwxrwx 1 root root 6 Nov 22 12:04 7:0 -> ../vcs
lrwxrwxrwx 1 root root 7 Nov 22 12:04 7:1 -> ../vcs1
lrwxrwxrwx 1 root root 7 Nov 22 12:04 7:128 -> ../vcsa
lrwxrwxrwx 1 root root 8 Nov 22 12:04 7:129 -> ../vcsa1
/dev/cpu:
total 0
drwxr-xr-x 2 root root 80 Nov 22 12:04 0
/dev/cpu/0:
total 0
cr--r--r-- 1 root root 203, 0 Nov 22 12:04 cpuid
crw-rw---- 1 root root 202, 0 Nov 22 12:04 msr
/dev/disk:
total 0
drwxr-xr-x 2 root root 80 Nov 22 12:04 by-path
drwxr-xr-x 2 root root 60 Nov 22 12:04 by-uuid
/dev/disk/by-path:
total 0
lrwxrwxrwx 1 root root 9 Nov 22 12:04 pci-0000:00:03.0-virtio-pci-virtio1 ->
../../vda
lrwxrwxrwx 1 root root 9 Nov 22 12:04 pci-0000:00:04.0-virtio-pci-virtio2 ->
../../vdb
/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root root 9 Nov 22 12:04 77215008-5380-4417-a972-7f7090ad4429 ->
../../vdb
/dev/hugepages:
total 0
/dev/input:
total 0
drwxr-xr-x 2 root root 100 Nov 22 12:04 by-path
crw-r----- 1 root root 13, 64 Nov 22 12:04 event0
crw-r----- 1 root root 13, 65 Nov 22 12:04 event1
crw-r----- 1 root root 13, 66 Nov 22 12:04 event2
crw-r----- 1 root root 13, 63 Nov 22 12:04 mice
crw-r----- 1 root root 13, 32 Nov 22 12:04 mouse0
crw-r----- 1 root root 13, 33 Nov 22 12:04 mouse1
/dev/input/by-path:
total 0
lrwxrwxrwx 1 root root 9 Nov 22 12:04 platform-i8042-serio-0-event-kbd -> ../event1
lrwxrwxrwx 1 root root 9 Nov 22 12:04 platform-i8042-serio-1-event-mouse -> ../event2
lrwxrwxrwx 1 root root 9 Nov 22 12:04 platform-i8042-serio-1-mouse -> ../mouse1
/dev/mapper:
total 0
crw-rw---- 1 root root 10, 58 Nov 22 12:04 control
/dev/md:
total 0
-rw------- 1 root root 0 Nov 22 12:04 md-device-map
/dev/net:
total 0
crw-rw-rw- 1 root root 10, 200 Nov 22 12:03 tun
/dev/pts:
total 0
/dev/raw:
total 0
crw-rw---- 1 root disk 162, 0 Nov 22 12:04 rawctl
/dev/shm:
total 0
/dev/virtio-ports:
total 0
lrwxrwxrwx 1 root root 11 Nov 22 12:04 org.libguestfs.channel.0 -> ../vport0p1
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
/dev/root / ext2 rw,noatime,errors=continue 0 0
/proc /proc proc rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
/dev /dev devtmpfs rw,relatime,size=241996k,nr_inodes=60499,mode=755 0 0
No volume groups found
No volume groups found
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
Module Size Used by
dm_mod 82839 0
ext2 67965 1
ext4 363408 0
jbd2 90230 1 ext4
virtio_balloon 4798 0
virtio_pci 6985 0
virtio_net 16824 0
virtio_scsi 9139 0
virtio_blk 7164 1
virtio_console 17806 0
virtio_rng 2752 0
virtio 4977 7
virtio_balloon,virtio_pci,virtio_net,virtio_scsi,virtio_blk,virtio_console,virtio_rng
virtio_ring 8301 7
virtio_balloon,virtio_pci,virtio_net,virtio_scsi,virtio_blk,virtio_console,virtio_rng
sd_mod 38976 0
sym53c8xx 77071 0
scsi_transport_spi 25863 1 sym53c8xx
ata_piix 24121 0
sr_mod 15177 0
cdrom 39085 1 sr_mod
mbcache 8193 2 ext2,ext4
crc7 1457 0
crc_ccitt 1717 0
crc_t10dif 1541 1 sd_mod
crc_itu_t 1717 0
libcrc32c 1246 0
Fri Nov 22 12:04:01 UTC 2013
uptime: 2.47 1.42
verbose daemon enabled
linux commmand line: panic=1 console=ttyS0 udevtimeout=300 no_timer_check acpi=off
printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm
udevadm settle
udevsettle
udevsettle: No such file or directory
libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
libguestfs: [03456ms] appliance is up
Guest launched OK.
libguestfs: send_to_daemon: 64 bytes: 00 00 00 3c | 20 00 f5 f5 | 00 00 00 04 | 00 00 00
d2 | 00 00 00 00 | ...
guestfsd: main_loop: new request, len 0x3c
/dev/sda: No such file or directory
udevadm settle
udevsettle
udevsettle: No such file or directory
parted -s -- /dev/vda mklabel msdos mkpart primary 128s -128s
[ 3.166588] vda:
[ 3.167922] vda: vda1
Warning: The resulting partition is not properly aligned for best performance.
udevadm settle
udevsettle
udevsettle: No such file or directory
guestfsd: main_loop: proc 210 (part_disk) took 0.08 seconds
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 d2 | 00 00 00
01 | 00 12 34 00 | ...
libguestfs: send_to_daemon: 68 bytes: 00 00 00 40 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00
2a | 00 00 00 00 | ...
guestfsd: main_loop: new request, len 0x40
/dev/sda1: No such file or directory
mke2fs -t ext2 -F /dev/vda1
mke2fs 1.41.12 (17-May-2010)
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 2a | 00 00 00
01 | 00 12 34 01 | ...
libguestfs: send_to_daemon: 72 bytes: 00 00 00 44 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00
4a | 00 00 00 00 | ...
guestfsd: main_loop: proc 42 (mkfs) took 0.02 seconds
guestfsd: main_loop: new request, len 0x44
/dev/sda1: No such file or directory
mount -o /dev/vda1 /sysroot/
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 4a | 00 00 00
01 | 00 12 34 02 | ...
libguestfs: send_to_daemon: 56 bytes: 00 00 00 34 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00
03 | 00 00 00 00 | ...
guestfsd: main_loop: proc 74 (mount_options) took 0.00 seconds
guestfsd: main_loop: new request, len 0x34
guestfsd: main_loop: proc 3 (touch) took 0.00 seconds
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 03 | 00 00 00
01 | 00 12 34 03 | ...
libguestfs: send_to_daemon: 44 bytes: 00 00 00 28 | 20 00 f5 f5 | 00 00 00 04 | 00 00 01
1a | 00 00 00 00 | ...
guestfsd: main_loop: new request, len 0x28
umount /sysroot
fsync /dev/vda
guestfsd: main_loop: proc 282 (internal_autosync) took 0.00 seconds
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00
01 | 00 12 34 04 | ...
libguestfs: sending SIGTERM to process 10448
libguestfs: closing guestfs handle 0x1e09260 (state 0)
===== TEST FINISHED OK =====
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Fabian Deutsch [mailto:fabiand@redhat.com]
Sent: Friday, November 22, 2013 3:54 PM
To: Исаев Виталий Анатольевич
Cc: Richard W.M. Jones; libguestfs(a)redhat.com
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
Am Freitag, den 22.11.2013, 11:40 +0000 schrieb Исаев Виталий
Анатольевич:
> >
>
>
>
Unfortunately, placing the link into the /boot does not work.
libguestfs-test-tool failes with the same message:
Could you provide
$ ls /boot
$ ls /dev/.initramfs/live/
$ ls /dev/.initramfs/live/isolinux/
I just realized that I provided the wrong path, it should be:
$ ln -s /dev/.initramfs/live/isolinux/vmlinuz0 /boot/vmlinuz-$(uname -r)
Please remove the old link in /boot and try to link it like given above.
- fabian
************************************************************
* IMPORTANT NOTICE
*
* When reporting bugs, include the COMPLETE, UNEDITED
* output below in your bug report.
*
************************************************************
===== Test starts here =====
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/roo
t/bin
library version: 1.16.34rhel=6,release=2.el6
guestfs_get_append: (null)
guestfs_get_attach_method: appliance
guestfs_get_autosync: 1
guestfs_get_direct: 0
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib64/guestfs
guestfs_get_pgroup: 0
guestfs_get_qemu: /usr/libexec/qemu-kvm
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f
checksum '/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu =
x86_64, kernel = (null), initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
febootstrap-supermin-helper: failed to find a suitable kernel.
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
febootstrap use, you shouldn't boot the Xen guest with it).
libguestfs: error: cannot find any suitable libguestfs supermin,
fixed
or old-style appliance on LIBGUESTFS_PATH (search
path: /usr/lib64/guestfs)
libguestfs-test-tool: failed to launch appliance
libguestfs: closing guestfs handle 0x69b2d0 (state 0)
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 3:33 PM
To: Fabian Deutsch
Cc: Исаев Виталий Анатольевич; Itamar Heim;
libguestfs@redhat.com<mailto:libguestfs@redhat.com>;
> fdeutsch@redhat.com<mailto:fdeutsch@redhat.com Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the
RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 12:14:24PM +0100, Fabian Deutsch wrote:
> Am Freitag, den 22.11.2013, 10:29 +0000 schrieb Исаев Виталий
> Анатольевич:
> > Thanks a lot. Yes, we have a Support and we will ask them
to help
with this bug.
> > How do you think, maybe we can hack this issue quickly
just
putting the kernel file (desired by libguestfs) manually to some
directory on the RHEV-H file system? /boot and /lib/modules do not
contain kernels on RHEV-H.
> Hey,
> as you said, a workaround is to link the kernel into the right
place,
> e.g.:
> $ ln -s /dev/.initramfs/live/vmlinuz0 /boot/vmlinuz-$(uname -r)
Does libguestfs-test-tool run after this? (I don't have an
ovirt-node
instance). I would have thought that /lib/modules/... would need to
be in place also.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones virt-p2v converts physical machines
to virtual machines. Boot with a live CD or over the network (PXE)
and turn machines into KVM guests.
6:28 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 12:04:51PM +0000, Исаев Виталий Анатольевич wrote:
Thanks to all. Symbolic link to vmlinuz image is a solution to my
problem:
Actually we came up with another possible way. Not tested, but if it
works, then it has the advantage of not needing root or any permanent
changes to the filesystem:
(1) Delete the symlink in /boot.
(2) Set this environment variable instead:
export FEBOOTSTRAP_KERNEL=/dev/.initramfs/live/isolinux/vmlinuz0
(3) Run libguestfs-test-tool to see if it works.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
8:02 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
Rich, this wasn't operational.
First of all, the image on my version of RHEV-H is kept in other directory. So I did
that:
1. $ export FEBOOTSTRAP_KERNEL=/dev/.initramfs/live/vmlinuz0
2. $ echo $FEBOOTSTRAP_KERNEL
/dev/.initramfs/live/vmlinuz0
3. $ libguestfs-test-tool
************************************************************
* IMPORTANT NOTICE
*
* When reporting bugs, include the COMPLETE, UNEDITED
* output below in your bug report.
*
************************************************************
===== Test starts here =====
FEBOOTSTRAP_KERNEL=/dev/.initramfs/live/vmlinuz0
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
library version: 1.16.34rhel=6,release=2.el6
guestfs_get_append: (null)
guestfs_get_attach_method: appliance
guestfs_get_autosync: 1
guestfs_get_direct: 0
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /usr/lib64/guestfs
guestfs_get_pgroup: 0
guestfs_get_qemu: /usr/libexec/qemu-kvm
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum
'/usr/lib64/guestfs/supermin.d' x86_64
supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null),
initrd = (null), appliance = (null)
supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
febootstrap-supermin-helper: using environment variable(s) FEBOOTSTRAP_* to
select kernel /dev/.initramfs/live/vmlinuz0
febootstrap-supermin-helper: cannot guess module path.
Set $FEBOOTSTRAP_MODULES to the modules directory corresponding to
kernel /dev/.initramfs/live/vmlinuz0, or unset $FEBOOTSTRAP_KERNEL to autoselect a
kernel.
libguestfs: error: cannot find any suitable libguestfs supermin, fixed or old-style
appliance on LIBGUESTFS_PATH (search path: /usr/lib64/guestfs)
libguestfs-test-tool: failed to launch appliance
libguestfs: closing guestfs handle 0xf04260 (state 0)
Виталий Исаев
Инженер-программист
Группа разработки и внедрения ПСЗИ
Департамент информационной безопасности
ОАО «Финтех»
-----Original Message-----
From: Richard W.M. Jones [mailto:rjones@redhat.com]
Sent: Friday, November 22, 2013 4:30 PM
To: Исаев Виталий Анатольевич
Cc: Fabian Deutsch; libguestfs(a)redhat.com; Itamar Heim (iheim(a)redhat.com)
Subject: Re: HA: [Libguestfs] Accessing iSCSI disc images from the RHEV Manager using
libguestfs
On Fri, Nov 22, 2013 at 12:04:51PM +0000, Исаев Виталий Анатольевич wrote:
Thanks to all. Symbolic link to vmlinuz image is a solution to my
problem:
Actually we came up with another possible way. Not tested, but if it works, then it has
the advantage of not needing root or any permanent changes to the filesystem:
(1) Delete the symlink in /boot.
(2) Set this environment variable instead:
export FEBOOTSTRAP_KERNEL=/dev/.initramfs/live/isolinux/vmlinuz0
(3) Run libguestfs-test-tool to see if it works.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora
Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over
100 libraries supported.
http://fedoraproject.org/wiki/MinGW
8:33 a.m.
New subject: HA: Accessing iSCSI disc images from the RHEV Manager using libguestfs
On Fri, Nov 22, 2013 at 02:02:17PM +0000, Исаев Виталий Анатольевич wrote:
select kernel /dev/.initramfs/live/vmlinuz0
febootstrap-supermin-helper: cannot guess module path.
Thanks, I can see why that doesn't work. It's another bug unfortunately:
https://bugzilla.redhat.com/show_bug.cgi?id=1033632
However at least the symlink workaround works for now.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2:56 a.m.
On Thu, Nov 21, 2013 at 06:09:57PM +0200, Itamar Heim wrote:
i may be missing something, but wouldn't vdsm hooks be a better
fit:
http://www.ovirt.org/VDSM-Hooks
for example, I think the "checkimages" one would cover what you are
trying to do already?
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;
It seems like this could work. checkImage() could be replaced
with a function that called libguestfs code:
http://libguestfs.org/guestfs-python.3.html#example-2:-inspect-a-virtual-...
(Of course I have not tried it ...)
Rich.
--
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
3999
days inactive
4000
days old
26 comments
4 participants
participants (4)
-
Fabian Deutsch -
Itamar Heim -
Richard W.M. Jones -
Исаев Виталий Анатольевич