8:15 a.m.
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?
Regards,
Jose Garcia
8:34 a.m.
On 06/27/2012 04:15 PM, jose garcia wrote:
Are you referring to the "installVds" option at vdc_options?
When I don't want to install a host but do want to add it to my system,
and I have ovirtmgmt bridge on the host , I turn this option off, and
then I simply add the host.
However, I don't thikn that this is the standard procedure, it's just an
available option.
3:55 a.m.
This is a multi-part message in MIME format.
--------------090806090404090004090801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 06/28/2012 02:43 AM, Itamar Heim wrote:
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.
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?
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
--------------090806090404090004090801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/28/2012 02:43 AM, Itamar Heim
wrote:<br>
</div>
<blockquote cite="mid:4FEBB6D9.4000802@redhat.com"
type="cite">On
06/27/2012 09:15 AM, jose garcia wrote:
<br>
<blockquote type="cite">Good evening to all,
<br>
<br>
I have added two nodes of Fedora 17 with vdsm 4.10 installed to
oVirt
<br>
3.1 engine. I was having problems
<br>
with SSL, so I have disabled it. When I added the nodes there
was no
<br>
attempt of installation as it was
<br>
the case with oVirt 3.0, but the nodes get activated, provided
that
<br>
ovirtmgmt bridge is present.
<br>
<br>
I have been told that there is a configuration in the database
that make
<br>
this happen. I just recreated the
<br>
database via the script /dbscripts/create_db_devel.sh and run
<br>
engine-setup, after removing all packages from oVirt 3.0 and
jboss and
<br>
installing ovirt 3.1 basic packages.
<br>
<br>
My question is: What would be the 'standard' procedure to get
oVirt 3.1
<br>
running?
<br>
</blockquote>
<br>
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
<br>
</blockquote>
<br>
Good morning,<br>
<br>
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.<br>
<br>
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): <br>
<br>
when trying to connect without specifying the uri (qemu:///system)
it gives segmentation fault. If it is given it asks for user and
password. <br>
<br>
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. <br>
<br>
It is required to use sasl or to add a sasl user in the engine, in
the hosts or in both?<br>
<br>
vdsm.log reads:<br>
<br>
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<br>
Thread-70::DEBUG::2012-06-27
18:57:25,531::vm::580::vm.Vm::(_startUnderlyingVm)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::_ongoingCreations
released<br>
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<br>
Traceback (most recent call last):<br>
File "/usr/share/vdsm/vm.py", line 570, in
_startUnderlyingVm<br>
self._run()<br>
File "/usr/share/vdsm/libvirtvm.py", line 1364, in
_run<br>
self._connection.createXML(domxml, flags),<br>
File
"/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py",
line 82, in wrapper<br>
ret = f(*args, **kwargs)<br>
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2420,
in createXML<br>
if ret is None:raise
libvirtError('virDomainCreateXML() failed',
conn=self)<br>
<b>libvirtError: internal error unsupported configuration: Readonly
leases are not supported</b><br>
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<br>
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',) {}<br>
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}]}<br>
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',) {}<br>
Thread-76::<a class="moz-txt-link-freetext"
href="INFO::2012-06-27">INFO::2012-06-27</a>
18:57:27,595::API::317::vds::(destroy)
vmContainerLock acquired by vm 32339151-23ed-4cc3-ada4-0f540ab81a97<br>
Thread-76::DEBUG::2012-06-27
18:57:27,595::libvirtvm::2085::vm.Vm::(destroy)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::destroy Called<br>
Thread-76::<a class="moz-txt-link-freetext"
href="INFO::2012-06-27">INFO::2012-06-27</a>
18:57:27,595::libvirtvm::2040::vm.Vm::(releaseVm)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::Release VM resources<br>
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<br>
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'<br>
<br>
And there is a log in /var/log/libvirt/qemu for the VM that says:<br>
<br>
starting up<br>
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<br>
<b>libvir: Locking error : unsupported configuration: Readonly
leases are not supported</b><br>
2012-06-27 17:57:28.241+0000: shutting down<br>
<br>
<br>
<br>
</body>
</html>
--------------090806090404090004090801--
4:03 a.m.
This is a multi-part message in MIME format.
--------------090401040101080908060106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 06/28/2012 09:55 AM, jose garcia wrote:
Sorry for that, after reboot of the engine and the nodes I can boot the
VM, but what would be required to use sasl, which is the the default?
--------------090401040101080908060106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/28/2012 09:55 AM, jose garcia
wrote:<br>
</div>
<blockquote cite="mid:4FEC1BF1.1070005@gmail.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 06/28/2012 02:43 AM, Itamar Heim
wrote:<br>
</div>
<blockquote cite="mid:4FEBB6D9.4000802@redhat.com"
type="cite">On
06/27/2012 09:15 AM, jose garcia wrote: <br>
<blockquote type="cite">Good evening to all, <br>
<br>
I have added two nodes of Fedora 17 with vdsm 4.10 installed
to oVirt <br>
3.1 engine. I was having problems <br>
with SSL, so I have disabled it. When I added the nodes there
was no <br>
attempt of installation as it was <br>
the case with oVirt 3.0, but the nodes get activated, provided
that <br>
ovirtmgmt bridge is present. <br>
<br>
I have been told that there is a configuration in the database
that make <br>
this happen. I just recreated the <br>
database via the script /dbscripts/create_db_devel.sh and run
<br>
engine-setup, after removing all packages from oVirt 3.0 and
jboss and <br>
installing ovirt 3.1 basic packages. <br>
<br>
My question is: What would be the 'standard' procedure to get
oVirt 3.1 <br>
running? <br>
</blockquote>
<br>
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 <br>
</blockquote>
<br>
Good morning,<br>
<br>
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.<br>
<br>
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): <br>
<br>
when trying to connect without specifying the uri (qemu:///system)
it gives segmentation fault. If it is given it asks for user and
password. <br>
<br>
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. <br>
<br>
It is required to use sasl or to add a sasl user in the engine, in
the hosts or in both?<br>
<br>
vdsm.log reads:<br>
<br>
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<br>
Thread-70::DEBUG::2012-06-27
18:57:25,531::vm::580::vm.Vm::(_startUnderlyingVm)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::_ongoingCreations
released<br>
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<br>
Traceback (most recent call last):<br>
File "/usr/share/vdsm/vm.py", line 570, in
_startUnderlyingVm<br>
self._run()<br>
File "/usr/share/vdsm/libvirtvm.py", line 1364, in
_run<br>
self._connection.createXML(domxml, flags),<br>
File
"/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line
82, in wrapper<br>
ret = f(*args, **kwargs)<br>
File "/usr/lib64/python2.7/site-packages/libvirt.py", line
2420,
in createXML<br>
if ret is None:raise
libvirtError('virDomainCreateXML()
failed', conn=self)<br>
<b>libvirtError: internal error unsupported configuration:
Readonly leases are not supported</b><br>
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<br>
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',) {}<br>
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}]}<br>
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',) {}<br>
Thread-76::<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="INFO::2012-06-27">INFO::2012-06-27</a>
18:57:27,595::API::317::vds::(destroy) vmContainerLock acquired by
vm 32339151-23ed-4cc3-ada4-0f540ab81a97<br>
Thread-76::DEBUG::2012-06-27
18:57:27,595::libvirtvm::2085::vm.Vm::(destroy)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::destroy Called<br>
Thread-76::<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="INFO::2012-06-27">INFO::2012-06-27</a>
18:57:27,595::libvirtvm::2040::vm.Vm::(releaseVm)
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::Release VM resources<br>
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<br>
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'<br>
<br>
And there is a log in /var/log/libvirt/qemu for the VM that says:<br>
<br>
starting up<br>
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<br>
<b>libvir: Locking error : unsupported configuration: Readonly
leases are not supported</b><br>
2012-06-27 17:57:28.241+0000: shutting down<br>
<br>
<br>
<br>
</blockquote>
Sorry for that, after reboot of the engine and the nodes I can boot
the VM, but what would be required to use sasl, which is the the
default?<br>
<br>
</body>
</html>
--------------090401040101080908060106--
5:33 a.m.
On 06/28/2012 04:55 AM, jose garcia wrote:
yes.
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 any
of its configuration parameters affecting installation process)
thanks
6:55 a.m.
This is a multi-part message in MIME format.
--------------030302060001010106070800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 06/28/2012 11:33 AM, Itamar Heim wrote:
I apologize for mixing up things, but had the clean install of the node
worked I would never have tweaked anything. SSL was not working for me
so I had to disable it. If in the first connection to the node there is
an error related to SSL it is not probable that the engine can configure
certificates or anything. Meanwhile I have found the problem with the VM
don't booting, which is a bug in the sanlock libvirt feature reported in
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=828633. To
attach an iso there is a workaround updating libvirt with the version in
updates-testing and, maybe, tweaking /etc/libvirt/qemu-sanlock.conf.
This does not sound as the out-of-the-box kind of thing to me. Anyway,
the tweak worked but the installed machine won't first-time boot and I
am at the moment wondering why//the log is showing: /managed non
plugable/(sic)/device was removed unexpetedly/(sic)/from libvirt/.
I can imagine how difficult is the development process. What I know is
that testing software is not an easy thing either and you can't sit and
wait for a solution to come out of some box. What I am trying is to test
the basic features of the new version, no more. I am not trying to tune
it in any way.
Regards
--------------030302060001010106070800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/28/2012 11:33 AM, Itamar Heim
wrote:<br>
</div>
<blockquote cite="mid:4FEC32F3.2070701@redhat.com"
type="cite">On
06/28/2012 04:55 AM, jose garcia wrote:
<br>
<blockquote type="cite">On 06/28/2012 02:43 AM, Itamar Heim wrote:
<br>
<blockquote type="cite">On 06/27/2012 09:15 AM, jose garcia
wrote:
<br>
<blockquote type="cite">Good evening to all,
<br>
<br>
I have added two nodes of Fedora 17 with vdsm 4.10 installed
to oVirt
<br>
3.1 engine. I was having problems
<br>
with SSL, so I have disabled it. When I added the nodes
there was no
<br>
attempt of installation as it was
<br>
the case with oVirt 3.0, but the nodes get activated,
provided that
<br>
ovirtmgmt bridge is present.
<br>
<br>
I have been told that there is a configuration in the
database that make
<br>
this happen. I just recreated the
<br>
database via the script /dbscripts/create_db_devel.sh and
run
<br>
engine-setup, after removing all packages from oVirt 3.0 and
jboss and
<br>
installing ovirt 3.1 basic packages.
<br>
<br>
My question is: What would be the 'standard' procedure to
get oVirt 3.1
<br>
running?
<br>
</blockquote>
<br>
the standard procedure would be to install the rpm and
engine-setup
<br>
and add the host from UI so they will be configured with
certificates
<br>
and ssl
<br>
</blockquote>
<br>
Good morning,
<br>
<br>
I wanted to know if there will be an installation process from
scratch
<br>
with a reboot for the hosts as there was in 3.0.
<br>
</blockquote>
<br>
yes.
<br>
<br>
<blockquote type="cite">
<br>
I have an issue that may also be related to authentication. I am
unable
<br>
to start my newly created VM. The engine seems to connect to
libvirt in
<br>
read-only mode, and boot of the virtual Machine fails. There is
<br>
something quaint in virsh (Fedora 17 in the hosts):
<br>
<br>
when trying to connect without specifying the uri
(qemu:///system) it
<br>
gives segmentation fault. If it is given it asks for user and
password.
<br>
<br>
Tried to disable sasl in libvirtd.conf and now I can connect
with virsh
<br>
to the default uri without providing a password, but booting of
the vm
<br>
keeps failing.
<br>
<br>
It is required to use sasl or to add a sasl user in the engine,
in the
<br>
hosts or in both?
<br>
</blockquote>
<br>
everything should work out of the box without tweaking config
files.
<br>
however, i'm not sure we will work correctly if they were tweaked
manually.
<br>
<br>
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 any of its configuration parameters affecting installation
process)
<br>
thanks
<br>
<br>
</blockquote>
<br>
I apologize for mixing up things, but had the clean install of the
node worked I would never have tweaked anything. SSL was not working
for me so I had to disable it. If in the first connection to the
node there is an error related to SSL it is not probable that the
engine can configure certificates or anything. Meanwhile I have
found the problem with the VM don't booting, which is a bug in the
sanlock libvirt feature reported in
<a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?format=multiple&a...;.
To attach an iso there is a workaround updating libvirt with the
version in updates-testing and, maybe, tweaking
/etc/libvirt/qemu-sanlock.conf. This does not sound as the
out-of-the-box kind of thing to me. Anyway, the tweak worked but the
installed machine won't first-time boot and I am at the moment
wondering why<i> </i>the log is showing: <i>managed non
plugable</i>(sic)<i>
device was removed unexpetedly</i>(sic)<i> from libvirt</i>.
<br>
<br>
I can imagine how difficult is the development process. What I know
is that testing software is not an easy thing either and you can't
sit and wait for a solution to come out of some box. What I am
trying is to test the basic features of the new version, no more. I
am not trying to tune it in any way.<br>
<br>
Regards<br>
<br>
<blockquote cite="mid:4FEC32F3.2070701@redhat.com"
type="cite">
<blockquote type="cite">
<br>
vdsm.log reads:
<br>
<br>
Thread-72::DEBUG::2012-06-27
<br>
18:57:25,511::task::978::TaskManager.Task::(_decref)
<br>
Task=`e92b65bc-b9fe-492f-b77c-397321dbb105`::ref 0 aborting
False
<br>
Thread-70::DEBUG::2012-06-27
<br>
18:57:25,531::vm::580::vm.Vm::(_startUnderlyingVm)
<br>
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::_ongoingCreations
released
<br>
Thread-70::ERROR::2012-06-27
<br>
18:57:25,532::vm::604::vm.Vm::(_startUnderlyingVm)
<br>
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::The vm start
process failed
<br>
Traceback (most recent call last):
<br>
File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm
<br>
self._run()
<br>
File "/usr/share/vdsm/libvirtvm.py", line 1364, in _run
<br>
self._connection.createXML(domxml, flags),
<br>
File
"/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py",
line
<br>
82, in wrapper
<br>
ret = f(*args, **kwargs)
<br>
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2420,
in
<br>
createXML
<br>
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
<br>
*libvirtError: internal error unsupported configuration:
Readonly leases
<br>
are not supported*
<br>
Thread-70::DEBUG::2012-06-27
<br>
18:57:25,542::vm::920::vm.Vm::(setDownStatus)
<br>
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::Changed state to
Down:
<br>
internal error unsupported configuration: Readonly leases are
not supported
<br>
Thread-75::DEBUG::2012-06-27
<br>
18:57:27,588::BindingXMLRPC::859::vds::(wrapper) client
<br>
[10.10.30.101]::call vmGetStats with
<br>
('32339151-23ed-4cc3-ada4-0f540ab81a97',) {}
<br>
Thread-75::DEBUG::2012-06-27
<br>
18:57:27,588::BindingXMLRPC::865::vds::(wrapper) return
vmGetStats with
<br>
{'status': {'message': 'Done', 'code': 0},
'statsList':
[{'status':
<br>
'Down', 'hash': '0', 'exitMessage': 'internal
error unsupported
<br>
configuration: Readonly leases are not supported', 'vmId':
<br>
'32339151-23ed-4cc3-ada4-0f540ab81a97', 'timeOffset':
'0',
'exitCode': 1}]}
<br>
Thread-76::DEBUG::2012-06-27
<br>
18:57:27,594::BindingXMLRPC::859::vds::(wrapper) client
<br>
[10.10.30.101]::call vmDestroy with
<br>
('32339151-23ed-4cc3-ada4-0f540ab81a97',) {}
<br>
Thread-76::<a class="moz-txt-link-freetext"
href="INFO::2012-06-27">INFO::2012-06-27</a>
18:57:27,595::API::317::vds::(destroy)
<br>
vmContainerLock acquired by vm
32339151-23ed-4cc3-ada4-0f540ab81a97
<br>
Thread-76::DEBUG::2012-06-27
<br>
18:57:27,595::libvirtvm::2085::vm.Vm::(destroy)
<br>
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::destroy Called
<br>
Thread-76::<a class="moz-txt-link-freetext"
href="INFO::2012-06-27">INFO::2012-06-27</a>
<br>
18:57:27,595::libvirtvm::2040::vm.Vm::(releaseVm)
<br>
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::Release VM
resources
<br>
Thread-76::WARNING::2012-06-27
<br>
18:57:27,596::vm::328::vm.Vm::(_set_lastStatus)
<br>
vmId=`32339151-23ed-4cc3-ada4-0f540ab81a97`::trying to set state
to
<br>
Powering down when already Down
<br>
Thread-76::DEBUG::2012-06-27
<br>
18:57:27,596::__init__::1249::Storage.Misc.excCmd::(_log)
'/usr/bin/sudo
<br>
-n /usr/sbin/service ksmtuned retune'
<br>
<br>
And there is a log in /var/log/libvirt/qemu for the VM that
says:
<br>
<br>
starting up
<br>
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
<br>
QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -S -M pc-0.14 -cpu
<br>
kvm64,+lahf_lm,+ssse3,-cx16 -enable-kvm -m 1024 -smp
<br>
1,sockets=1,cores=1,threads=1 -name fedora-test -uuid
<br>
32339151-23ed-4cc3-ada4-0f540ab81a97 -smbios
type=1,manufacturer=Red
<br>
Hat,product=RHEV
<br>
Hypervisor,version=17-1,serial=03000200-0400-0500-0006-000700080009_00:30:18:a8:a8:42,uuid=32339151-23ed-4cc3-ada4-0f540ab81a97
<br>
-nodefconfig -nodefaults -chardev
<br>
socket,id=charmonitor,path=/var/lib/libvirt/qemu/fedora-test.monitor,server,nowait
<br>
-mon chardev=charmonitor,id=monitor,mode=control -rtc
<br>
base=2012-06-27T17:57:28,driftfix=slew -no-shutdown -device
<br>
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
<br>
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive
<br>
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=
<br>
-device
<br>
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
<br>
-drive
<br>
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
<br>
-device
<br>
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2
<br>
-netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device
<br>
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:51,bus=pci.0,addr=0x3,bootindex=3
<br>
-chardev
<br>
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/fedora-test.com.redhat.rhevm.vdsm,server,nowait
<br>
-device
<br>
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
<br>
-chardev spicevmc,id=charchannel1,name=vdagent -device
<br>
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0
<br>
-chardev pty,id=charconsole0 -device
<br>
virtconsole,chardev=charconsole0,id=console0 -spice
port=5900,addr=0 -k
<br>
en-us -vga qxl -global qxl-vga.vram_size=67108864 -device
<br>
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
<br>
*libvir: Locking error : unsupported configuration: Readonly
leases are
<br>
not supported*
<br>
2012-06-27 17:57:28.241+0000: shutting down
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</body>
</html>
--------------030302060001010106070800--
2:06 p.m.
On 06/28/2012 07:55 AM, jose garcia wrote:
i didn't mean to imply you did something wrong, and i appreciate you are
trying to make it work.
however, it will be easier to try and identify your issue if you can try
to run the installation on a cleanly installed fedora 17 host.
thanks,
Itamar
3:13 a.m.
On 06/28/2012 08:06 PM, Itamar Heim wrote:
Good morning,
It's all right. I will try to retake the easy way whenever i can. At the
moment, I have the engine working
with two nodes and without any security authentication. The general
performance seems to have been improved. I think the user portal has new
features. I would like to know if it's fully operative in order to take
the time to have a look at it.
I am having some trouble installing VMs but I don't think they are
directly related to oVirt and if one of my servers refrained from
rebooting randomly everything would be easier. My feeling is that the
project is advancing.
Cheers,
Jose Garcia
4665
days inactive
4667
days old
8 comments
3 participants
participants (3)
-
Itamar Heim -
jose garcia -
Yair Zaslavsky