Accessing iSCSI disc images from the RHEV Manager using libguestfs
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, Виталий Исаев Инженер-программист Группа разработки и внедрения ПСЗИ Департамент информационной безопасности ОАО <Финтех>
[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
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@ovirt.org.
________________________________________ От: Itamar Heim [iheim@redhat.com] Отправлено: 21 ноября 2013 г. 20:10 Кому: Richard W.M. Jones; Исаев Виталий Анатольевич Копия: libguestfs@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@ovirt.org.
Thank you for your attention and advises. Vitaly
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@ovirt.org.
Thank you for your attention and advises. Vitaly
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@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@ovirt.org.
Thank you for your attention and advises. Vitaly
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@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@ovirt.org.
Thank you for your attention and advises. Vitaly
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
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@ovirt.org, then it won't be an issue and you won't need custom hooks, etc.
[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
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@redhat.com; fdeutsch@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
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
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@redhat.com; fdeutsch@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
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
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@redhat.com; fdeutsch@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
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
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
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@redhat.com; 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. http://libguestfs.org/virt-v2v
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
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@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
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
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@redhat.com; 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.
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@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@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@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@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@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.
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
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@redhat.com; Itamar Heim (iheim@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
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
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-mac... (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
participants (4)
-
Fabian Deutsch -
Itamar Heim -
Richard W.M. Jones -
Исаев Виталий Анатольевич