Re: [lago-devel] Lago - Installation help needed
Adding the Lago devel mailing list. The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs? TIA, Y. On Wed, Sep 21, 2016 at 4:25 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Hello Yaniv,
Following your recommendation, I install a new bare metal host, installed F24, then followed the lago.readthedoc web site.
When running ./run_suite.sh basic_suite_3.6 , things seems to go right (downloading...) for a while, then begin some errors about accessing 192.168.200.1:8585
May you tell me where would be the best place to ask some help about Lago ? (IRC, mailing list, e-mail... ?)
Best regards,
-- Nicolas ECARNOT
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
http://pastebin.com/nsDFZhuE One thing to note : when trying to run again the same command ("./run_suite.sh basic_suite_3.6"), the script is breaking when trying to create the lago network : * Create network lago_basic_suite_3_6_lago: libvirt: error : internal error: Network is already in use by interface 8938-930e31b * Create network lago_basic_suite_3_6_lago: ERROR (in 0:00:00) # Start nets: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:00) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 170, in start net.start() File "/usr/lib/python2.7/site-packages/lago/virt.py", line 339, in start self.libvirt_con.networkCreateXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4209, in networkCreateXML if ret is None:raise libvirtError('virNetworkCreateXML() failed', conn=self) libvirtError: internal error: Network is already in use by interface 8938-930e31b I tried to ifdown this interface, but that does not seem to be enough.
TIA, Y.
On Wed, Sep 21, 2016 at 4:25 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Hello Yaniv,
Following your recommendation, I install a new bare metal host, installed F24, then followed the lago.readthedoc web site.
When running ./run_suite.sh basic_suite_3.6 , things seems to go right (downloading...) for a while, then begin some errors about accessing 192.168.200.1:8585 <http://192.168.200.1:8585>
May you tell me where would be the best place to ask some help about Lago ? (IRC, mailing list, e-mail... ?)
Best regards,
-- Nicolas ECARNOT
-- Nicolas ECARNOT
On Wed, Sep 21, 2016 at 5:07 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
Perhaps something with the Firewall?
One thing to note : when trying to run again the same command ("./run_suite.sh basic_suite_3.6"), the script is breaking when trying to create the lago network :
* Create network lago_basic_suite_3_6_lago: libvirt: error : internal error: Network is already in use by interface 8938-930e31b
Right - you did not clean the previous run: lagocli --prefix-path ./deployment-basic_suite_3.6/current cleanup Y. * Create network lago_basic_suite_3_6_lago: ERROR (in 0:00:00)
# Start nets: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:00) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 170, in start net.start() File "/usr/lib/python2.7/site-packages/lago/virt.py", line 339, in start self.libvirt_con.networkCreateXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4209, in networkCreateXML if ret is None:raise libvirtError('virNetworkCreateXML() failed', conn=self) libvirtError: internal error: Network is already in use by interface 8938-930e31b
I tried to ifdown this interface, but that does not seem to be enough.
TIA, Y.
On Wed, Sep 21, 2016 at 4:25 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Hello Yaniv,
Following your recommendation, I install a new bare metal host, installed F24, then followed the lago.readthedoc web site.
When running ./run_suite.sh basic_suite_3.6 , things seems to go right (downloading...) for a while, then begin some errors about accessing 192.168.200.1:8585
May you tell me where would be the best place to ask some help about Lago ? (IRC, mailing list, e-mail... ?)
Best regards,
-- Nicolas ECARNOT
-- Nicolas ECARNOT
Le 21/09/2016 à 16:11, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:07 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
Perhaps something with the Firewall?
I had no idea whether to keep it or not. I already disabled selinux after having realized it lead to a read only root file system. About the issue above, no being able to reach some random port would indeed be caused by the firewall, so I'll give it a try.
One thing to note : when trying to run again the same command ("./run_suite.sh basic_suite_3.6"), the script is breaking when trying to create the lago network :
* Create network lago_basic_suite_3_6_lago: libvirt: error : internal error: Network is already in use by interface 8938-930e31b
Right - you did not clean the previous run:
lagocli --prefix-path ./deployment-basic_suite_3.6/current cleanup
Nope, I already tried that before answering. Eventually, it did the trick to run : # ip link set 8938-930e31b down After the next run, no more NIC issue, but back to the 192.168.200.1:8585 problem. I'm going to disable the FW. Stay tuned. Nicolas ECARNOT
Y.
* Create network lago_basic_suite_3_6_lago: ERROR (in 0:00:00) # Start nets: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:00) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 170, in start net.start() File "/usr/lib/python2.7/site-packages/lago/virt.py", line 339, in start self.libvirt_con.networkCreateXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4209, in networkCreateXML if ret is None:raise libvirtError('virNetworkCreateXML() failed', conn=self) libvirtError: internal error: Network is already in use by interface 8938-930e31b
I tried to ifdown this interface, but that does not seem to be enough.
TIA, Y.
On Wed, Sep 21, 2016 at 4:25 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Hello Yaniv,
Following your recommendation, I install a new bare metal host, installed F24, then followed the lago.readthedoc web site.
When running ./run_suite.sh basic_suite_3.6 , things seems to go right (downloading...) for a while, then begin some errors about accessing 192.168.200.1:8585 <http://192.168.200.1:8585>
May you tell me where would be the best place to ask some help about Lago ? (IRC, mailing list, e-mail... ?)
Best regards,
-- Nicolas ECARNOT
-- Nicolas ECARNOT
-- Nicolas ECARNOT
On Wed, Sep 21, 2016 at 5:19 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 21/09/2016 à 16:11, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:07 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
Perhaps something with the Firewall?
I had no idea whether to keep it or not. I already disabled selinux after having realized it lead to a read only root file system.
About the issue above, no being able to reach some random port would indeed be caused by the firewall, so I'll give it a try.
During RPM installation it should add the relevant rule to the firewalld, btw: if which firewall-cmd &>/dev/null; then firewall-cmd --reload firewall-cmd --permanent --zone=public --add-service=ovirtlago firewall-cmd --reload fi
One thing to note : when trying to run again the same command ("./run_suite.sh basic_suite_3.6"), the script is breaking when trying to create the lago network :
* Create network lago_basic_suite_3_6_lago: libvirt: error : internal error: Network is already in use by interface 8938-930e31b
Right - you did not clean the previous run:
lagocli --prefix-path ./deployment-basic_suite_3.6/current cleanup
Nope, I already tried that before answering. Eventually, it did the trick to run : # ip link set 8938-930e31b down
After the next run, no more NIC issue, but back to the 192.168.200.1:8585 problem.
I'm going to disable the FW. Stay tuned.
Nicolas ECARNOT
Y.
* Create network lago_basic_suite_3_6_lago: ERROR (in 0:00:00)
# Start nets: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:00) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 170, in start net.start() File "/usr/lib/python2.7/site-packages/lago/virt.py", line 339, in start self.libvirt_con.networkCreateXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4209, in networkCreateXML if ret is None:raise libvirtError('virNetworkCreateXML() failed', conn=self) libvirtError: internal error: Network is already in use by interface 8938-930e31b
I tried to ifdown this interface, but that does not seem to be enough.
TIA, Y.
On Wed, Sep 21, 2016 at 4:25 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Hello Yaniv,
Following your recommendation, I install a new bare metal host, installed F24, then followed the lago.readthedoc web site.
When running ./run_suite.sh basic_suite_3.6 , things seems to go right (downloading...) for a while, then begin some errors about accessing 192.168.200.1:8585
May you tell me where would be the best place to ask some help about Lago ? (IRC, mailing list, e-mail... ?)
Best regards,
-- Nicolas ECARNOT
-- Nicolas ECARNOT
-- Nicolas ECARNOT
Le 21/09/2016 à 16:28, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:19 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 16:11, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:07 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
Perhaps something with the Firewall?
I had no idea whether to keep it or not. I already disabled selinux after having realized it lead to a read only root file system.
About the issue above, no being able to reach some random port would indeed be caused by the firewall, so I'll give it a try.
During RPM installation it should add the relevant rule to the firewalld, btw: if which firewall-cmd &>/dev/null; then firewall-cmd --reload firewall-cmd --permanent --zone=public --add-service=ovirtlago firewall-cmd --reload fi
I gave it many tries and only when manually adding your recommended firewall-cmd command, I was able to go one step further in the run. Next issue is there : @ Start Prefix: # Start nets: * Create network lago_basic_suite_3_6_lago: * Create network lago_basic_suite_3_6_lago: Success (in 0:00:06) # Start nets: Success (in 0:00:06) # Start vms: * Starting VM lago_basic_suite_3_6_engine: libvirt: QEMU Driver error : internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory * Starting VM lago_basic_suite_3_6_engine: ERROR (in 0:00:02) # Start vms: ERROR (in 0:00:02) # Destroy network lago_basic_suite_3_6_lago: # Destroy network lago_basic_suite_3_6_lago: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:09) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 175, in start vm.start() File "/usr/lib/python2.7/site-packages/lago/plugins/vm.py", line 247, in start return self.provider.start(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/vm.py", line 93, in start self.libvirt_con.createXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3727, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory So here is the time I have to admit I'm trying to run all this on a *very* humble machine, with only 4Gb of RAM, that may sound ridiculous but I am prepared to wait for days between each command return and mouse click, as long as everything is doing its job (slowly). Not being able to allocate memory is blocking me from even testing Lago. Wouldn't be somewhere I could tweak some limits? -- Nicolas ECARNOT
On Wed, Sep 21, 2016 at 5:58 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Not being able to allocate memory is blocking me from even testing Lago.
Wouldn't be somewhere I could tweak some limits?
Running ovirt-system-tests requires much more than 4GB of RAM, however if you just want to check out Lago(without ovirt-system-tests) have a look on [1] and [2]
libvirt: error : internal error: Network is already in use by interface 8938-930e31b You can always remove them manually: sudo virsh net-list net-destroy id
[1] https://github.com/lago-project/lago-demo - run Jenkins inside Lago [2] https://github.com/lago-project/lago/pull/316/files/4df1f7710c61619694bdb341... - run core Lago in virtualenv(you can take the LagoInitFile template from there), still under work.
On Wed, Sep 21, 2016 at 5:58 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 21/09/2016 à 16:28, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:19 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 21/09/2016 à 16:11, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:07 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
Perhaps something with the Firewall?
I had no idea whether to keep it or not. I already disabled selinux after having realized it lead to a read only root file system.
About the issue above, no being able to reach some random port would indeed be caused by the firewall, so I'll give it a try.
During RPM installation it should add the relevant rule to the firewalld, btw: if which firewall-cmd &>/dev/null; then firewall-cmd --reload firewall-cmd --permanent --zone=public --add-service=ovirtlago firewall-cmd --reload fi
I gave it many tries and only when manually adding your recommended firewall-cmd command, I was able to go one step further in the run.
Next issue is there :
@ Start Prefix: # Start nets: * Create network lago_basic_suite_3_6_lago: * Create network lago_basic_suite_3_6_lago: Success (in 0:00:06) # Start nets: Success (in 0:00:06) # Start vms: * Starting VM lago_basic_suite_3_6_engine: libvirt: QEMU Driver error : internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory * Starting VM lago_basic_suite_3_6_engine: ERROR (in 0:00:02) # Start vms: ERROR (in 0:00:02) # Destroy network lago_basic_suite_3_6_lago: # Destroy network lago_basic_suite_3_6_lago: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:09) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 175, in start vm.start() File "/usr/lib/python2.7/site-packages/lago/plugins/vm.py", line 247, in start return self.provider.start(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/vm.py", line 93, in start self.libvirt_con.createXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3727, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory
So here is the time I have to admit I'm trying to run all this on a *very* humble machine, with only 4Gb of RAM, that may sound ridiculous but I am prepared to wait for days between each command return and mouse click, as long as everything is doing its job (slowly).
Not being able to allocate memory is blocking me from even testing Lago.
Wouldn't be somewhere I could tweak some limits?
Of course, but I don't such low value would suffice. You can change the template - basic_suite_3.6/LagoInitFile.in
-- Nicolas ECARNOT
Le 21/09/2016 à 17:43, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:58 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 16:28, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:19 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 16:11, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:07 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
Perhaps something with the Firewall?
I had no idea whether to keep it or not. I already disabled selinux after having realized it lead to a read only root file system.
About the issue above, no being able to reach some random port would indeed be caused by the firewall, so I'll give it a try.
During RPM installation it should add the relevant rule to the firewalld, btw: if which firewall-cmd &>/dev/null; then firewall-cmd --reload firewall-cmd --permanent --zone=public --add-service=ovirtlago firewall-cmd --reload fi
I gave it many tries and only when manually adding your recommended firewall-cmd command, I was able to go one step further in the run.
Next issue is there :
@ Start Prefix: # Start nets: * Create network lago_basic_suite_3_6_lago: * Create network lago_basic_suite_3_6_lago: Success (in 0:00:06) # Start nets: Success (in 0:00:06) # Start vms: * Starting VM lago_basic_suite_3_6_engine: libvirt: QEMU Driver error : internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory * Starting VM lago_basic_suite_3_6_engine: ERROR (in 0:00:02) # Start vms: ERROR (in 0:00:02) # Destroy network lago_basic_suite_3_6_lago: # Destroy network lago_basic_suite_3_6_lago: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:09) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 175, in start vm.start() File "/usr/lib/python2.7/site-packages/lago/plugins/vm.py", line 247, in start return self.provider.start(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/vm.py", line 93, in start self.libvirt_con.createXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3727, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory
So here is the time I have to admit I'm trying to run all this on a *very* humble machine, with only 4Gb of RAM, that may sound ridiculous but I am prepared to wait for days between each command return and mouse click, as long as everything is doing its job (slowly).
Not being able to allocate memory is blocking me from even testing Lago.
Wouldn't be somewhere I could tweak some limits?
Of course, but I don't such low value would suffice. You can change the template - basic_suite_3.6/LagoInitFile.in
Thank you Nadav for your answer about networking. Thank you Yaniv as always helpful, because your hint worked : I reduced the values of memory settings in the Lago init file and ran everything from scratch : at first, it got stuck for hours with no disk usage progress (as adviced in the FAQ). So I stopped everything, and ran a cleanup, then deleted the /var/lib/lago/somewhere/rpm/cache/blahblah, and also rm -fr the deployment dir. Then ran again, and it seems that everything until the tests went OK. Now in my processes, I can see qemu processes running the engine, the host0, host1 and storage. virsh # list Id Name State ---------------------------------------------------- 1 f8b91b68-lago_basic_suite_3_6_engine running 2 f8b91b68-lago_basic_suite_3_6_host1 running 3 f8b91b68-lago_basic_suite_3_6_host0 running 4 f8b91b68-lago_basic_suite_3_6_storage running But the first test (engine initialization) is failing with an issue related to paramiko (see below). Apart from googling it, I had no idea what paramiko was. Anyway, as it leads to test 001 failing, then eventually complete stop, I have to know how to correct this. I already checked that I have the paramiko RPM installed. + env_run_test /data/lago/ovirt-system-tests/basic_suite_3.6/test-scenarios/001_initialize_engine.py [0/1196] + echo '#########################' ######################### + local res=0 + cd /data/lago/ovirt-system-tests/deployment-basic_suite_3.6 + lago ovirt runtest /data/lago/ovirt-system-tests/basic_suite_3.6/test-scenarios/001_initialize_engine.py current session does not belong to lago group. @ Run test: 001_initialize_engine.py: nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] # 001_initialize_engine.test_initialize_engine: * Copy /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf to lago_basic_suite_3_6_engine:/tmp/answer-file: * Copy /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf to lago_basic_suite_3_6_engine:/tmp/answer-file: Success (in 0:00:01) * Collect artifacts: No handlers could be found for logger "paramiko.transport" - [Thread-8] lago_basic_suite_3_6_host0: ERROR (in 0:01:04) * Collect artifacts: ERROR (in 0:01:04) # 001_initialize_engine.test_initialize_engine: ERROR (in 0:01:19) # Results located at /data/lago/ovirt-system-tests/deployment-basic_suite_3.6/default/nosetests-001_initialize_engine.py.xml @ Run test: 001_initialize_engine.py: ERROR (in 0:01:21) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 258, in do_run self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 102, in do_ovirt_runtest raise RuntimeError('Some tests failed') RuntimeError: Some tests failed + res=1 + cd - /data/lago/ovirt-system-tests + return 1 + failed=true + env_collect /data/lago/ovirt-system-tests/test_logs/basic_suite_3.6/post-001_initialize_engine.py + local tests_out_dir=/data/lago/ovirt-system-tests/test_logs/basic_suite_3.6/post-001_initialize_engine.py + echo '#########################' ######################### + [[ -e /data/lago/ovirt-system-tests/test_logs/basic_suite_3.6 ]] + mkdir -p /data/lago/ovirt-system-tests/test_logs/basic_suite_3.6 + cd /data/lago/ovirt-system-tests/deployment-basic_suite_3.6/current + lago ovirt collect --output /data/lago/ovirt-system-tests/test_logs/basic_suite_3.6/post-001_initialize_engine.py current session does not belong to lago group. @ Collect artifacts: # [Thread-1] lago_basic_suite_3_6_engine: # [Thread-2] lago_basic_suite_3_6_host1: # [Thread-3] lago_basic_suite_3_6_host0: # [Thread-4] lago_basic_suite_3_6_storage: # [Thread-1] lago_basic_suite_3_6_engine: Success (in 0:00:22) # [Thread-4] lago_basic_suite_3_6_storage: Success (in 0:00:23) # [Thread-2] lago_basic_suite_3_6_host1: Success (in 0:00:23) # [Thread-3] lago_basic_suite_3_6_host0: Success (in 0:00:23) @ Collect artifacts: Success (in 0:00:24) + cp -a logs /data/lago/ovirt-system-tests/test_logs/basic_suite_3.6/post-001_initialize_engine.py/lago_logs + cd - /data/lago/ovirt-system-tests + true + echo '@@@@ ERROR: Failed running /data/lago/ovirt-system-tests/basic_suite_3.6/test-scenarios/001_initialize_engine.py' @@@@ ERROR: Failed running /data/lago/ovirt-system-tests/basic_suite_3.6/test-scenarios/001_initialize_engine.py + return 1 Many stackoverflow answers seem to say that the fix is easy, but I have no clue where to put these settings? http://stackoverflow.com/questions/15437700/no-handlers-could-be-found-for-l... -- Nicolas ECARNOT
Le 23/09/2016 à 09:06, Nicolas Ecarnot a écrit :
# 001_initialize_engine.test_initialize_engine:
* Copy /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf to lago_basic_suite_3_6_engine:/tmp/answer-file: * Copy /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf to lago_basic_suite_3_6_engine:/tmp/answer-file: Success (in 0:00:01) * Collect artifacts: No handlers could be found for logger "paramiko.transport" - [Thread-8] lago_basic_suite_3_6_host0: ERROR (in 0:01:04) * Collect artifacts: ERROR (in 0:01:04) # 001_initialize_engine.test_initialize_engine: ERROR (in 0:01:19) # Results located at /data/lago/ovirt-system-tests/deployment-basic_suite_3.6/default/nosetests-001_initialize_engine.py.xml
Sorry for this self-reply, but I had a look at the xml log file above, and as expected, it clearly states that when answering to the ovirt engine setup, not enough RAM is detected, and the answer file is replying "No", so the installation is aborting. As you may have noticed, stubborned as I am, I'd like to try anyway, so can I change the /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf file to make it answer yes to keep installing anyway? Can I just modify OVESETUP_SYSTEM/memCheckEnabled=bool:True ? PS : I promise, I'm still playing with this tiny bare metal machine for some days, and if it is too limited, I'll switch to a stronger one (but I have to convince some people), and stop bothering you all with issues related to hardware limits. -- Nicolas ECARNOT
On Fri, Sep 23, 2016 at 10:53 AM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 23/09/2016 à 09:06, Nicolas Ecarnot a écrit :
# 001_initialize_engine.test_initialize_engine:
* Copy /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf to lago_basic_suite_3_6_engine:/tmp/answer-file: * Copy /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf to lago_basic_suite_3_6_engine:/tmp/answer-file: Success (in 0:00:01) * Collect artifacts: No handlers could be found for logger "paramiko.transport" - [Thread-8] lago_basic_suite_3_6_host0: ERROR (in 0:01:04) * Collect artifacts: ERROR (in 0:01:04) # 001_initialize_engine.test_initialize_engine: ERROR (in 0:01:19) # Results located at /data/lago/ovirt-system-tests/ deployment-basic_suite_3.6/default/nosetests-001_initialize_engine.py.xml
Sorry for this self-reply, but I had a look at the xml log file above, and as expected, it clearly states that when answering to the ovirt engine setup, not enough RAM is detected, and the answer file is replying "No", so the installation is aborting.
As you may have noticed, stubborned as I am, I'd like to try anyway, so can I change the /data/lago/ovirt-system-tests/ basic_suite_3.6/engine-answer-file.conf file to make it answer yes to keep installing anyway? Can I just modify OVESETUP_SYSTEM/memCheckEnabled=bool:True ?
You can try.
PS : I promise, I'm still playing with this tiny bare metal machine for some days, and if it is too limited, I'll switch to a stronger one (but I have to convince some people), and stop bothering you all with issues related to hardware limits.
BTW, please make sure you are running KSM (sudo systemctl start ksm) - it may give you a bit of leg room.. Y.
-- Nicolas ECARNOT
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
Le 26/09/2016 à 08:14, Yaniv Kaul a écrit :
As you may have noticed, stubborned as I am, I'd like to try anyway, so can I change the /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf file to make it answer yes to keep installing anyway? Can I just modify OVESETUP_SYSTEM/memCheckEnabled=bool:True ?
You can try.
I did, but to no avail.
PS : I promise, I'm still playing with this tiny bare metal machine for some days, and if it is too limited, I'll switch to a stronger one (but I have to convince some people), and stop bothering you all with issues related to hardware limits.
BTW, please make sure you are running KSM (sudo systemctl start ksm) - it may give you a bit of leg room..
Ok, I just installed and ran KSM, and the results are not the same. In the engine test, I only get warnings, and eventually : --== END OF SUMMARY ==-- [ INFO ] Starting engine service [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'ovirt-engine' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160926025618-pe4ci8.log In this log file, I see some errors about minidnf (about which I know nothing), and indirect information about the lack of a correct database. I see no more errors about memory. The log file is attached, and I'd be very thankful if anyone could have a quick look for things I may have missed. -- Nicolas ECARNOT
On Mon, Sep 26, 2016 at 10:43 AM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 26/09/2016 à 08:14, Yaniv Kaul a écrit :
As you may have noticed, stubborned as I am, I'd like to try anyway, so can I change the /data/lago/ovirt-system-tests/basic_suite_3.6/engine-answer-file.conf file to make it answer yes to keep installing anyway? Can I just modify OVESETUP_SYSTEM/memCheckEnabled=bool:True ?
You can try.
I did, but to no avail.
You should set it to False if you want engine-setup to not ask.
PS : I promise, I'm still playing with this tiny bare metal machine for some days, and if it is too limited, I'll switch to a stronger one (but I have to convince some people), and stop bothering you all with issues related to hardware limits.
BTW, please make sure you are running KSM (sudo systemctl start ksm) - it may give you a bit of leg room..
Ok, I just installed and ran KSM, and the results are not the same.
In the engine test, I only get warnings, and eventually : --== END OF SUMMARY ==--
[ INFO ] Starting engine service [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'ovirt-engine' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160926025618-pe4ci8.log
In this log file, I see some errors about minidnf (about which I know nothing),
You can ignore these. dnf is the replacement for yum built into recent fedora. On el7 these messages are expected and harmless.
and indirect information about the lack of a correct database. I see no more errors about memory.
The log file is attached, and I'd be very thankful if anyone could have a quick look for things I may have missed.
Please check/post engine logs, /var/log/ovirt-engine/* . Thanks. Best, -- Didi
Hello Didi, Thank you for your answer. Le 26/09/2016 à 09:52, Yedidyah Bar David a écrit :
Can I just modify OVESETUP_SYSTEM/memCheckEnabled=bool:True ? You can try. I did, but to no avail. You should set it to False if you want engine-setup to not ask.
Sorry for not having been clear : I did that ("set to false"), and indeed, I wasn't bothered with it anymore, but it failed anyway later, at the end of all the automatic replies, when running the last steps of the installer. The KSM proposed by Yaniv seem to have been a good one, as the installation went further. But there are still errors I'm trying to detect. See below.
PS : I promise, I'm still playing with this tiny bare metal machine for some days, and if it is too limited, I'll switch to a stronger one (but I have to convince some people), and stop bothering you all with issues related to hardware limits.
BTW, please make sure you are running KSM (sudo systemctl start ksm) - it may give you a bit of leg room..
Ok, I just installed and ran KSM, and the results are not the same.
In the engine test, I only get warnings, and eventually : --== END OF SUMMARY ==--
[ INFO ] Starting engine service [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'ovirt-engine' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160926025618-pe4ci8.log
In this log file, I see some errors about minidnf (about which I know nothing),
You can ignore these.
dnf is the replacement for yum built into recent fedora. On el7 these messages are expected and harmless.
Ok, I knew what dnf was, but had no idea about minidnf. Anyway, if it can be ignore, let's skip that and keep searching.
and indirect information about the lack of a correct database. I see no more errors about memory.
The log file is attached, and I'd be very thankful if anyone could have a quick look for things I may have missed.
Please check/post engine logs, /var/log/ovirt-engine/* . Thanks.
I used lagocli collect to retrieve the log files, and I provided the relevant log file attached in my previous message (I hope it went though mailman). Looking at the tree retrieved by "lagocli collect", or connecting directly with "lagocli shell", I see that there is one and only file : the one I provided. Is there some interesting keywords I should pay attention at, apart the obvious errors? -- Nicolas ECARNOT
quick lookup: grep -i -E -B10 -A10 "(exception|error|timeout)" ovirt-engine-setup-20160926025618-pe4ci8.log | more 2016-09-26 02:56:26 DEBUG otopi.ovirt_engine_setup.engine_common.database database.getCredentials:1168 database connection failed Traceback (most recent call last): File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 1166, in getCredentials ] = self.isNewDatabase() File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 364, in isNewDatabase transaction=False, File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 185, in execute database=database, File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 119, in connect sslmode=sslmode, OperationalError: could not connect to server: Connection refused Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? On Mon, Sep 26, 2016 at 11:30 AM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Hello Didi,
Thank you for your answer.
Le 26/09/2016 à 09:52, Yedidyah Bar David a écrit :
Can I just modify OVESETUP_SYSTEM/memCheckEnabled=bool:True ?
You can try. I did, but to no avail.
You should set it to False if you want engine-setup to not ask.
Sorry for not having been clear : I did that ("set to false"), and indeed, I wasn't bothered with it anymore, but it failed anyway later, at the end of all the automatic replies, when running the last steps of the installer.
The KSM proposed by Yaniv seem to have been a good one, as the installation went further. But there are still errors I'm trying to detect. See below.
PS : I promise, I'm still playing with this tiny bare metal machine for some days, and if it is too limited, I'll switch to a stronger one (but I have to convince some people), and stop bothering you all with issues related to hardware limits.
BTW, please make sure you are running KSM (sudo systemctl start ksm) - it may give you a bit of leg room..
Ok, I just installed and ran KSM, and the results are not the same.
In the engine test, I only get warnings, and eventually : --== END OF SUMMARY ==--
[ INFO ] Starting engine service [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'ovirt-engine' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160926025618-pe4ci8.log
In this log file, I see some errors about minidnf (about which I know nothing),
You can ignore these.
dnf is the replacement for yum built into recent fedora. On el7 these messages are expected and harmless.
Ok, I knew what dnf was, but had no idea about minidnf. Anyway, if it can be ignore, let's skip that and keep searching.
and indirect information about the lack of a correct database. I see no more errors about memory.
The log file is attached, and I'd be very thankful if anyone could have a quick look for things I may have missed.
Please check/post engine logs, /var/log/ovirt-engine/* . Thanks.
I used lagocli collect to retrieve the log files, and I provided the relevant log file attached in my previous message (I hope it went though mailman).
Looking at the tree retrieved by "lagocli collect", or connecting directly with "lagocli shell", I see that there is one and only file : the one I provided.
Is there some interesting keywords I should pay attention at, apart the obvious errors?
-- Nicolas ECARNOT
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
On Mon, Sep 26, 2016 at 11:38 AM, Nadav Goldin <ngoldin@redhat.com> wrote:
quick lookup: grep -i -E -B10 -A10 "(exception|error|timeout)" ovirt-engine-setup-20160926025618-pe4ci8.log | more 2016-09-26 02:56:26 DEBUG otopi.ovirt_engine_setup.engine_common.database database.getCredentials:1168 database connection failed Traceback (most recent call last): File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 1166, in getCredentials ] = self.isNewDatabase() File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 364, in isNewDatabase transaction=False, File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 185, in execute database=database, File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 119, in connect sslmode=sslmode, OperationalError: could not connect to server: Connection refused Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host "localhost" and accepting TCP/IP connections on port 5432?
All these are irrelevant. The only relevant error is: 2016-09-26 03:00:42 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:828 execute: ('/sbin/service', 'ovirt-engine', 'start'), executable='None', cwd='None', env=None 2016-09-26 03:00:43 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:878 execute-result: ('/sbin/service', 'ovirt-engine', 'start'), rc=1 2016-09-26 03:00:43 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:936 execute-output: ('/sbin/service', 'ovirt-engine', 'start') stdout: Starting oVirt Engine: [FAILED] 2016-09-26 03:00:43 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:941 execute-output: ('/sbin/service', 'ovirt-engine', 'start') stderr: So we need engine logs to know more. If none were generated, it might have failed too early. Please check system logs - /var/log/messages, journalctl, etc. Thanks.
On Mon, Sep 26, 2016 at 11:30 AM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Hello Didi,
Thank you for your answer.
Le 26/09/2016 à 09:52, Yedidyah Bar David a écrit :
Can I just modify OVESETUP_SYSTEM/memCheckEnabled=bool:True ?
You can try. I did, but to no avail.
You should set it to False if you want engine-setup to not ask.
Sorry for not having been clear : I did that ("set to false"), and indeed, I wasn't bothered with it anymore, but it failed anyway later, at the end of all the automatic replies, when running the last steps of the installer.
The KSM proposed by Yaniv seem to have been a good one, as the installation went further. But there are still errors I'm trying to detect. See below.
PS : I promise, I'm still playing with this tiny bare metal machine for some days, and if it is too limited, I'll switch to a stronger one (but I have to convince some people), and stop bothering you all with issues related to hardware limits.
BTW, please make sure you are running KSM (sudo systemctl start ksm) - it may give you a bit of leg room..
Ok, I just installed and ran KSM, and the results are not the same.
In the engine test, I only get warnings, and eventually : --== END OF SUMMARY ==--
[ INFO ] Starting engine service [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'ovirt-engine' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160926025618-pe4ci8.log
In this log file, I see some errors about minidnf (about which I know nothing),
You can ignore these.
dnf is the replacement for yum built into recent fedora. On el7 these messages are expected and harmless.
Ok, I knew what dnf was, but had no idea about minidnf. Anyway, if it can be ignore, let's skip that and keep searching.
and indirect information about the lack of a correct database. I see no more errors about memory.
The log file is attached, and I'd be very thankful if anyone could have a quick look for things I may have missed.
Please check/post engine logs, /var/log/ovirt-engine/* . Thanks.
I used lagocli collect to retrieve the log files, and I provided the relevant log file attached in my previous message (I hope it went though mailman).
Looking at the tree retrieved by "lagocli collect", or connecting directly with "lagocli shell", I see that there is one and only file : the one I provided.
Is there some interesting keywords I should pay attention at, apart the obvious errors?
-- Nicolas ECARNOT
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
-- Didi
Hello, After having succeed in installing Lago and running a very basic oVirt 3.6 on a 4G RAM system, I now start it from scratch on a new 64G real server. Following the same path, but with some better knowledge, I'm facing some similar issues, and not understanding how I coped with them previously : On the deploy stage, the VMs are trying to chat with the repository server on the 8585 port. Digging around, I see that there should be an http server listening on tcp/8585, as I can see here : /usr/lib/python2.7/site-packages/ovirtlago/constants.py LIBEXEC_DIR = '/usr/libexec/ovirtlago/' DATA_DIR = '/usr/share/ovirtlago/' ANSWER_FILES_DIR = os.path.join(DATA_DIR, 'config', 'answer-files') REPO_SERVER_PORT = 8585 ENGINE_USER = 'admin@internal' ENGINE_PASSWORD = '123' But the problem is that : root@serv-hv-dev02:/usr/lib/python2.7/site-packages/ovirtlago# LANG=C ls -la /usr/libexec/ovirtlago/ ls: cannot access '/usr/libexec/ovirtlago/': No such file or directory And I get the same error on my previous tiny server. So, I have no clue how I got past it previously, and no idea how to solve that. The only thing I changed between the two servers is that on the new one, I installed : yum install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm when I installed release36 on the first one. This is no firewall error as stated below. Some pieces seem to be missing. -- Nicolas ECARNOT Le 21/09/2016 à 16:58, Nicolas Ecarnot a écrit :
Le 21/09/2016 à 16:28, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:19 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 16:11, Yaniv Kaul a écrit :
On Wed, Sep 21, 2016 at 5:07 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
Perhaps something with the Firewall?
I had no idea whether to keep it or not. I already disabled selinux after having realized it lead to a read only root file system.
About the issue above, no being able to reach some random port would indeed be caused by the firewall, so I'll give it a try.
During RPM installation it should add the relevant rule to the firewalld, btw: if which firewall-cmd &>/dev/null; then firewall-cmd --reload firewall-cmd --permanent --zone=public --add-service=ovirtlago firewall-cmd --reload fi
I gave it many tries and only when manually adding your recommended firewall-cmd command, I was able to go one step further in the run.
Next issue is there :
@ Start Prefix: # Start nets: * Create network lago_basic_suite_3_6_lago: * Create network lago_basic_suite_3_6_lago: Success (in 0:00:06) # Start nets: Success (in 0:00:06) # Start vms: * Starting VM lago_basic_suite_3_6_engine: libvirt: QEMU Driver error : internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory * Starting VM lago_basic_suite_3_6_engine: ERROR (in 0:00:02) # Start vms: ERROR (in 0:00:02) # Destroy network lago_basic_suite_3_6_lago: # Destroy network lago_basic_suite_3_6_lago: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:09) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 175, in start vm.start() File "/usr/lib/python2.7/site-packages/lago/plugins/vm.py", line 247, in start return self.provider.start(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/vm.py", line 93, in start self.libvirt_con.createXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3727, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: 2016-09-21T14:50:12.757362Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory
So here is the time I have to admit I'm trying to run all this on a *very* humble machine, with only 4Gb of RAM, that may sound ridiculous but I am prepared to wait for days between each command return and mouse click, as long as everything is doing its job (slowly).
Not being able to allocate memory is blocking me from even testing Lago.
Wouldn't be somewhere I could tweak some limits?
-- Nicolas ECARNOT
-- Nicolas ECARNOT
Le 30/09/2016 à 11:04, Nicolas Ecarnot a écrit :
Hello,
After having succeed in installing Lago and running a very basic oVirt 3.6 on a 4G RAM system, I now start it from scratch on a new 64G real server.
Following the same path, but with some better knowledge, I'm facing some similar issues, and not understanding how I coped with them previously :
On the deploy stage, the VMs are trying to chat with the repository server on the 8585 port.
Digging around, I see that there should be an http server listening on tcp/8585, as I can see here :
/usr/lib/python2.7/site-packages/ovirtlago/constants.py
LIBEXEC_DIR = '/usr/libexec/ovirtlago/' DATA_DIR = '/usr/share/ovirtlago/' ANSWER_FILES_DIR = os.path.join(DATA_DIR, 'config', 'answer-files')
REPO_SERVER_PORT = 8585 ENGINE_USER = 'admin@internal' ENGINE_PASSWORD = '123'
But the problem is that :
root@serv-hv-dev02:/usr/lib/python2.7/site-packages/ovirtlago# LANG=C ls -la /usr/libexec/ovirtlago/ ls: cannot access '/usr/libexec/ovirtlago/': No such file or directory
And I get the same error on my previous tiny server.
So, I have no clue how I got past it previously, and no idea how to solve that.
The only thing I changed between the two servers is that on the new one, I installed : yum install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm
when I installed release36 on the first one.
This is no firewall error as stated below. Some pieces seem to be missing.
Wow, I'm getting puzzled : Without changing anything, just destroying the deployed prefix, then running again, everything seem to have worked, though I've been doing the exact same thing maybe 7 times before. What is happening ? -- Nicolas ECARNOT
On Sep 30, 2016 2:17 PM, "Nicolas Ecarnot" <nicolas@ecarnot.net> wrote:
Le 30/09/2016 à 11:04, Nicolas Ecarnot a écrit :
Hello,
After having succeed in installing Lago and running a very basic oVirt 3.6 on a 4G RAM system, I now start it from scratch on a new 64G real server.
Following the same path, but with some better knowledge, I'm facing some similar issues, and not understanding how I coped with them previously :
On the deploy stage, the VMs are trying to chat with the repository server on the 8585 port.
Digging around, I see that there should be an http server listening on tcp/8585, as I can see here :
/usr/lib/python2.7/site-packages/ovirtlago/constants.py
LIBEXEC_DIR = '/usr/libexec/ovirtlago/' DATA_DIR = '/usr/share/ovirtlago/' ANSWER_FILES_DIR = os.path.join(DATA_DIR, 'config', 'answer-files')
REPO_SERVER_PORT = 8585 ENGINE_USER = 'admin@internal' ENGINE_PASSWORD = '123'
But the problem is that :
root@serv-hv-dev02:/usr/lib/python2.7/site-packages/ovirtlago# LANG=C ls -la /usr/libexec/ovirtlago/ ls: cannot access '/usr/libexec/ovirtlago/': No such file or directory
And I get the same error on my previous tiny server.
So, I have no clue how I got past it previously, and no idea how to solve that.
The only thing I changed between the two servers is that on the new one, I installed : yum install -y
http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm
when I installed release36 on the first one.
This is no firewall error as stated below. Some pieces seem to be missing.
Wow, I'm getting puzzled : Without changing anything, just destroying the deployed prefix, then running again, everything seem to have worked, though I've been doing the exact same thing maybe 7 times before.
What is happening ?
When lago is executing a suite, it is making sure the web server is running and serving the repo. When it's not, if you wish to run it outside the suite, execute 'lago ovirt serve'. Or you can enable the regular repos of the VMs and exclude the internal ones when calling yum commands. Y.
-- Nicolas ECARNOT _______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
Le 30/09/2016 à 20:18, Yaniv Kaul a écrit :
When lago is executing a suite, it is making sure the web server is running and serving the repo. When it's not, if you wish to run it outside the suite, execute 'lago ovirt serve'. Or you can enable the regular repos of the VMs and exclude the internal ones when calling yum commands. Y.
Yaniv, When first reading your answer, and reading that engine:/etc/yum.repos.d/lago.conf is pointing to 192.168.200.1 (the bare-metal host), I understood that the bare-metal host was the one that had to http-serve the packages. But on this bare-metal host, I find no httpd package installed, nor /etc/httpd, neither /var/www/html. But I find it on the engine VM. I don't get it. Moreover, when going under the deployment_blahblah_prefix dir, and running lago ovirt serve, nothing is happening, the command gets stuck. May you enlighten this please ? -- Nicolas ECARNOT
On Fri, Oct 14, 2016 at 3:00 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 30/09/2016 à 20:18, Yaniv Kaul a écrit :
When lago is executing a suite, it is making sure the web server is running and serving the repo. When it's not, if you wish to run it outside the suite, execute 'lago ovirt serve'. Or you can enable the regular repos of the VMs and exclude the internal ones when calling yum commands. Y.
Yaniv,
When first reading your answer, and reading that engine:/etc/yum.repos.d/lago.conf is pointing to 192.168.200.1 (the bare-metal host), I understood that the bare-metal host was the one that had to http-serve the packages.
But on this bare-metal host, I find no httpd package installed, nor /etc/httpd, neither /var/www/html.
Right, it's an internal, Python web-server, part of ovirtlago.
But I find it on the engine VM.
I don't get it.
Moreover, when going under the deployment_blahblah_prefix dir, and running lago ovirt serve, nothing is happening, the command gets stuck.
Under current? Y.
May you enlighten this please ?
-- Nicolas ECARNOT
Le 14/10/2016 à 15:03, Yaniv Kaul a écrit :
On Fri, Oct 14, 2016 at 3:00 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 30/09/2016 à 20:18, Yaniv Kaul a écrit :
When lago is executing a suite, it is making sure the web server is running and serving the repo. When it's not, if you wish to run it outside the suite, execute 'lago ovirt serve'. Or you can enable the regular repos of the VMs and exclude the internal ones when calling yum commands. Y.
Yaniv,
When first reading your answer, and reading that engine:/etc/yum.repos.d/lago.conf is pointing to 192.168.200.1 (the bare-metal host), I understood that the bare-metal host was the one that had to http-serve the packages.
But on this bare-metal host, I find no httpd package installed, nor /etc/httpd, neither /var/www/html.
Right, it's an internal, Python web-server, part of ovirtlago.
OK
But I find it on the engine VM.
I don't get it.
Moreover, when going under the deployment_blahblah_prefix dir, and running lago ovirt serve, nothing is happening, the command gets stuck.
Under current?
Is your question the version? lago --version lago 0.25.0 I made a git pull yesterday. When running a dnf update, I see that there's a lago 0.26.0-1.fc24 upgrade pending, so I may try this.
Y.
May you enlighten this please ?
-- Nicolas ECARNOT
-- Nicolas ECARNOT
On Fri, Oct 14, 2016 at 4:28 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 14/10/2016 à 15:03, Yaniv Kaul a écrit :
On Fri, Oct 14, 2016 at 3:00 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 30/09/2016 à 20:18, Yaniv Kaul a écrit :
When lago is executing a suite, it is making sure the web server is running and serving the repo. When it's not, if you wish to run it outside the suite, execute 'lago ovirt serve'. Or you can enable the regular repos of the VMs and exclude the internal ones when calling yum commands. Y.
Yaniv,
When first reading your answer, and reading that engine:/etc/yum.repos.d/lago.conf is pointing to 192.168.200.1 (the bare-metal host), I understood that the bare-metal host was the one that had to http-serve the packages.
But on this bare-metal host, I find no httpd package installed, nor /etc/httpd, neither /var/www/html.
Right, it's an internal, Python web-server, part of ovirtlago.
OK
But I find it on the engine VM.
I don't get it.
Moreover, when going under the deployment_blahblah_prefix dir, and running lago ovirt serve, nothing is happening, the command gets stuck.
Under current?
No, I meant under deployment_blah_blah_blah/current Y.
Is your question the version?
lago --version lago 0.25.0
I made a git pull yesterday.
When running a dnf update, I see that there's a lago 0.26.0-1.fc24 upgrade pending, so I may try this.
Y.
May you enlighten this please ?
-- Nicolas ECARNOT
-- Nicolas ECARNOT
Le 14/10/2016 à 23:01, Yaniv Kaul a écrit :
On Fri, Oct 14, 2016 at 4:28 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Le 14/10/2016 à 15:03, Yaniv Kaul a écrit :
On Fri, Oct 14, 2016 at 3:00 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net> <mailto:nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>>> wrote:
Le 30/09/2016 à 20:18, Yaniv Kaul a écrit :
When lago is executing a suite, it is making sure the web server is running and serving the repo. When it's not, if you wish to run it outside the suite, execute 'lago ovirt serve'. Or you can enable the regular repos of the VMs and exclude the internal ones when calling yum commands. Y.
Yaniv,
When first reading your answer, and reading that engine:/etc/yum.repos.d/lago.conf is pointing to 192.168.200.1 (the bare-metal host), I understood that the bare-metal host was the one that had to http-serve the packages.
But on this bare-metal host, I find no httpd package installed, nor /etc/httpd, neither /var/www/html.
Right, it's an internal, Python web-server, part of ovirtlago.
OK
But I find it on the engine VM.
I don't get it.
Moreover, when going under the deployment_blahblah_prefix dir, and running lago ovirt serve, nothing is happening, the command gets stuck.
Under current?
No, I meant under deployment_blah_blah_blah/current
Sorry. Yes, it was under current. Anyway, I upgraded to 0.26.0-1. Made another wipe+run, and tried "ovirt serve". Apart a package error I had to ignore, it looks like the engine was able to get its package from the server, so I guess it is working. Actually, I was expecting this command to run in the background and give me my prompt back, but no, it is staying listening for request, I guess. That's OK for me.
Y.
Is your question the version?
lago --version lago 0.25.0
I made a git pull yesterday.
When running a dnf update, I see that there's a lago 0.26.0-1.fc24 upgrade pending, so I may try this.
Y.
May you enlighten this please ?
-- Nicolas ECARNOT
-- Nicolas ECARNOT
-- Nicolas ECARNOT
Le 21/09/2016 à 15:49, Yaniv Kaul a écrit :
Adding the Lago devel mailing list.
The download is the reposync phase - which seems to be OK, but then the connection means that for some reason Lago is not serving those RPMs (8585 is the port it should be listening to). Can you share some logs?
http://pastebin.com/nsDFZhuE One thing to note : when trying to run again the same command ("./run_suite.sh basic_suite_3.6"), the script is breaking when trying to create the lago network : * Create network lago_basic_suite_3_6_lago: libvirt: error : internal error: Network is already in use by interface 8938-930e31b * Create network lago_basic_suite_3_6_lago: ERROR (in 0:00:00) # Start nets: ERROR (in 0:00:00) @ Start Prefix: ERROR (in 0:00:00) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 691, in main cli_plugins[args.verb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 488, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 499, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 255, in do_start prefix.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 958, in start self.virt_env.start(vm_names=vm_names) File "/usr/lib/python2.7/site-packages/lago/virt.py", line 170, in start net.start() File "/usr/lib/python2.7/site-packages/lago/virt.py", line 339, in start self.libvirt_con.networkCreateXML(self._libvirt_xml()) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4209, in networkCreateXML if ret is None:raise libvirtError('virNetworkCreateXML() failed', conn=self) libvirtError: internal error: Network is already in use by interface 8938-930e31b I tried to ifdown this interface, but that does not seem to be enough.
TIA, Y.
On Wed, Sep 21, 2016 at 4:25 PM, Nicolas Ecarnot <nicolas@ecarnot.net <mailto:nicolas@ecarnot.net>> wrote:
Hello Yaniv,
Following your recommendation, I install a new bare metal host, installed F24, then followed the lago.readthedoc web site.
When running ./run_suite.sh basic_suite_3.6 , things seems to go right (downloading...) for a while, then begin some errors about accessing 192.168.200.1:8585 <http://192.168.200.1:8585>
May you tell me where would be the best place to ask some help about Lago ? (IRC, mailing list, e-mail... ?)
Best regards,
-- Nicolas ECARNOT
-- Nicolas ECARNOT
participants (4)
-
Nadav Goldin -
Nicolas Ecarnot -
Yaniv Kaul -
Yedidyah Bar David