<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&amp;id=828633">https://bugzilla.redhat.com/show_bug.cgi?format=multiple&amp;id=828633</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>
    &nbsp; &nbsp; <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>