Re: [Users] Addition of nodes to oVirt-engine

Itamar Heim Thu, 28 Jun 2012 03:33:29 -0700

On 06/28/2012 04:55 AM, jose garcia wrote:

On 06/28/2012 02:43 AM, Itamar Heim wrote:

On 06/27/2012 09:15 AM, jose garcia wrote:

Good evening to all,


I have added two nodes of Fedora 17 with vdsm 4.10 installed to oVirt
3.1 engine. I was having problems
with SSL, so I have disabled it. When I added the nodes there was no
attempt of installation as it was
the case with oVirt 3.0, but the nodes get activated, provided that
ovirtmgmt bridge is present.

I have been told that there is a configuration in the database that make
this happen. I just recreated the
database via the script /dbscripts/create_db_devel.sh and run
engine-setup, after removing all packages from oVirt 3.0 and jboss and
installing ovirt 3.1 basic packages.

My question is: What would be the 'standard' procedure to get oVirt 3.1
running?


the standard procedure would be to install the rpm and engine-setup
and add the host from UI so they will be configured with certificates
and ssl


Good morning,

I wanted to know if there will be an installation process from scratch
with a reboot for the hosts as there was in 3.0.


yes.


I have an issue that may also be related to authentication. I am unable
to start my newly created VM. The engine seems to connect to libvirt in
read-only mode, and boot of the virtual Machine fails. There is
something quaint in virsh (Fedora 17 in the hosts):

when trying to connect without specifying the uri (qemu:///system) it
gives segmentation fault. If it is given it asks for user and password.

Tried to disable sasl in libvirtd.conf and now I can connect with virsh
to the default uri without providing a password, but booting of the vm
keeps failing.

It is required to use sasl or to add a sasl user in the engine, in the
hosts or in both?


everything should work out of the box without tweaking config files.
however, i'm not sure we will work correctly if they were tweaked manually.

please try a clean install of your node, then add it from the UI(assuming you did a clean rpm install of the engine and didn't tweak anyof its configuration parameters affecting installation process)

thanks


vdsm.log reads:

Thread-72::DEBUG::2012-06-27
18:57:25,511::task::978::TaskManager.Task::(_decref)
Task=`e92b65bc-b9fe-492f-b77c-397321dbb105`::ref 0 aborting False
Thread-70::DEBUG::2012-06-27
18:57:25,531::vm::580::vm.Vm::(_startUnderlyingVm)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::_ongoingCreations released
Thread-70::ERROR::2012-06-27
18:57:25,532::vm::604::vm.Vm::(_startUnderlyingVm)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::The vm start process failed
Traceback (most recent call last):
File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm
self._run()
File "/usr/share/vdsm/libvirtvm.py", line 1364, in _run
self._connection.createXML(domxml, flags),
File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line
82, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2420, in
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
*libvirtError: internal error unsupported configuration: Readonly leases
are not supported*
Thread-70::DEBUG::2012-06-27
18:57:25,542::vm::920::vm.Vm::(setDownStatus)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::Changed state to Down:
internal error unsupported configuration: Readonly leases are not supported
Thread-75::DEBUG::2012-06-27
18:57:27,588::BindingXMLRPC::859::vds::(wrapper) client
[10.10.30.101]::call vmGetStats with
('32339151-23ed-4cc3-ada4-0f540ab81a97',) {}
Thread-75::DEBUG::2012-06-27
18:57:27,588::BindingXMLRPC::865::vds::(wrapper) return vmGetStats with
{'status': {'message': 'Done', 'code': 0}, 'statsList': [{'status':
'Down', 'hash': '0', 'exitMessage': 'internal error unsupported
configuration: Readonly leases are not supported', 'vmId':
'32339151-23ed-4cc3-ada4-0f540ab81a97', 'timeOffset': '0', 'exitCode': 1}]}
Thread-76::DEBUG::2012-06-27
18:57:27,594::BindingXMLRPC::859::vds::(wrapper) client
[10.10.30.101]::call vmDestroy with
('32339151-23ed-4cc3-ada4-0f540ab81a97',) {}
Thread-76::INFO::2012-06-27 18:57:27,595::API::317::vds::(destroy)
vmContainerLock acquired by vm 32339151-23ed-4cc3-ada4-0f540ab81a97
Thread-76::DEBUG::2012-06-27
18:57:27,595::libvirtvm::2085::vm.Vm::(destroy)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::destroy Called
Thread-76::INFO::2012-06-27
18:57:27,595::libvirtvm::2040::vm.Vm::(releaseVm)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::Release VM resources
Thread-76::WARNING::2012-06-27
18:57:27,596::vm::328::vm.Vm::(_set_lastStatus)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::trying to set state to
Powering down when already Down
Thread-76::DEBUG::2012-06-27
18:57:27,596::__init__::1249::Storage.Misc.excCmd::(_log) '/usr/bin/sudo
-n /usr/sbin/service ksmtuned retune'

And there is a log in /var/log/libvirt/qemu for the VM that says:

starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -S -M pc-0.14 -cpu
kvm64,+lahf_lm,+ssse3,-cx16 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name fedora-test -uuid
32339151-23ed-4cc3-ada4-0f540ab81a97 -smbios type=1,manufacturer=Red
Hat,product=RHEV
Hypervisor,version=17-1,serial=03000200-0400-0500-0006-000700080009_00:30:18:a8:a8:42,uuid=32339151-23ed-4cc3-ada4-0f540ab81a97
-nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/fedora-test.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=2012-06-27T17:57:28,driftfix=slew -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive
file=/rhev/data-center/ee37f596-bf78-11e1-94ba-7309589a8ec2/891fa5d3-ceff-4711-8538-9bccd018969c/images/11111111-1111-1111-1111-111111111111/Fedora-16-x86_64-Live-KDE.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial=
-device
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
-drive
file=/rhev/data-center/ee37f596-bf78-11e1-94ba-7309589a8ec2/cdd28fda-e2fa-4ce4-9805-566ad7d69df2/images/81d0b868-9e5c-4ed8-9ac0-db6982da5de1/80a356f1-0932-4d54-be81-e112720c60b0,if=none,id=drive-virtio-disk0,format=raw,serial=81d0b868-9e5c-4ed8-9ac0-db6982da5de1,cache=none,werror=stop,rerror=stop,aio=threads
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2
-netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:51,bus=pci.0,addr=0x3,bootindex=3
-chardev
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/fedora-test.com.redhat.rhevm.vdsm,server,nowait
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
-chardev spicevmc,id=charchannel1,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0
-chardev pty,id=charconsole0 -device
virtconsole,chardev=charconsole0,id=console0 -spice port=5900,addr=0 -k
en-us -vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
*libvir: Locking error : unsupported configuration: Readonly leases are
not supported*
2012-06-27 17:57:28.241+0000: shutting down


_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Addition of nodes to oVirt-engine

Reply via email to