From bohai at huawei.com Tue Aug 6 03:20:01 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Tue, 6 Aug 2013 03:20:01 +0000 Subject: [node-devel] about collectd in ovirt-node Message-ID: <98B730463BF8F84A885ABF3A8F61495165F56C2B@SZXEMA501-MBS.china.huawei.com> Hi everyone, In lateset ovirt-node, I found after a weeks passwd, the /var/log/ become no space. The reason is the messages file to occupy too many space. In messages file, I found a lot of the below info: "Filter subsystem:Built-in target` write ': Dispatching value to all write plugins failed with status 2 (ENOENT). Most likely this means you didn't load any write plugins". I googled the message, and the reason is that collect's write plugins is not configured. Whether it's better to disable collectd service default after install before we configure it to avoid the problem. Best regards to you. Ricky From mburns at redhat.com Tue Aug 6 13:55:41 2013 From: mburns at redhat.com (Mike Burns) Date: Tue, 6 Aug 2013 09:55:41 -0400 (EDT) Subject: [node-devel] oVirt Node weekly meeting Message-ID: <974308582.13298334.1375797341817.JavaMail.root@zmail17.collab.prod.int.phx2.redhat.com> A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 1860 bytes Desc: not available URL: From fabiand at redhat.com Wed Aug 7 09:38:02 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Wed, 07 Aug 2013 11:38:02 +0200 Subject: [node-devel] about collectd in ovirt-node In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F56C2B@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495165F56C2B@SZXEMA501-MBS.china.huawei.com> Message-ID: <1375868282.3535.1.camel@fdeutsch-laptop.local> Am Dienstag, den 06.08.2013, 03:20 +0000 schrieb Bohai (ricky): > Hi everyone, > > In lateset ovirt-node, I found after a weeks passwd, the /var/log/ become no space. > The reason is the messages file to occupy too many space. > > In messages file, I found a lot of the below info: > "Filter subsystem:Built-in target` write ': Dispatching value to all write plugins failed with > status 2 (ENOENT). Most likely this means you didn't load any write plugins". > > I googled the message, and the reason is that collect's write plugins is not configured. Yep - that's an annoying bug and we've actually got a bug for it: https://bugzilla.redhat.com/show_bug.cgi?id=908270 > Whether it's better to disable collectd service default after install before we configure it to avoid the problem. Enabling or disabling a service is currently not possible at runtime. Only during the image build process. But there are ideas how to solve this, just not yet implemented. - fabian > Best regards to you. > Ricky > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From fabiand at redhat.com Wed Aug 7 09:40:11 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Wed, 07 Aug 2013 11:40:11 +0200 Subject: [node-devel] about the virtual machine define XML file's persistence In-Reply-To: <98B730463BF8F84A885ABF3A8F61495158136BBD@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495158136BBD@SZXEMA501-MBS.china.huawei.com> Message-ID: <1375868411.3535.3.camel@fdeutsch-laptop.local> Am Mittwoch, den 31.07.2013, 04:10 +0000 schrieb Bohai (ricky): > Hi, > > I have a question about the virtual machine's define XML's persistence. > > As we know, if we use "virsh define" to define a virtual machine, libvirt will put the XML to > the path "/etc/libvirt/qemu". > > Normal case, even the system is rebooted, the XML file still exist. > But in the ovirt-node case , because of the system is stateless, if we reboot the system, > the defined virtual machine XML file will disappear. > > How to solve the problem, any hint? > Or this issue should be considered and solved in the upper level(Like vdsm? Or ovirt-engine?). > Or customize the libvirt to make it to put the XML to a persist path(like /config or /data?) You can use the persist command on a shell to persist (nearly) all files on the filesystem. The persist command is the way to store changes on a writable filesystem. The changed files are then bind-mounted during the boot process to the correct location in the root-fs. - fabian > I apologize if I am missing something very obvious. > > Best regards to you. > Ricky > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From fabiand at redhat.com Wed Aug 7 13:28:19 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Wed, 07 Aug 2013 15:28:19 +0200 Subject: [node-devel] about gptsync command in ovirt-node In-Reply-To: <51F10F4B.7020209@redhat.com> References: <98B730463BF8F84A885ABF3A8F6149515778FABA@szxeml523-mbs.china.huawei.com> <51F10F4B.7020209@redhat.com> Message-ID: <1375882099.3535.4.camel@fdeutsch-laptop.local> Am Donnerstag, den 25.07.2013, 07:43 -0400 schrieb Mike Burns: > On 07/24/2013 07:10 AM, Bohai (ricky) wrote: > > Hi, > > > > I found in ovirt-node setup code "gptsync" command is used. > > But in fact there is no "gptsync" in the ovirt-node system. > > > > Whether it's a risk for some problem or not? > > > > 409 def create_hostvg(self): > > > > 454 # sync GPT to the legacy MBR partitions > > 455 if ("OVIRT_INSTALL_ROOT" in _functions.OVIRT_VARS and > > 456 _functions.OVIRT_VARS["OVIRT_INSTALL_ROOT"] == "y"): > > 457 if self.LABEL_TYPE == "gpt": > > 458 logger.info("Running gptsync to create legacy mbr") > > 459 _functions.system("gptsync \"" + \ > > 460 self.ROOTDRIVE + "\"") > > I'm guessing it's a bug, but I'll defer to Joey on this. According to the anaconda devs (which packaged gptsync) gptsync is not needde anymore, b/c parted can write the correct partition tables now. gptsync is therefor no longer packaged. - fabian > Mike > > > > > Best regards to you. > > Ricky > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From fabiand at redhat.com Tue Aug 13 16:03:43 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 13 Aug 2013 18:03:43 +0200 Subject: [node-devel] oVirt Node Weekly Meeting Minutes -- 2013-08-13 Message-ID: <1376409823.28718.0.camel@fdeutsch-laptop.local> Minutes: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-13-14.02.html Minutes (text): http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-13-14.02.txt Log: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-13-14.02.log.html =================== #ovirt: Node Weekly =================== Meeting started by fabiand at 14:02:50 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-13-14.02.log.html . Meeting summary --------------- * 3.0 respin (fabiand, 14:04:53) * plan is to do a snapshot build today or VDSM based on the current master (fabiand, 14:07:32) * Plan to backport patches to 3.0 later on .. (fabiand, 14:09:00) Meeting ended at 14:15:04 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * fabiand (30) * apuimedo (9) * jboggs (6) * rbarry (4) * ovirtbot (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From bohai at huawei.com Thu Aug 15 07:13:24 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Thu, 15 Aug 2013 07:13:24 +0000 Subject: [node-devel] about boot time of ovirt-node Message-ID: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> Hi all, In the use of ovirt-node , I found a strange thing. Ovirt-node system boots more faster in a virtual machine than a real machine. (Because of no enough real machine, sometimes I use virtual machine to test the setup and install function. And the real machine is absolutely more power than the real machine.) I don't to know why and how to find the reason about it. Or whether it's a problem of ovirt-node? Any help or hint is welcome. Best regards to you. Ricky From bohai at huawei.com Thu Aug 15 07:38:58 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Thu, 15 Aug 2013 07:38:58 +0000 Subject: [node-devel] about boot time of ovirt-node Message-ID: <98B730463BF8F84A885ABF3A8F61495165F6560A@SZXEMA501-MBS.china.huawei.com> > -----Original Message----- > From: Bohai (ricky) > Sent: Thursday, August 15, 2013 3:13 PM > To: 'node-devel at ovirt.org' > Cc: Luohao (A); Haofeng; 'boh.ricky at gmail.com' > Subject: about boot time of ovirt-node > > Hi all, > > In the use of ovirt-node , I found a strange thing. > Ovirt-node system boots more faster in a virtual machine than a real machine. > (Because of no enough real machine, sometimes I use virtual machine > to test the setup and install function. And the real machine is absolutely more > power > than the real machine.) Sorry, it's a typo, here is virtual machine. > > I don't to know why and how to find the reason about it. > Or whether it's a problem of ovirt-node? > > Any help or hint is welcome. > > Best regards to you. > Ricky From fabiand at redhat.com Thu Aug 15 09:22:32 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 15 Aug 2013 11:22:32 +0200 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> Message-ID: <1376558552.2651.1.camel@fdeutsch-laptop.local> Am Donnerstag, den 15.08.2013, 07:13 +0000 schrieb Bohai (ricky): > Hi all, > > In the use of ovirt-node , I found a strange thing. > Ovirt-node system boots more faster in a virtual machine than a real machine. > (Because of no enough real machine, sometimes I use virtual machine > to test the setup and install function. And the real machine is absolutely more power > than the real machine.) > > I don't to know why and how to find the reason about it. > Or whether it's a problem of ovirt-node? I suppose you mean the OS part of the boot process? So not including POST and other bios related stuff. On the Fedora based node you could run a systemd-analyze to find out what service is taking how much time. Greetings fabian > Any help or hint is welcome. > > Best regards to you. > Ricky > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From bohai at huawei.com Fri Aug 16 02:23:43 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Fri, 16 Aug 2013 02:23:43 +0000 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <1376558552.2651.1.camel@fdeutsch-laptop.local> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> <1376558552.2651.1.camel@fdeutsch-laptop.local> Message-ID: <98B730463BF8F84A885ABF3A8F61495165F660DD@SZXEMA501-MBS.china.huawei.com> > -----Original Message----- > From: Fabian Deutsch [mailto:fabiand at redhat.com] > Sent: Thursday, August 15, 2013 5:23 PM > To: Bohai (ricky) > Cc: node-devel at ovirt.org; Luohao (A); Haofeng; boh.ricky at gmail.com > Subject: Re: [node-devel] about boot time of ovirt-node > > Am Donnerstag, den 15.08.2013, 07:13 +0000 schrieb Bohai (ricky): > > Hi all, > > > > In the use of ovirt-node , I found a strange thing. > > Ovirt-node system boots more faster in a virtual machine than a real > machine. > > (Because of no enough real machine, sometimes I use virtual machine > > to test the setup and install function. And the real machine is absolutely more > power > > than the real machine.) > > > > I don't to know why and how to find the reason about it. > > Or whether it's a problem of ovirt-node? > > I suppose you mean the OS part of the boot process? So not including > POST and other bios related stuff. > On the Fedora based node you could run a systemd-analyze to find out > what service is taking how much time. > Thank you for your answer. I will try it to find the reason. > Greetings > fabian > > > Any help or hint is welcome. > > > > Best regards to you. > > Ricky > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > From wenyi at linux.vnet.ibm.com Fri Aug 16 03:06:04 2013 From: wenyi at linux.vnet.ibm.com (Wenyi Gao) Date: Fri, 16 Aug 2013 11:06:04 +0800 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> Message-ID: <520D971C.3010100@linux.vnet.ibm.com> According to my understanding, physical machines have many hardware devices, which takes OS some extra time to detect and initialize the hardware device. While we usually run the VM with much less hardware devices than physical machine, which can save some time to boot up. Best regards Wenyi Gao On 2013-08-15 15:13, Bohai (ricky) wrote: > Hi all, > > In the use of ovirt-node , I found a strange thing. > Ovirt-node system boots more faster in a virtual machine than a real machine. > (Because of no enough real machine, sometimes I use virtual machine > to test the setup and install function. And the real machine is absolutely more power > than the real machine.) > > I don't to know why and how to find the reason about it. > Or whether it's a problem of ovirt-node? > > Any help or hint is welcome. > > Best regards to you. > Ricky > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > From bohai at huawei.com Fri Aug 16 07:00:03 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Fri, 16 Aug 2013 07:00:03 +0000 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <520D971C.3010100@linux.vnet.ibm.com> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> <520D971C.3010100@linux.vnet.ibm.com> Message-ID: <98B730463BF8F84A885ABF3A8F61495165F66173@SZXEMA501-MBS.china.huawei.com> Thanks for your time and your answer. > -----Original Message----- > From: node-devel-bounces at ovirt.org [mailto:node-devel-bounces at ovirt.org] > On Behalf Of Wenyi Gao > Sent: Friday, August 16, 2013 11:06 AM > To: node-devel at ovirt.org > Subject: Re: [node-devel] about boot time of ovirt-node > > > According to my understanding, physical machines have many hardware > devices, which takes OS some extra time to detect and initialize the > hardware device. > While we usually run the VM with much less hardware devices than > physical machine, which can save some time to boot up. > Maybe it's a possible reason. But in fact, in the same real machine, I had ever run the fedora, ovirt-node(last year's old version). Their boot time seem more fewer than current version. I send the mail mainly for two reasons: 1. to got the help to find the reason 2. to know whether any other people encounter the same problem > Best regards > Wenyi Gao > > > On 2013-08-15 15:13, Bohai (ricky) wrote: > > Hi all, > > > > In the use of ovirt-node , I found a strange thing. > > Ovirt-node system boots more faster in a virtual machine than a real > machine. > > (Because of no enough real machine, sometimes I use virtual machine > > to test the setup and install function. And the real machine is absolutely more > power > > than the real machine.) > > > > I don't to know why and how to find the reason about it. > > Or whether it's a problem of ovirt-node? > > > > Any help or hint is welcome. > > > > Best regards to you. > > Ricky > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From bohai at huawei.com Fri Aug 16 07:58:21 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Fri, 16 Aug 2013 07:58:21 +0000 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <1376558552.2651.1.camel@fdeutsch-laptop.local> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> <1376558552.2651.1.camel@fdeutsch-laptop.local> Message-ID: <98B730463BF8F84A885ABF3A8F61495165F661EF@SZXEMA501-MBS.china.huawei.com> Hi Fabian, As your hint , I use the systemd-analyze to get the machine boot time as below: real machine: Startup finished in 1.657s (kernel) + 34.576s (initrd) + 38.054s (userspace) = 1min 14.288s virtual machine: Startup finished in 1.382s (kernel) + 2.624s (initrd) + 37.547s (userspace) = 41.554s The main difference is about initrd's load time. And i found a similar problem's discuss post in the opensuse community. Link: http://lists.opensuse.org/opensuse-factory/2013-03/msg00177.html Summary from the post: " With grub2, it loads in 2-3 seconds on an HP dv2815 laptop with a modest AMD Turion CPU at 2 GHz. The difference might be grub2, or it might be due to poor performance for an i7 running in 8686-compatibility mode. I doubt that Intel spent much time optimizing those operations. " > -----Original Message----- > From: Fabian Deutsch [mailto:fabiand at redhat.com] > Sent: Thursday, August 15, 2013 5:23 PM > To: Bohai (ricky) > Cc: node-devel at ovirt.org; Luohao (A); Haofeng; boh.ricky at gmail.com > Subject: Re: [node-devel] about boot time of ovirt-node > > Am Donnerstag, den 15.08.2013, 07:13 +0000 schrieb Bohai (ricky): > > Hi all, > > > > In the use of ovirt-node , I found a strange thing. > > Ovirt-node system boots more faster in a virtual machine than a real > machine. > > (Because of no enough real machine, sometimes I use virtual machine > > to test the setup and install function. And the real machine is absolutely more > power > > than the real machine.) > > > > I don't to know why and how to find the reason about it. > > Or whether it's a problem of ovirt-node? > > I suppose you mean the OS part of the boot process? So not including > POST and other bios related stuff. > On the Fedora based node you could run a systemd-analyze to find out > what service is taking how much time. > > Greetings > fabian > > > Any help or hint is welcome. > > > > Best regards to you. > > Ricky > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > From fabiand at redhat.com Fri Aug 16 09:16:05 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Fri, 16 Aug 2013 11:16:05 +0200 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F661EF@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> <1376558552.2651.1.camel@fdeutsch-laptop.local> <98B730463BF8F84A885ABF3A8F61495165F661EF@SZXEMA501-MBS.china.huawei.com> Message-ID: <1376644565.2681.2.camel@fdeutsch-laptop.local> Am Freitag, den 16.08.2013, 07:58 +0000 schrieb Bohai (ricky): > Hi Fabian, > > As your hint , I use the systemd-analyze to get the machine boot time as below: > > real machine: > Startup finished in 1.657s (kernel) + 34.576s (initrd) + 38.054s (userspace) = 1min 14.288s > virtual machine: > Startup finished in 1.382s (kernel) + 2.624s (initrd) + 37.547s (userspace) = 41.554s > > The main difference is about initrd's load time. You can add rd.debug and/or rd.udev.debug to the cmdline when booting. In that case dracut will log to either journald (if systemd is used within dracut) or to /run/initramfs/init.log. I'm curious what dracut is taking so long .. - fabian > And i found a similar problem's discuss post in the opensuse community. > Link: > http://lists.opensuse.org/opensuse-factory/2013-03/msg00177.html > > Summary from the post: > " > With grub2, it loads in 2-3 seconds on an HP dv2815 laptop with a modest > AMD Turion CPU at 2 GHz. > > The difference might be grub2, or it might be due to poor performance > for an i7 running in 8686-compatibility mode. I doubt that Intel spent > much time optimizing those operations. > " > > > > -----Original Message----- > > From: Fabian Deutsch [mailto:fabiand at redhat.com] > > Sent: Thursday, August 15, 2013 5:23 PM > > To: Bohai (ricky) > > Cc: node-devel at ovirt.org; Luohao (A); Haofeng; boh.ricky at gmail.com > > Subject: Re: [node-devel] about boot time of ovirt-node > > > > Am Donnerstag, den 15.08.2013, 07:13 +0000 schrieb Bohai (ricky): > > > Hi all, > > > > > > In the use of ovirt-node , I found a strange thing. > > > Ovirt-node system boots more faster in a virtual machine than a real > > machine. > > > (Because of no enough real machine, sometimes I use virtual machine > > > to test the setup and install function. And the real machine is absolutely more > > power > > > than the real machine.) > > > > > > I don't to know why and how to find the reason about it. > > > Or whether it's a problem of ovirt-node? > > > > I suppose you mean the OS part of the boot process? So not including > > POST and other bios related stuff. > > On the Fedora based node you could run a systemd-analyze to find out > > what service is taking how much time. > > > > Greetings > > fabian > > > > > Any help or hint is welcome. > > > > > > Best regards to you. > > > Ricky > > > > > > _______________________________________________ > > > node-devel mailing list > > > node-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From fabiand at redhat.com Fri Aug 16 09:17:37 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Fri, 16 Aug 2013 11:17:37 +0200 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <1376644565.2681.2.camel@fdeutsch-laptop.local> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> <1376558552.2651.1.camel@fdeutsch-laptop.local> <98B730463BF8F84A885ABF3A8F61495165F661EF@SZXEMA501-MBS.china.huawei.com> <1376644565.2681.2.camel@fdeutsch-laptop.local> Message-ID: <1376644657.2681.3.camel@fdeutsch-laptop.local> Am Freitag, den 16.08.2013, 11:16 +0200 schrieb Fabian Deutsch: > Am Freitag, den 16.08.2013, 07:58 +0000 schrieb Bohai (ricky): > > Hi Fabian, > > > > As your hint , I use the systemd-analyze to get the machine boot time as below: > > > > real machine: > > Startup finished in 1.657s (kernel) + 34.576s (initrd) + 38.054s (userspace) = 1min 14.288s > > virtual machine: > > Startup finished in 1.382s (kernel) + 2.624s (initrd) + 37.547s (userspace) = 41.554s > > > > The main difference is about initrd's load time. > > You can add rd.debug and/or rd.udev.debug to the cmdline when booting. > In that case dracut will log to either journald (if systemd is used > within dracut) or to /run/initramfs/init.log. journalctl -ab can be used to retrieve the logged data - fabian > I'm curious what dracut is taking so long .. > > - fabian > > > And i found a similar problem's discuss post in the opensuse community. > > Link: > > http://lists.opensuse.org/opensuse-factory/2013-03/msg00177.html > > > > Summary from the post: > > " > > With grub2, it loads in 2-3 seconds on an HP dv2815 laptop with a modest > > AMD Turion CPU at 2 GHz. > > > > The difference might be grub2, or it might be due to poor performance > > for an i7 running in 8686-compatibility mode. I doubt that Intel spent > > much time optimizing those operations. > > " > > > > > > > -----Original Message----- > > > From: Fabian Deutsch [mailto:fabiand at redhat.com] > > > Sent: Thursday, August 15, 2013 5:23 PM > > > To: Bohai (ricky) > > > Cc: node-devel at ovirt.org; Luohao (A); Haofeng; boh.ricky at gmail.com > > > Subject: Re: [node-devel] about boot time of ovirt-node > > > > > > Am Donnerstag, den 15.08.2013, 07:13 +0000 schrieb Bohai (ricky): > > > > Hi all, > > > > > > > > In the use of ovirt-node , I found a strange thing. > > > > Ovirt-node system boots more faster in a virtual machine than a real > > > machine. > > > > (Because of no enough real machine, sometimes I use virtual machine > > > > to test the setup and install function. And the real machine is absolutely more > > > power > > > > than the real machine.) > > > > > > > > I don't to know why and how to find the reason about it. > > > > Or whether it's a problem of ovirt-node? > > > > > > I suppose you mean the OS part of the boot process? So not including > > > POST and other bios related stuff. > > > On the Fedora based node you could run a systemd-analyze to find out > > > what service is taking how much time. > > > > > > Greetings > > > fabian > > > > > > > Any help or hint is welcome. > > > > > > > > Best regards to you. > > > > Ricky > > > > > > > > _______________________________________________ > > > > node-devel mailing list > > > > node-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From mburns at redhat.com Tue Aug 20 14:20:46 2013 From: mburns at redhat.com (Mike Burns) Date: Tue, 20 Aug 2013 10:20:46 -0400 Subject: [node-devel] oVirt Node Weekly Meeting Minutes -- 2013-08-20 Message-ID: <52137B3E.9070901@redhat.com> Minutes: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-20-14.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-20-14.00.txt Log: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-20-14.00.log.html ================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by mburns at 14:00:50 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2013/ovirt.2013-08-20-14.00.log.html . Meeting summary --------------- * agenda and roll call (mburns, 14:00:56) * 3.0.1 (mburns, 14:01:44) * 3.1.0 (mburns, 14:01:47) * other topics (mburns, 14:01:53) * 3.0.1 (mburns, 14:01:57) * test iso posted last week (mburns, 14:03:39) * some patches pending for 3.0.1 that need porting to node-3.0 branch (mburns, 14:03:56) * fabiand will have things ready to be posted by tomorrow (afternoon CEST) (mburns, 14:04:27) * fabiand and mburns to discuss patch inclusion in 3.0.1 (mburns, 14:06:31) * rbarry to assist with el6 builds (mburns, 14:06:37) * 3.1.0 (mburns, 14:08:18) * Some things i'd like to tackle in 3.1.0 (mburns, 14:09:01) * break up ovirt-node into more sub-packages like -virt -tui etc for use cases that don't need those pieces of functionality (mburns, 14:10:11) * storage/install module re-write (mburns, 14:10:16) * openvswitch (mburns, 14:10:21) * live plugins (mburns, 14:10:38) * some sort of "here i am, here is what i can do" publishing model (mburns, 14:12:36) * to make registration easier for things like engine (mburns, 14:12:56) * kimchi plugin (mburns, 14:13:06) * think about new features and we can discuss at a later meeting (mburns, 14:15:29) * ACTION: mburns to email node-devel to solicit new feature requests (mburns, 14:15:55) * other topics (mburns, 14:16:29) * there is interest in an ovirt-node based system discovery and provisioning image for use with foreman (mburns, 14:17:16) * they're doing initial investigation (mburns, 14:17:28) * some actions that will be needed: further kickstart work, splitting to more subpackages for specific functionality (tui, virt, etc) (mburns, 14:18:16) * fabiand doing a presentation on test automation with a focus on node at froscon next week (mburns, 14:19:28) Meeting ended at 14:20:22 UTC. Action Items ------------ * mburns to email node-devel to solicit new feature requests Action Items, by person ----------------------- * mburns * mburns to email node-devel to solicit new feature requests * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mburns (51) * fabiand (24) * rbarry (4) * jboggs (4) * ovirtbot (3) * knesenko (1) * eedri_ (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From mburns at redhat.com Tue Aug 20 14:26:25 2013 From: mburns at redhat.com (Mike Burns) Date: Tue, 20 Aug 2013 10:26:25 -0400 Subject: [node-devel] oVirt Node feature requests for 3.1 release Message-ID: <52137C91.1070607@redhat.com> Hi all, We're going into our initial planning cycle for oVirt Node 3.1 and are looking for features that are interesting to people. There are a number of ideas that were proposed on our weekly meeting that are listed below. If you would really like to see one or more of the features below, please let us know. If you have an idea for another feature, please also reply with a short abstract for that feature. Thanks Mike * Package Refactoring -- make it easier to build custom images for different use cases without pulling in unnecessary functionality (I.E., virt capabilities when acting as a storage node only). * re-writes of the storage and installer modules for easier testing * openvswitch support * live install of plugins (install on a running system, possibly with push model) * Some sort of announcement model where we identify who we are and what we can do to a system (for registration purposes) * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone use cases From mburns at redhat.com Tue Aug 20 14:35:53 2013 From: mburns at redhat.com (Mike Burns) Date: Tue, 20 Aug 2013 10:35:53 -0400 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <52137C91.1070607@redhat.com> References: <52137C91.1070607@redhat.com> Message-ID: <52137EC9.2040904@redhat.com> On 08/20/2013 10:26 AM, Mike Burns wrote: > Hi all, > > We're going into our initial planning cycle for oVirt Node 3.1 and are > looking for features that are interesting to people. There are a number > of ideas that were proposed on our weekly meeting that are listed below. > If you would really like to see one or more of the features below, > please let us know. If you have an idea for another feature, please > also reply with a short abstract for that feature. > > Thanks > > Mike > > * Package Refactoring -- make it easier to build custom images for > different use cases without pulling in unnecessary functionality (I.E., > virt capabilities when acting as a storage node only). > * re-writes of the storage and installer modules for easier testing > * openvswitch support > * live install of plugins (install on a running system, possibly with > push model) > * Some sort of announcement model where we identify who we are and what > we can do to a system (for registration purposes) > * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone > use cases * investigate LiveMedia and oz for building ovirt-node > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From fabiand at redhat.com Tue Aug 20 16:12:16 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 20 Aug 2013 18:12:16 +0200 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <52137EC9.2040904@redhat.com> References: <52137C91.1070607@redhat.com> <52137EC9.2040904@redhat.com> Message-ID: <1377015136.10356.0.camel@fdeutsch-laptop.local> Am Dienstag, den 20.08.2013, 10:35 -0400 schrieb Mike Burns: > > > * Package Refactoring -- make it easier to build custom images for > > different use cases without pulling in unnecessary functionality > (I.E., > > virt capabilities when acting as a storage node only). > > * re-writes of the storage and installer modules for easier testing > > * openvswitch support > > * live install of plugins (install on a running system, possibly > with > > push model) > > * Some sort of announcement model where we identify who we are and > what > > we can do to a system (for registration purposes) > > * kimchi plugin (http://github.com/kimchi-project/kimchi) for > standalone > > use cases > > * investigate LiveMedia and oz for building ovirt-node * plugin for standalone/virt-manager mode. To have local/private instances to be used with virt-manager From mburns at redhat.com Tue Aug 20 16:13:32 2013 From: mburns at redhat.com (Mike Burns) Date: Tue, 20 Aug 2013 12:13:32 -0400 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <1377015136.10356.0.camel@fdeutsch-laptop.local> References: <52137C91.1070607@redhat.com> <52137EC9.2040904@redhat.com> <1377015136.10356.0.camel@fdeutsch-laptop.local> Message-ID: <521395AC.9050809@redhat.com> On 08/20/2013 12:12 PM, Fabian Deutsch wrote: > Am Dienstag, den 20.08.2013, 10:35 -0400 schrieb Mike Burns: >> >>> * Package Refactoring -- make it easier to build custom images for >>> different use cases without pulling in unnecessary functionality >> (I.E., >>> virt capabilities when acting as a storage node only). >>> * re-writes of the storage and installer modules for easier testing >>> * openvswitch support >>> * live install of plugins (install on a running system, possibly >> with >>> push model) >>> * Some sort of announcement model where we identify who we are and >> what >>> we can do to a system (for registration purposes) >>> * kimchi plugin (http://github.com/kimchi-project/kimchi) for >> standalone >>> use cases >> >> * investigate LiveMedia and oz for building ovirt-node > > * plugin for standalone/virt-manager mode. To have local/private > instances to be used with virt-manager Check out kimchi, that is basically what it does. It's not virt-manager, but a somewhat thinner, cleaner interface. > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > From wenyi at linux.vnet.ibm.com Wed Aug 21 00:54:07 2013 From: wenyi at linux.vnet.ibm.com (Wenyi Gao) Date: Wed, 21 Aug 2013 08:54:07 +0800 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <52137C91.1070607@redhat.com> References: <52137C91.1070607@redhat.com> Message-ID: <52140FAF.3000802@linux.vnet.ibm.com> On 2013-08-20 22:26, Mike Burns wrote: > Hi all, > > We're going into our initial planning cycle for oVirt Node 3.1 and are > looking for features that are interesting to people. There are a > number of ideas that were proposed on our weekly meeting that are > listed below. If you would really like to see one or more of the > features below, please let us know. If you have an idea for another > feature, please also reply with a short abstract for that feature. > > Thanks > > Mike > > * Package Refactoring -- make it easier to build custom images for > different use cases without pulling in unnecessary functionality > (I.E., virt capabilities when acting as a storage node only). +1 > * re-writes of the storage and installer modules for easier testing +1 > * openvswitch support +1 > * live install of plugins (install on a running system, possibly with > push model) > * Some sort of announcement model where we identify who we are and > what we can do to a system (for registration purposes) > * kimchi plugin (http://github.com/kimchi-project/kimchi) for > standalone use cases > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > Best regards Wenyi Gao From bohai at huawei.com Wed Aug 21 06:41:10 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Wed, 21 Aug 2013 06:41:10 +0000 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <52137C91.1070607@redhat.com> References: <52137C91.1070607@redhat.com> Message-ID: <98B730463BF8F84A885ABF3A8F61495165F69024@SZXEMA501-MBS.china.huawei.com> > -----Original Message----- > From: node-devel-bounces at ovirt.org [mailto:node-devel-bounces at ovirt.org] > On Behalf Of Mike Burns > Sent: Tuesday, August 20, 2013 10:26 PM > To: node-devel; arch > Subject: [node-devel] oVirt Node feature requests for 3.1 release > > Hi all, > > We're going into our initial planning cycle for oVirt Node 3.1 and are > looking for features that are interesting to people. There are a number > of ideas that were proposed on our weekly meeting that are listed below. > If you would really like to see one or more of the features below, > please let us know. If you have an idea for another feature, please > also reply with a short abstract for that feature. > > Thanks > > Mike > > * Package Refactoring -- make it easier to build custom images for > different use cases without pulling in unnecessary functionality (I.E., > virt capabilities when acting as a storage node only). > * re-writes of the storage and installer modules for easier testing +1 > * openvswitch support +1 > * live install of plugins (install on a running system, possibly with > push model) > * Some sort of announcement model where we identify who we are and what > we can do to a system (for registration purposes) > * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone > use cases > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From bohai at huawei.com Wed Aug 21 08:45:44 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Wed, 21 Aug 2013 08:45:44 +0000 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <1376644657.2681.3.camel@fdeutsch-laptop.local> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> <1376558552.2651.1.camel@fdeutsch-laptop.local> <98B730463BF8F84A885ABF3A8F61495165F661EF@SZXEMA501-MBS.china.huawei.com> <1376644565.2681.2.camel@fdeutsch-laptop.local> <1376644657.2681.3.camel@fdeutsch-laptop.local> Message-ID: <98B730463BF8F84A885ABF3A8F61495165F692A1@SZXEMA501-MBS.china.huawei.com> Hi, Fabian Thanks for your answer and your time. I try to get the log as you said. The below is the summary of journalctl's log . Maybe the NIC device and NIC device's process are the reason why initrd's slow. About the detail, please reference the attachments. -------------------------------summary about journalctl----------------------------------- Aug 21 08:14:47 localhost systemd-udevd[344]: '/sbin/initqueue --settled --onetime --unique /sbin/dmsquash-live-root /dev/dm-3'(err) '/sbin/initqueue at 51(): echo '/sbin/dmsquash-live-root /dev/dm-3'' Aug 21 08:14:59 localhost systemd-journal[196]: Suppressed 402 messages from /system/systemd-udevd.service Aug 21 08:14:59 localhost systemd-udevd[302]: validate module index Aug 21 08:15:02 localhost systemd-udevd[302]: validate module index Aug 21 08:15:05 localhost systemd-udevd[302]: validate module index Aug 21 08:15:08 localhost systemd-udevd[302]: worker [342] /devices/pci0000:00/0000:00:03.0/0000:02:00.1/net/eth0 timeout; kill it Aug 21 08:15:08 localhost systemd-udevd[302]: seq 2637 '/devices/pci0000:00/0000:00:03.0/0000:02:00.1/net/eth0' killed ------------------------------------------------------------------------------------------------------ > -----Original Message----- > From: Fabian Deutsch [mailto:fabiand at redhat.com] > Sent: Friday, August 16, 2013 5:18 PM > To: Bohai (ricky) > Cc: Luohao (A); boh.ricky at gmail.com; Haofeng; node-devel at ovirt.org > Subject: Re: [node-devel] about boot time of ovirt-node > > Am Freitag, den 16.08.2013, 11:16 +0200 schrieb Fabian Deutsch: > > Am Freitag, den 16.08.2013, 07:58 +0000 schrieb Bohai (ricky): > > > Hi Fabian, > > > > > > As your hint , I use the systemd-analyze to get the machine boot time as > below: > > > > > > real machine: > > > Startup finished in 1.657s (kernel) + 34.576s (initrd) + 38.054s (userspace) = > 1min 14.288s > > > virtual machine: > > > Startup finished in 1.382s (kernel) + 2.624s (initrd) + 37.547s (userspace) = > 41.554s > > > > > > The main difference is about initrd's load time. > > > > You can add rd.debug and/or rd.udev.debug to the cmdline when booting. > > In that case dracut will log to either journald (if systemd is used > > within dracut) or to /run/initramfs/init.log. > > journalctl -ab can be used to retrieve the logged data > > - fabian > > > I'm curious what dracut is taking so long .. > > > > - fabian > > > > > And i found a similar problem's discuss post in the opensuse community. > > > Link: > > > http://lists.opensuse.org/opensuse-factory/2013-03/msg00177.html > > > > > > Summary from the post: > > > " > > > With grub2, it loads in 2-3 seconds on an HP dv2815 laptop with a modest > > > AMD Turion CPU at 2 GHz. > > > > > > The difference might be grub2, or it might be due to poor performance > > > for an i7 running in 8686-compatibility mode. I doubt that Intel spent > > > much time optimizing those operations. > > > " > > > > > > > > > > -----Original Message----- > > > > From: Fabian Deutsch [mailto:fabiand at redhat.com] > > > > Sent: Thursday, August 15, 2013 5:23 PM > > > > To: Bohai (ricky) > > > > Cc: node-devel at ovirt.org; Luohao (A); Haofeng; boh.ricky at gmail.com > > > > Subject: Re: [node-devel] about boot time of ovirt-node > > > > > > > > Am Donnerstag, den 15.08.2013, 07:13 +0000 schrieb Bohai (ricky): > > > > > Hi all, > > > > > > > > > > In the use of ovirt-node , I found a strange thing. > > > > > Ovirt-node system boots more faster in a virtual machine than a real > > > > machine. > > > > > (Because of no enough real machine, sometimes I use virtual machine > > > > > to test the setup and install function. And the real machine is absolutely > more > > > > power > > > > > than the real machine.) > > > > > > > > > > I don't to know why and how to find the reason about it. > > > > > Or whether it's a problem of ovirt-node? > > > > > > > > I suppose you mean the OS part of the boot process? So not including > > > > POST and other bios related stuff. > > > > On the Fedora based node you could run a systemd-analyze to find out > > > > what service is taking how much time. > > > > > > > > Greetings > > > > fabian > > > > > > > > > Any help or hint is welcome. > > > > > > > > > > Best regards to you. > > > > > Ricky > > > > > > > > > > _______________________________________________ > > > > > node-devel mailing list > > > > > node-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > > > > > > > _______________________________________________ > > > node-devel mailing list > > > node-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: jorunalctl.log Type: application/octet-stream Size: 798196 bytes Desc: jorunalctl.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: systemd.plot Type: application/octet-stream Size: 121637 bytes Desc: systemd.plot URL: From fabiand at redhat.com Thu Aug 22 09:42:28 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 22 Aug 2013 11:42:28 +0200 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <52137C91.1070607@redhat.com> References: <52137C91.1070607@redhat.com> Message-ID: <1377164548.2654.0.camel@fdeutsch-laptop.local> Am Dienstag, den 20.08.2013, 10:26 -0400 schrieb Mike Burns: > Hi all, > > We're going into our initial planning cycle for oVirt Node 3.1 and are > looking for features that are interesting to people. There are a number > of ideas that were proposed on our weekly meeting that are listed below. > If you would really like to see one or more of the features below, > please let us know. If you have an idea for another feature, please > also reply with a short abstract for that feature. > > Thanks > > Mike > > * Package Refactoring -- make it easier to build custom images for > different use cases without pulling in unnecessary functionality (I.E., > virt capabilities when acting as a storage node only). > * re-writes of the storage and installer modules for easier testing > * openvswitch support > * live install of plugins (install on a running system, possibly with > push model) > * Some sort of announcement model where we identify who we are and what > we can do to a system (for registration purposes) > * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone > use cases I've created a feature page for the 3.1 release in the wiki to track the feature requests: http://www.ovirt.org/Node_3.1_release-management I've also added all features from above. - fabian From fabiand at redhat.com Thu Aug 22 10:03:39 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 22 Aug 2013 12:03:39 +0200 Subject: [node-devel] about boot time of ovirt-node In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F692A1@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495165F651E1@SZXEMA501-MBS.china.huawei.com> <1376558552.2651.1.camel@fdeutsch-laptop.local> <98B730463BF8F84A885ABF3A8F61495165F661EF@SZXEMA501-MBS.china.huawei.com> <1376644565.2681.2.camel@fdeutsch-laptop.local> <1376644657.2681.3.camel@fdeutsch-laptop.local> <98B730463BF8F84A885ABF3A8F61495165F692A1@SZXEMA501-MBS.china.huawei.com> Message-ID: <1377165819.2654.4.camel@fdeutsch-laptop.local> Am Mittwoch, den 21.08.2013, 08:45 +0000 schrieb Bohai (ricky): > Hi, Fabian > > Thanks for your answer and your time. > > I try to get the log as you said. > The below is the summary of journalctl's log . > Maybe the NIC device and NIC device's process are the reason why initrd's slow. > About the detail, please reference the attachments. Hey Ricky, the journctl.log gave some insight. It looks like there is much time spend doing all sorts of stuff with udev. > -------------------------------summary about journalctl----------------------------------- > Aug 21 08:14:47 localhost systemd-udevd[344]: '/sbin/initqueue --settled --onetime --unique /sbin/dmsquash-live-root /dev/dm-3'(err) '/sbin/initqueue at 51(): echo '/sbin/dmsquash-live-root /dev/dm-3'' > Aug 21 08:14:59 localhost systemd-journal[196]: Suppressed 402 messages from /system/systemd-udevd.service > Aug 21 08:14:59 localhost systemd-udevd[302]: validate module index > Aug 21 08:15:02 localhost systemd-udevd[302]: validate module index > Aug 21 08:15:05 localhost systemd-udevd[302]: validate module index > Aug 21 08:15:08 localhost systemd-udevd[302]: worker [342] /devices/pci0000:00/0000:00:03.0/0000:02:00.1/net/eth0 timeout; kill it > Aug 21 08:15:08 localhost systemd-udevd[302]: seq 2637 '/devices/pci0000:00/0000:00:03.0/0000:02:00.1/net/eth0' killed > ------------------------------------------------------------------------------------------------------ And yes, this snippet really shows that systemd/udev is waiting for outstanding stuff from devices. I don't fully understand the cmdline, but the presence of --settled indicates that systemd is blocking until all outstandings bits poured in. So them is actually spend on initializing hardware. The udev part should be much quicker in the VM logs. Greetings fabian > > > > > -----Original Message----- > > From: Fabian Deutsch [mailto:fabiand at redhat.com] > > Sent: Friday, August 16, 2013 5:18 PM > > To: Bohai (ricky) > > Cc: Luohao (A); boh.ricky at gmail.com; Haofeng; node-devel at ovirt.org > > Subject: Re: [node-devel] about boot time of ovirt-node > > > > Am Freitag, den 16.08.2013, 11:16 +0200 schrieb Fabian Deutsch: > > > Am Freitag, den 16.08.2013, 07:58 +0000 schrieb Bohai (ricky): > > > > Hi Fabian, > > > > > > > > As your hint , I use the systemd-analyze to get the machine boot time as > > below: > > > > > > > > real machine: > > > > Startup finished in 1.657s (kernel) + 34.576s (initrd) + 38.054s (userspace) = > > 1min 14.288s > > > > virtual machine: > > > > Startup finished in 1.382s (kernel) + 2.624s (initrd) + 37.547s (userspace) = > > 41.554s > > > > > > > > The main difference is about initrd's load time. > > > > > > You can add rd.debug and/or rd.udev.debug to the cmdline when booting. > > > In that case dracut will log to either journald (if systemd is used > > > within dracut) or to /run/initramfs/init.log. > > > > journalctl -ab can be used to retrieve the logged data > > > > - fabian > > > > > I'm curious what dracut is taking so long .. > > > > > > - fabian > > > > > > > And i found a similar problem's discuss post in the opensuse community. > > > > Link: > > > > http://lists.opensuse.org/opensuse-factory/2013-03/msg00177.html > > > > > > > > Summary from the post: > > > > " > > > > With grub2, it loads in 2-3 seconds on an HP dv2815 laptop with a modest > > > > AMD Turion CPU at 2 GHz. > > > > > > > > The difference might be grub2, or it might be due to poor performance > > > > for an i7 running in 8686-compatibility mode. I doubt that Intel spent > > > > much time optimizing those operations. > > > > " > > > > > > > > > > > > > -----Original Message----- > > > > > From: Fabian Deutsch [mailto:fabiand at redhat.com] > > > > > Sent: Thursday, August 15, 2013 5:23 PM > > > > > To: Bohai (ricky) > > > > > Cc: node-devel at ovirt.org; Luohao (A); Haofeng; boh.ricky at gmail.com > > > > > Subject: Re: [node-devel] about boot time of ovirt-node > > > > > > > > > > Am Donnerstag, den 15.08.2013, 07:13 +0000 schrieb Bohai (ricky): > > > > > > Hi all, > > > > > > > > > > > > In the use of ovirt-node , I found a strange thing. > > > > > > Ovirt-node system boots more faster in a virtual machine than a real > > > > > machine. > > > > > > (Because of no enough real machine, sometimes I use virtual machine > > > > > > to test the setup and install function. And the real machine is absolutely > > more > > > > > power > > > > > > than the real machine.) > > > > > > > > > > > > I don't to know why and how to find the reason about it. > > > > > > Or whether it's a problem of ovirt-node? > > > > > > > > > > I suppose you mean the OS part of the boot process? So not including > > > > > POST and other bios related stuff. > > > > > On the Fedora based node you could run a systemd-analyze to find out > > > > > what service is taking how much time. > > > > > > > > > > Greetings > > > > > fabian > > > > > > > > > > > Any help or hint is welcome. > > > > > > > > > > > > Best regards to you. > > > > > > Ricky > > > > > > > > > > > > _______________________________________________ > > > > > > node-devel mailing list > > > > > > node-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > > > > > > > > > > _______________________________________________ > > > > node-devel mailing list > > > > node-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > > > > > > _______________________________________________ > > > node-devel mailing list > > > node-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/node-devel > > > From mburns at redhat.com Thu Aug 22 11:50:53 2013 From: mburns at redhat.com (Mike Burns) Date: Thu, 22 Aug 2013 07:50:53 -0400 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <1377164548.2654.0.camel@fdeutsch-laptop.local> References: <52137C91.1070607@redhat.com> <1377164548.2654.0.camel@fdeutsch-laptop.local> Message-ID: <5215FB1D.1080402@redhat.com> On 08/22/2013 05:42 AM, Fabian Deutsch wrote: > Am Dienstag, den 20.08.2013, 10:26 -0400 schrieb Mike Burns: >> Hi all, >> >> We're going into our initial planning cycle for oVirt Node 3.1 and are >> looking for features that are interesting to people. There are a number >> of ideas that were proposed on our weekly meeting that are listed below. >> If you would really like to see one or more of the features below, >> please let us know. If you have an idea for another feature, please >> also reply with a short abstract for that feature. >> >> Thanks >> >> Mike >> >> * Package Refactoring -- make it easier to build custom images for >> different use cases without pulling in unnecessary functionality (I.E., >> virt capabilities when acting as a storage node only). >> * re-writes of the storage and installer modules for easier testing >> * openvswitch support >> * live install of plugins (install on a running system, possibly with >> push model) >> * Some sort of announcement model where we identify who we are and what >> we can do to a system (for registration purposes) >> * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone >> use cases > > I've created a feature page for the 3.1 release in the wiki to track the > feature requests: > http://www.ovirt.org/Node_3.1_release-management > > I've also added all features from above. Thanks Fabian. > > - fabian > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > From bohai at huawei.com Fri Aug 23 03:22:03 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Fri, 23 Aug 2013 03:22:03 +0000 Subject: [node-devel] Maybe the reason for install failed sometimes Message-ID: <98B730463BF8F84A885ABF3A8F61495165F6C825@SZXEMA501-MBS.china.huawei.com> Hi, I failed to install the ovirt-node. About detail info, please see the summary of ovirt.log at the end of the mail. I read the code, and found the call for subprocess_closefds like below: 1426 def findfs(label): 1427 system("partprobe /dev/mapper/*") 1428 system("udevadm settle") 1429 blkid_cmd = "/sbin/blkid -c /dev/null -l -o device -t LABEL=\"" + label + "\"" 1430 blkid = subprocess_closefds(blkid_cmd, shell=True, stdout=PIPE, stderr=STDOUT) 1431 blkid_output = blkid.stdout.read().strip() 1432 return blkid_output I think when we read the stdout the command has not finished, so the real blkid can't be read. After call of function subprocess_closefds, whether or not we need to wait for process to terminate? For example, to call the "Popen.communicate" to wait the comand finished. There are lots of call for subprocess_closefds like this in ovirt-node codes , I guess maybe they are the reason why install failed sometimes. How do you think about this? --------------------------/tmp/ovirt.log----------------------------------- 301 2013-08-23 01:16:17,938 - DEBUG - install - Trial 1 to find candidate (None) 302 2013-08-23 01:16:19,290 - DEBUG - ovirtfunctions - partprobe 303 2013-08-23 01:16:19,290 - DEBUG - ovirtfunctions - 304 2013-08-23 01:16:19,469 - DEBUG - ovirtfunctions - partprobe /dev/mapper/* 305 2013-08-23 01:16:19,469 - DEBUG - ovirtfunctions - 306 2013-08-23 01:16:19,670 - DEBUG - ovirtfunctions - udevadm settle 307 2013-08-23 01:16:19,670 - DEBUG - ovirtfunctions - 308 2013-08-23 01:16:19,681 - DEBUG - install - Trial 2 to find candidate (RootBackup) 309 2013-08-23 01:16:19,681 - DEBUG - install - Found candidate: RootBackup 310 2013-08-23 01:16:19,719 - DEBUG - ovirtfunctions - partprobe /dev/mapper/* 311 2013-08-23 01:16:19,719 - DEBUG - ovirtfunctions - 312 2013-08-23 01:16:19,845 - DEBUG - ovirtfunctions - udevadm settle 313 2013-08-23 01:16:19,845 - DEBUG - ovirtfunctions - 314 2013-08-23 01:16:20,030 - INFO - install - 315 2013-08-23 01:16:20,030 - INFO - install - 316 2013-08-23 01:16:20,037 - DEBUG - install - Traceback (most recent call last): 317 File "/usr/lib/python2.7/site-packages/ovirtnode/install.py", line 424, in ovirt_boot_setup 318 self.partN = int(self.disk[-1:]) 319 ValueError: invalid literal for int() with base 10: '' ------------------------------------------------------------------------------------ Best regards to you. Ricky From fabiand at redhat.com Fri Aug 23 06:36:38 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Fri, 23 Aug 2013 08:36:38 +0200 Subject: [node-devel] Maybe the reason for install failed sometimes In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F6C825@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495165F6C825@SZXEMA501-MBS.china.huawei.com> Message-ID: <1377239798.2618.10.camel@fdeutsch-laptop.local> Am Freitag, den 23.08.2013, 03:22 +0000 schrieb Bohai (ricky): > Hi, > > I failed to install the ovirt-node. About detail info, please see the summary of ovirt.log > at the end of the mail. > > I read the code, and found the call for subprocess_closefds like below: > 1426 def findfs(label): > 1427 system("partprobe /dev/mapper/*") > 1428 system("udevadm settle") > 1429 blkid_cmd = "/sbin/blkid -c /dev/null -l -o device -t LABEL=\"" + label + "\"" > 1430 blkid = subprocess_closefds(blkid_cmd, shell=True, stdout=PIPE, stderr=STDOUT) > 1431 blkid_output = blkid.stdout.read().strip() > 1432 return blkid_output > > I think when we read the stdout the command has not finished, so the real blkid can't be read. > > After call of function subprocess_closefds, whether or not we need to wait for process to terminate? Hey Ricky, subprocess_closefds is just wrapping subprocess.Popen and adding close_fds=True. subprocess.Popen by default is waiting for the cmd to exit. At least it behaved like this in a small test. > For example, to call the "Popen.communicate" to wait the comand finished. But maybe we should take the warning just above [1] serious. Using proc.stdout.read() can lead to dead-locks, maybe those are the problem. But if we had the problem of dead-locks I'd expect the whole python process to block - but maybe this assumption is wrong. But at least that part of our codebase is targeted with the node-3.1 feature (page has to be created) [2] One idea is to use blivet [3] for the storage stuff, this is a module used by anaconda. Maybe even other parts of anaconda can be used to e.g. handle the grub and uefi stuff. This would mean joint efforts with the anaconda team. Greetings fabian --- [1] http://docs.python.org/2/library/subprocess.html#subprocess.Popen.stdin [2] http://www.ovirt.org/Features/Node/StorageAndInstallerModuleRewrite [3] https://git.fedorahosted.org/git/?p=blivet.git > There are lots of call for subprocess_closefds like this in ovirt-node codes , > I guess maybe they are the reason why install failed sometimes. > > How do you think about this? > > > --------------------------/tmp/ovirt.log----------------------------------- > 301 2013-08-23 01:16:17,938 - DEBUG - install - Trial 1 to find candidate (None) > 302 2013-08-23 01:16:19,290 - DEBUG - ovirtfunctions - partprobe > 303 2013-08-23 01:16:19,290 - DEBUG - ovirtfunctions - > 304 2013-08-23 01:16:19,469 - DEBUG - ovirtfunctions - partprobe /dev/mapper/* > 305 2013-08-23 01:16:19,469 - DEBUG - ovirtfunctions - > 306 2013-08-23 01:16:19,670 - DEBUG - ovirtfunctions - udevadm settle > 307 2013-08-23 01:16:19,670 - DEBUG - ovirtfunctions - > 308 2013-08-23 01:16:19,681 - DEBUG - install - Trial 2 to find candidate (RootBackup) > 309 2013-08-23 01:16:19,681 - DEBUG - install - Found candidate: RootBackup > 310 2013-08-23 01:16:19,719 - DEBUG - ovirtfunctions - partprobe /dev/mapper/* > 311 2013-08-23 01:16:19,719 - DEBUG - ovirtfunctions - > 312 2013-08-23 01:16:19,845 - DEBUG - ovirtfunctions - udevadm settle > 313 2013-08-23 01:16:19,845 - DEBUG - ovirtfunctions - > 314 2013-08-23 01:16:20,030 - INFO - install - > 315 2013-08-23 01:16:20,030 - INFO - install - > 316 2013-08-23 01:16:20,037 - DEBUG - install - Traceback (most recent call last): > 317 File "/usr/lib/python2.7/site-packages/ovirtnode/install.py", line 424, in ovirt_boot_setup > 318 self.partN = int(self.disk[-1:]) > 319 ValueError: invalid literal for int() with base 10: '' > ------------------------------------------------------------------------------------ > > Best regards to you. > Ricky > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From lpeer at redhat.com Sun Aug 25 10:31:29 2013 From: lpeer at redhat.com (Livnat Peer) Date: Sun, 25 Aug 2013 13:31:29 +0300 Subject: [node-devel] oVirt Node feature requests for 3.1 release In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F69024@SZXEMA501-MBS.china.huawei.com> References: <52137C91.1070607@redhat.com> <98B730463BF8F84A885ABF3A8F61495165F69024@SZXEMA501-MBS.china.huawei.com> Message-ID: <5219DD01.2030707@redhat.com> On 08/21/2013 09:41 AM, Bohai (ricky) wrote: > >> -----Original Message----- >> From: node-devel-bounces at ovirt.org [mailto:node-devel-bounces at ovirt.org] >> On Behalf Of Mike Burns >> Sent: Tuesday, August 20, 2013 10:26 PM >> To: node-devel; arch >> Subject: [node-devel] oVirt Node feature requests for 3.1 release >> >> Hi all, >> >> We're going into our initial planning cycle for oVirt Node 3.1 and are >> looking for features that are interesting to people. There are a number >> of ideas that were proposed on our weekly meeting that are listed below. >> If you would really like to see one or more of the features below, >> please let us know. If you have an idea for another feature, please >> also reply with a short abstract for that feature. >> >> Thanks >> >> Mike >> >> * Package Refactoring -- make it easier to build custom images for >> different use cases without pulling in unnecessary functionality (I.E., >> virt capabilities when acting as a storage node only). >> * re-writes of the storage and installer modules for easier testing > +1 > >> * openvswitch support > +1 +1 In addition we added in oVirt 3.3 integration with Neutron that is currently only available on RHEL/fedora based nodes. It would be great if we can look into what are the requirements to support it on oVirt node as well. > >> * live install of plugins (install on a running system, possibly with >> push model) >> * Some sort of announcement model where we identify who we are and what >> we can do to a system (for registration purposes) >> * kimchi plugin (http://github.com/kimchi-project/kimchi) for standalone >> use cases >> _______________________________________________ >> node-devel mailing list >> node-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/node-devel > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > > From bohai at huawei.com Mon Aug 26 02:19:37 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Mon, 26 Aug 2013 02:19:37 +0000 Subject: [node-devel] Maybe the reason for install failed sometimes In-Reply-To: <1377239798.2618.10.camel@fdeutsch-laptop.local> References: <98B730463BF8F84A885ABF3A8F61495165F6C825@SZXEMA501-MBS.china.huawei.com> <1377239798.2618.10.camel@fdeutsch-laptop.local> Message-ID: <98B730463BF8F84A885ABF3A8F61495165F6E244@SZXEMA501-MBS.china.huawei.com> > -----Original Message----- > From: Fabian Deutsch [mailto:fabiand at redhat.com] > Sent: Friday, August 23, 2013 2:37 PM > To: Bohai (ricky) > Cc: node-devel at ovirt.org; Luohao (A); Haofeng; boh.ricky at gmail.com > Subject: Re: [node-devel] Maybe the reason for install failed sometimes > > Am Freitag, den 23.08.2013, 03:22 +0000 schrieb Bohai (ricky): > > Hi, > > > > I failed to install the ovirt-node. About detail info, please see the summary of > ovirt.log > > at the end of the mail. > > > > I read the code, and found the call for subprocess_closefds like below: > > 1426 def findfs(label): > > 1427 system("partprobe /dev/mapper/*") > > 1428 system("udevadm settle") > > 1429 blkid_cmd = "/sbin/blkid -c /dev/null -l -o device -t LABEL=\"" + > label + "\"" > > 1430 blkid = subprocess_closefds(blkid_cmd, shell=True, stdout=PIPE, > stderr=STDOUT) > > 1431 blkid_output = blkid.stdout.read().strip() > > 1432 return blkid_output > > > > I think when we read the stdout the command has not finished, so the real > blkid can't be read. > > > > After call of function subprocess_closefds, whether or not we need to wait for > process to terminate? > > Hey Ricky, > > subprocess_closefds is just wrapping subprocess.Popen and adding > close_fds=True. subprocess.Popen by default is waiting for the cmd to > exit. At least it behaved like this in a small test. > Hey Fabian, Maybe I can't agree with you. When I read the Popen's source code in Python-2.7.5/Lib/subprocess.py, I didn't find the default wait code. In [1], the document only say the subprocess.call by default wait the command's complete. The below is the source code of subprocess.call, actually it depends on the wait() function. -------------------------------------------------------------------------------------------------- 516 def call(*popenargs, **kwargs): 517 """Run command with arguments. Wait for command to complete, then 518 return the returncode attribute. 519 520 The arguments are the same as for the Popen constructor. Example: 521 522 retcode = call(["ls", "-l"]) 523 """ 524 return Popen(*popenargs, **kwargs).wait() -------------------------------------------------------------------------------------------------- So, are you sure with the default wait of subprocess.Popen ? > > For example, to call the "Popen.communicate" to wait the comand finished. > > But maybe we should take the warning just above [1] serious. > Using proc.stdout.read() can lead to dead-locks, maybe those are the > problem. But if we had the problem of dead-locks I'd expect the whole > python process to block - but maybe this assumption is wrong. > > But at least that part of our codebase is targeted with the node-3.1 > feature (page has to be created) [2] > > One idea is to use blivet [3] for the storage stuff, this is a module > used by anaconda. Maybe even other parts of anaconda can be used to e.g. > handle the grub and uefi stuff. This would mean joint efforts with the > anaconda team. > > Greetings > fabian > > --- > [1] > http://docs.python.org/2/library/subprocess.html#subprocess.Popen.stdin > [2] http://www.ovirt.org/Features/Node/StorageAndInstallerModuleRewrite > [3] https://git.fedorahosted.org/git/?p=blivet.git > > > There are lots of call for subprocess_closefds like this in ovirt-node codes , > > I guess maybe they are the reason why install failed sometimes. > > > > How do you think about this? > > > > > > --------------------------/tmp/ovirt.log----------------------------------- > > 301 2013-08-23 01:16:17,938 - DEBUG - install - Trial 1 to find candidate > (None) > > 302 2013-08-23 01:16:19,290 - DEBUG - ovirtfunctions - partprobe > > 303 2013-08-23 01:16:19,290 - DEBUG - ovirtfunctions - > > 304 2013-08-23 01:16:19,469 - DEBUG - ovirtfunctions - partprobe > /dev/mapper/* > > 305 2013-08-23 01:16:19,469 - DEBUG - ovirtfunctions - > > 306 2013-08-23 01:16:19,670 - DEBUG - ovirtfunctions - udevadm settle > > 307 2013-08-23 01:16:19,670 - DEBUG - ovirtfunctions - > > 308 2013-08-23 01:16:19,681 - DEBUG - install - Trial 2 to find candidate > (RootBackup) > > 309 2013-08-23 01:16:19,681 - DEBUG - install - Found candidate: > RootBackup > > 310 2013-08-23 01:16:19,719 - DEBUG - ovirtfunctions - partprobe > /dev/mapper/* > > 311 2013-08-23 01:16:19,719 - DEBUG - ovirtfunctions - > > 312 2013-08-23 01:16:19,845 - DEBUG - ovirtfunctions - udevadm settle > > 313 2013-08-23 01:16:19,845 - DEBUG - ovirtfunctions - > > 314 2013-08-23 01:16:20,030 - INFO - install - > > 315 2013-08-23 01:16:20,030 - INFO - install - > > 316 2013-08-23 01:16:20,037 - DEBUG - install - Traceback (most recent call > last): > > 317 File "/usr/lib/python2.7/site-packages/ovirtnode/install.py", line 424, > in ovirt_boot_setup > > 318 self.partN = int(self.disk[-1:]) > > 319 ValueError: invalid literal for int() with base 10: '' > > ------------------------------------------------------------------------------------ > > > > Best regards to you. > > Ricky > > > > _______________________________________________ > > node-devel mailing list > > node-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/node-devel > From fabiand at redhat.com Mon Aug 26 07:27:52 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Mon, 26 Aug 2013 09:27:52 +0200 Subject: [node-devel] Maybe the reason for install failed sometimes In-Reply-To: <98B730463BF8F84A885ABF3A8F61495165F6E244@SZXEMA501-MBS.china.huawei.com> References: <98B730463BF8F84A885ABF3A8F61495165F6C825@SZXEMA501-MBS.china.huawei.com> <1377239798.2618.10.camel@fdeutsch-laptop.local> <98B730463BF8F84A885ABF3A8F61495165F6E244@SZXEMA501-MBS.china.huawei.com> Message-ID: <1377502072.20178.14.camel@fdeutsch-laptop.local> Am Montag, den 26.08.2013, 02:19 +0000 schrieb Bohai (ricky): > > > I failed to install the ovirt-node. About detail info, please see > the summary of > > ovirt.log > > > at the end of the mail. > > > > > > I read the code, and found the call for subprocess_closefds like > below: > > > 1426 def findfs(label): > > > 1427 system("partprobe /dev/mapper/*") > > > 1428 system("udevadm settle") > > > 1429 blkid_cmd = "/sbin/blkid -c /dev/null -l -o device -t > LABEL=\"" + > > label + "\"" > > > 1430 blkid = subprocess_closefds(blkid_cmd, shell=True, > stdout=PIPE, > > stderr=STDOUT) > > > 1431 blkid_output = blkid.stdout.read().strip() > > > 1432 return blkid_output > > > > > > I think when we read the stdout the command has not finished, so > the real > > blkid can't be read. > > > > > > After call of function subprocess_closefds, whether or not we need > to wait for > > process to terminate? > > > > Hey Ricky, > > > > subprocess_closefds is just wrapping subprocess.Popen and adding > > close_fds=True. subprocess.Popen by default is waiting for the cmd > to > > exit. At least it behaved like this in a small test. > > > > Hey Fabian, > Maybe I can't agree with you. > > When I read the Popen's source code in > Python-2.7.5/Lib/subprocess.py, > I didn't find the default wait code. > > In [1], the document only say the subprocess.call by default wait the > command's complete. > The below is the source code of subprocess.call, actually it depends > on the wait() function. You are right. It's only the subprocess.call() method which is waiting for the cmd to complete. subprocess.Popen() (which is used by subprocess_closefds) is only spawning the new process. So yes, this could really be a reason for the occasionally failing installations. In the 3.0 branch we can't just fix subprocess_closefds, we'll need to look at each call to that function to add - if necessary - a wait() call. For 3.1 we can probably get rid of subprocess_closefds at all and use the ovirt.node.utils.process module. Greetings - fabian From fabiand at redhat.com Tue Aug 27 11:38:12 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 27 Aug 2013 13:38:12 +0200 Subject: [node-devel] Slides on "Testing a LiveCD? Igor is doing it" / function test automation for oVirt Node Message-ID: <1377603492.3396.8.camel@fdeutsch-laptop.local> Hey, last weekend I spoke about test automation at (FrOSCon)[http://www.froscon.org]. This talk also touched oVirt Node, because Igor is used to do functional tests on oVirt Node. The slides of the presentation can be found here: http://fedorapeople.org/~fabiand/slides/2013-08-froscon-igor.pdf A short screencast showing a test-run on a dev-workstation can be found here: http://dummdida.tumblr.com/post/55870194359/igor-0-4-0-for-testing-ovirt-node-for-now Greetings fabian From fabiand at redhat.com Tue Aug 27 11:40:04 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 27 Aug 2013 13:40:04 +0200 Subject: [node-devel] Slides on "Testing a LiveCD? Igor is doing it" / function test automation for oVirt Node In-Reply-To: <1377603492.3396.8.camel@fdeutsch-laptop.local> References: <1377603492.3396.8.camel@fdeutsch-laptop.local> Message-ID: <1377603604.3396.9.camel@fdeutsch-laptop.local> Am Dienstag, den 27.08.2013, 13:38 +0200 schrieb Fabian Deutsch: > A short screencast showing a test-run on a dev-workstation can be > found > here: > http://dummdida.tumblr.com/post/55870194359/igor-0-4-0-for-testing-ovirt-node-for-now This is the correct link: http://dummdida.tumblr.com/post/51492048387/testing-ovirt-node-in-4min-video - fabian From babatoko at gmail.com Wed Aug 28 09:26:38 2013 From: babatoko at gmail.com (Martial Paupe) Date: Wed, 28 Aug 2013 11:26:38 +0200 Subject: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed Message-ID: Hi all, I'm trying to install ovirt-node ovirt-node-iso-3.1.0-0.999.5.vdsm.fc19.iso onto an IBM xserver 3650 M3 without any success. I got an error " Exception: RuntimeError('Failed to set install bootloader' ,) " when installer try to set the bootloader. How I can figure out what's wrong with that setup. Any help will be appreciate. Thanks babatoko -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabiand at redhat.com Wed Aug 28 09:49:38 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Wed, 28 Aug 2013 11:49:38 +0200 Subject: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed In-Reply-To: References: Message-ID: <1377683378.20594.5.camel@fdeutsch-laptop.local> Am Mittwoch, den 28.08.2013, 11:26 +0200 schrieb Martial Paupe: > Hi all, > > > I'm trying to install > ovirt-node ovirt-node-iso-3.1.0-0.999.5.vdsm.fc19.iso onto > an IBM xserver 3650 M3 without any success. I got an error " > Exception: RuntimeError('Failed to set install bootloader' ,) " when > installer try to set the bootloader. > > > How I can figure out what's wrong with that setup. Any help will be > appreciate. Hi Babatoko, I've also seen this error occasionally, but did not look into it yet. A good starting point for debugging is /var/ovirt.log and /var/log-ovirt-node.log. And the best way to track this is to file a bug. Greetings fabian From babatoko at gmail.com Tue Aug 27 14:16:51 2013 From: babatoko at gmail.com (Martial Paupe) Date: Tue, 27 Aug 2013 16:16:51 +0200 Subject: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed Message-ID: Hi all, I'm trying to install ovirt-node ovirt-node-iso-3.1.0-0.999.5.vdsm.fc19.iso onto an IBM xserver 3650 M3 without any success. I got an error when installer try to set the bootloader as the attached printscreen show you. How I can figure out what's wrong with that setup. Any help will be appreciate. Thanks babatoko -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130827_130601[1].jpg Type: image/jpeg Size: 1857405 bytes Desc: not available URL: From mburns at redhat.com Wed Aug 28 11:04:26 2013 From: mburns at redhat.com (Mike Burns) Date: Wed, 28 Aug 2013 07:04:26 -0400 Subject: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed In-Reply-To: <1377683378.20594.5.camel@fdeutsch-laptop.local> References: <1377683378.20594.5.camel@fdeutsch-laptop.local> Message-ID: <521DD93A.7030403@redhat.com> On 08/28/2013 05:49 AM, Fabian Deutsch wrote: > Am Mittwoch, den 28.08.2013, 11:26 +0200 schrieb Martial Paupe: >> Hi all, >> >> >> I'm trying to install >> ovirt-node ovirt-node-iso-3.1.0-0.999.5.vdsm.fc19.iso onto >> an IBM xserver 3650 M3 without any success. I got an error " >> Exception: RuntimeError('Failed to set install bootloader' ,) " when >> installer try to set the bootloader. >> >> >> How I can figure out what's wrong with that setup. Any help will be >> appreciate. > > Hi Babatoko, > > I've also seen this error occasionally, but did not look into it yet. > A good starting point for debugging is /var/ovirt.log > and /var/log-ovirt-node.log. /var/log/ovirt.log /var/log/ovirt-node.log > > And the best way to track this is to file a bug. > > Greetings > fabian > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > From babatoko at gmail.com Wed Aug 28 12:00:54 2013 From: babatoko at gmail.com (Martial Paupe) Date: Wed, 28 Aug 2013 14:00:54 +0200 Subject: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed In-Reply-To: <521DD93A.7030403@redhat.com> References: <1377683378.20594.5.camel@fdeutsch-laptop.local> <521DD93A.7030403@redhat.com> Message-ID: Thanks for replying, I've copied and attached both files to this mail. There is nothing obvious to me. I'll file a bug thanks for feedback On 28 August 2013 13:04, Mike Burns wrote: > On 08/28/2013 05:49 AM, Fabian Deutsch wrote: > >> Am Mittwoch, den 28.08.2013, 11:26 +0200 schrieb Martial Paupe: >> >>> Hi all, >>> >>> >>> I'm trying to install >>> ovirt-node ovirt-node-iso-3.1.0-0.999.5.**vdsm.fc19.iso onto >>> an IBM xserver 3650 M3 without any success. I got an error " >>> Exception: RuntimeError('Failed to set install bootloader' ,) " when >>> installer try to set the bootloader. >>> >>> >>> How I can figure out what's wrong with that setup. Any help will be >>> appreciate. >>> >> >> Hi Babatoko, >> >> I've also seen this error occasionally, but did not look into it yet. >> A good starting point for debugging is /var/ovirt.log >> and /var/log-ovirt-node.log. >> > > /var/log/ovirt.log > /var/log/ovirt-node.log > > >> And the best way to track this is to file a bug. >> >> Greetings >> fabian >> >> >> ______________________________**_________________ >> node-devel mailing list >> node-devel at ovirt.org >> http://lists.ovirt.org/**mailman/listinfo/node-devel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt.log Type: application/octet-stream Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-node.log Type: application/octet-stream Size: 21650 bytes Desc: not available URL: From fabiand at redhat.com Wed Aug 28 15:42:55 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Wed, 28 Aug 2013 17:42:55 +0200 Subject: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed In-Reply-To: References: <1377683378.20594.5.camel@fdeutsch-laptop.local> <521DD93A.7030403@redhat.com> Message-ID: <1377704575.20594.7.camel@fdeutsch-laptop.local> Am Mittwoch, den 28.08.2013, 14:00 +0200 schrieb Martial Paupe: > Thanks for replying, > > > I've copied and attached both files to this mail. There is nothing > obvious to me. Hey, it seems as if the ovirt.log was gathered not during the failed installation. Please try the following to get a matching ovirt.log and ovirt-node.log: 1. Run installation and wait for it to fail 2. Press F2 to drop to console 3. Now copy /var/log/ovirt.log /var/log/ovirt-node.log and possibly /tmp/ovirt.log to a safe location. > > I'll file a bug Yey! Greetings fabian > > thanks for feedback > > > On 28 August 2013 13:04, Mike Burns wrote: > On 08/28/2013 05:49 AM, Fabian Deutsch wrote: > Am Mittwoch, den 28.08.2013, 11:26 +0200 schrieb > Martial Paupe: > Hi all, > > > I'm trying to install > ovirt-node > ovirt-node-iso-3.1.0-0.999.5.vdsm.fc19.iso > onto > an IBM xserver 3650 M3 without any success. I > got an error " > Exception: RuntimeError('Failed to set install > bootloader' ,) " when > installer try to set the bootloader. > > > How I can figure out what's wrong with that > setup. Any help will be > appreciate. > > Hi Babatoko, > > I've also seen this error occasionally, but did not > look into it yet. > A good starting point for debugging is /var/ovirt.log > and /var/log-ovirt-node.log. > > > /var/log/ovirt.log > /var/log/ovirt-node.log > > > And the best way to track this is to file a bug. > > Greetings > fabian > > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel > > > > > _______________________________________________ > node-devel mailing list > node-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/node-devel From bohai at huawei.com Thu Aug 29 02:56:20 2013 From: bohai at huawei.com (Bohai (ricky)) Date: Thu, 29 Aug 2013 02:56:20 +0000 Subject: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed In-Reply-To: References: <1377683378.20594.5.camel@fdeutsch-laptop.local> <521DD93A.7030403@redhat.com> Message-ID: <98B730463BF8F84A885ABF3A8F61495165F82D3D@SZXEMA501-MBS.china.huawei.com> Hey, I had ever encountered the same error . But I didn?t see the detail log of the error you found, maybe they just appear same. Hope the below is helpful for you. About the reason I think, please reference the mail: http://www.mail-archive.com/node-devel at ovirt.org/msg00426.html And yesterday I commit a patch on gerrit to solve it . http://gerrit.ovirt.org/#/c/18671/ Maybe you can apply and try it. Greetings Ricky From: node-devel-bounces at ovirt.org [mailto:node-devel-bounces at ovirt.org] On Behalf Of Martial Paupe Sent: Wednesday, August 28, 2013 8:01 PM To: node-devel at ovirt.org Subject: Re: [node-devel] install ovirt-node on IBM xserver 3650 M3 failed Thanks for replying, I've copied and attached both files to this mail. There is nothing obvious to me. I'll file a bug thanks for feedback On 28 August 2013 13:04, Mike Burns > wrote: On 08/28/2013 05:49 AM, Fabian Deutsch wrote: Am Mittwoch, den 28.08.2013, 11:26 +0200 schrieb Martial Paupe: Hi all, I'm trying to install ovirt-node ovirt-node-iso-3.1.0-0.999.5.vdsm.fc19.iso onto an IBM xserver 3650 M3 without any success. I got an error " Exception: RuntimeError('Failed to set install bootloader' ,) " when installer try to set the bootloader. How I can figure out what's wrong with that setup. Any help will be appreciate. Hi Babatoko, I've also seen this error occasionally, but did not look into it yet. A good starting point for debugging is /var/ovirt.log and /var/log-ovirt-node.log. /var/log/ovirt.log /var/log/ovirt-node.log And the best way to track this is to file a bug. Greetings fabian _______________________________________________ node-devel mailing list node-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/node-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: