[Users] Users Digest, Vol 13, Issue 17
Jonathan Larson
jlarson at innovativecrest.com
Sat Oct 6 16:36:49 UTC 2012
-----Original Message-----
From: users-request at ovirt.org [users-request at ovirt.org]
Received: Saturday, 06 Oct 2012, 12:00
To: users at ovirt.org [users at ovirt.org]
Subject: Users Digest, Vol 13, Issue 17
Send Users mailing list submissions to
users at ovirt.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ovirt.org/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at ovirt.org
You can reach the person managing the list at
users-owner at ovirt.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."
Today's Topics:
1. Re: Nightly Builds, was Authentication for REST APIs?
(Steve Gordon)
2. Re: Ceph / rbd and ovirt (Ayal Baron)
3. Re: [Spice-devel] mouse problem with muiltiple monitors (was
HowTo: Spice ActiveX Plugin/Virt Viewer Console on oVirt 3.1)
(Dead Horse)
4. Re: fw: Migrating ovirt-engine to new server (Juan Hernandez)
----------------------------------------------------------------------
Message: 1
Date: Fri, 5 Oct 2012 14:02:19 -0400 (EDT)
From: Steve Gordon <sgordon at redhat.com>
To: Brian Vetter <bjvetter at gmail.com>
Cc: users at ovirt.org
Subject: Re: [Users] Nightly Builds, was Authentication for REST APIs?
Message-ID: <372383135.7069086.1349460139686.JavaMail.root at redhat.com>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
> From: "Brian Vetter" <bjvetter at gmail.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: users at ovirt.org
> Sent: Friday, October 5, 2012 12:03:13 PM
> Subject: Re: [Users] Nightly Builds, was Authentication for REST APIs?
>
> I found instructions on the wiki for using nightly builds at:
>
> http://wiki.ovirt.org/wiki/Installing_ovirt-engine_from_rpm
>
> The instructions didn't work. In particular, the ovirt-engine.repo
> file was not found at the provided url.
> http://www.ovirt.org/releases/nightly/fedora/16/ovirt-engine.repo
>
> I did find an ovirt-engine.repo file at:
> http://www.ovirt.org/releases/nightly/rpm/Fedora/17/ovirt-engine.repo
>
> The contents of that repo file point it back to the
> releases/3.1/rpm/Fedora/17 directory. I'm presuming that if I change
> the baseurl to releases/nightly/rpm/... it will all work (which I'll
> be doing this afternoon).
>
> In any case, someone might want to fix the ovirt-engine.repo file in
> the nightly tree and then update the urls in the wiki.
>
> Brian
I would recommend using this package to install the repo file:
http://www.ovirt.org/releases/ovirt-release-fedora.noarch.rpm
It includes definitions for both the stable and nightly repositories - defaulting to stable. You can:
yum install ovirt-engine --enablerepo=ovirt-nightly
Or enable it in the /etc/yum.repos.d/ovirt.repo file. Agree that the other repo files littering the directory structure should be cleaned up (I thought they already had been). Who has access to do that?
Steve
------------------------------
Message: 2
Date: Fri, 5 Oct 2012 20:02:46 -0400 (EDT)
From: Ayal Baron <abaron at redhat.com>
To: Josh Logan <joshtlogan at gmail.com>
Cc: users at ovirt.org
Subject: Re: [Users] Ceph / rbd and ovirt
Message-ID: <887641321.6918996.1349481766537.JavaMail.root at redhat.com>
Content-Type: text/plain; charset=utf-8
Hi Josh,
----- Original Message -----
>
>
>
> On Sun, Sep 23, 2012 at 8:41 AM, Itamar Heim < iheim at redhat.com >
> wrote:
>
>
>
> On 09/23/2012 05:33 PM, Josh Logan wrote:
>
>
>
>
> On Sun, Sep 23, 2012 at 6:10 AM, Itamar Heim < iheim at redhat.com
>
>
> <mailto: iheim at redhat.com >> wrote:
>
> On 09/22/2012 08:58 AM, Josh Logan wrote:
>
>
> I'm currently setting up an ovirt cluster and so far it looks
> good. I
> like the integration with Foreman http://theforeman.org/ .
>
> I would like to use Ceph / rbd for my storage. I saw some
> mention of
> patches coming in May, but I did not find any new posts.
>
> What is the status of this work? Is there some patches I can
> try out?
> I have a working Ceph cluster and a working ovirt cluster, I
> just need a
> way to bring them together.
>
> Thanks, JOSH
>
>
>
> I don't remember any active work on this right now (for sure nothing
> like the gluster integration being done).
> but iiuc, ceph provides posixfs support - did you try creating a
> posixfs based storage domain?
> (you would need a "full" host (not ovirt-node) to install ceph
> client components on).
>
> Thanks,
> Itamar
>
>
>
> I am doing my work on Fedora 17 hosts, not ovirt-node, since I know
> this
> will need more OS support.
>
> There are a few different Ceph filesystems. But the posix based one
> is
> the least ready for production. The rbd filesystem is integrated into
> qemu and libvirt is the most suited for VM images.
>
> Are the Gluster patches available? I would like to see what that
> feature looks like and if I can modify them for Ceph.
> If there is a better filesystem to investigate please let me know.
>
> Thanks, JOSH
>
>
> gluster as a native storage domain (rather than posixfs) is still in
> reviews (and has patches only for vdsm side).
> http://gerrit.ovirt.org/#/c/ 6856/
>
> you can also use NFS in the meantime if relevant for ceph.
>
>
>
> Thanks for the pointer. I'll follow that and see what I learn.
>
> The vdsm side may be similar since both are network disk device.
> There are only 2 steps needed to start up a VM with rbd.
>
> qemu-img create -f rbd rbd:data/host1 10G
>
> Then to start the image for qemu add -drive
> file=rbd:data/host1,if=none,id=drive-virtio-disk0,format=raw
>
> or within libvirt:
> <disk type='network' device='disk'>
> <driver name='qemu' type='raw'/>
> <source protocol='rbd' name='data/host1'/>
> <target dev='vda' bus='virtio'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
> function='0x0'/>
> </disk>
>
> So the steps are simple, and maybe Gluster is more complex then I
> should use as an example.
Have you followed up on this?
Do you need more pointers?
Regards,
Ayal.
>
> Thanks, JOSH
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
------------------------------
Message: 3
Date: Fri, 5 Oct 2012 21:34:00 -0500
From: Dead Horse <deadhorseconsulting at gmail.com>
To: Christophe Fergeau <cfergeau at redhat.com>
Cc: spice-devel at lists.freedesktop.org, "<users at ovirt.org>"
<users at ovirt.org>
Subject: Re: [Users] [Spice-devel] mouse problem with muiltiple
monitors (was HowTo: Spice ActiveX Plugin/Virt Viewer Console on oVirt
3.1)
Message-ID:
<CAEWPe=p8Xf3uYHDbD5uAz46i-OnHJxfYxrzJ-XkNc64GfwtjBQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I've actually started to notice that this occurs natively as well (I rarely
if ever use the activex console on a native windows install). However I
have noted that with a Native Windows install and the Activex Remote Viewer
version 0.5.3 that alot of guests have mouse issues w/o spice vdagent or
the windows spice agent in place (very annoying during LFC guests with no
knowledge of "spice mice"). Windows installs can be slipstreamed with the
spice drivers to fix this but thats really a pain. Linux guests however not
as easy. This actually seems to a repeat of this issue:
http://lists.ovirt.org/pipermail/users/2012-February/000351.html (for which
a fix was applied to windows spicec + activex NOT remote-viewer) possible
regression? Using the usbtablet custom vdsm hook does indeed solve issues
with guests that encounter this issue. I have noted it within older linux
guests (no surprise they know nothing of a spice mouse), windows guests,
solaris guests, some of the older opensuse and ubuntu as well as fedora.
The most confusing one was RHEL 6.x which without the spice vdagent loaded
will experience the cursor jumping in and out of the window or randomly on
the spice display. I note the one downside of the usbtablet is that power
users are able to view custom hooks in the PUP UI, but cannot set them as
only the "admin role" not "user role" can do this. That is to say the power
user can look at and even set the hook but is stopped short of committing
it to the VM settings.
- DHC
On Fri, Oct 5, 2012 at 5:18 AM, Christophe Fergeau <cfergeau at redhat.com>wrote:
> On Thu, Sep 13, 2012 at 12:26:43PM +0300, Itamar Heim wrote:
> > On 09/13/2012 10:24 AM, Karli Sj?berg wrote:
> > >
> > >13 sep 2012 kl. 01.21 skrev Dead Horse:
> > >
> > >>Thank you! glad to be able to help ;)
> > >>
> > >>As Itamar mentioned if you are running the spice client inside a VM
> > >>(dunno if this is case) you will need the guest paravirtual driver
> > >>and/or services for mouse handling. I have observed exactly this
> > >>behavior before when running the spice client in a VM when the guest
> > >>tools/drivers for mouse handling are not present (In my case most of
> > >>the time VirtualBox).
> > >
> > >Very amusing "bug":) But cripples SPICE?s usage.
> > >
> > >I have tested this from 5 different physical machines running Win7/IE,
> > >and this behavior shows itself only on machines with more than one
> > >monitor, or a laptop with another monitor attached .e.g. These guest
> > >tools you both mention, would these be
> > >"http://spice-space.org/download/binaries/spice-guest-tools-0.1.exe"?
> > >And can you install them in a physical machine as well?
> >
> > cc-ing spice-devel to see if they have insights on your issue
>
> Could this be related to
> https://bugzilla.redhat.com/show_bug.cgi?id=852841
> ?
>
> Christophe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20121005/c340eb90/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 06 Oct 2012 13:08:12 +0200
From: Juan Hernandez <jhernand at redhat.com>
To: Johan Kragsterman <johan.kragsterman at capvert.se>
Cc: users at ovirt.org
Subject: Re: [Users] fw: Migrating ovirt-engine to new server
Message-ID: <5070111C.8070705 at redhat.com>
Content-Type: text/plain; charset=windows-1252
On 10/05/2012 05:40 PM, Johan Kragsterman wrote:
> Hi there...
>
> Can't be possible that this is the procedure that we want to have to do this operation...?
>
> This is an operation that many users will want or will need to go through, and this definitely seem toooo complex.
You are right, it is more complex than what we all want to have, but at
the moment we don't have a simpler solution.
> I suppose/hope there is a strategy for developing another more smooth solution?
My particular view about this is that we should try to move as much as
possible to the database (certificates, for example, any kind of state
in general), so that when you have to move to a different server you
only need to install the packages in the new server and configure it to
use the old database.
> What I would have thought is that it would have been a solution where you can add multiple engines, and these would replicate the databases between them, and it would be easy to add another one, or remove one....
Clustering is another thing we all want. We already can support high
availability configurations using additional clustering software. I
think that in addition to that we should also support active-active
configurations similar to what you describe, but as you can imagine
implementing that is really challenging.
> Regards Johan
>
> -----users-bounces at ovirt.org skrev: -----
> Till: Juan Hernandez <jhernand at redhat.com>
> Fr?n: Neil
> S?nt av: users-bounces at ovirt.org
> Datum: 2012.10.05 14:31
> Kopia: users at ovirt.org
> ?rende: Re: [Users] fw: Migrating ovirt-engine to new server
>
> On Wed, Oct 3, 2012 at 8:52 PM, Juan Hernandez <jhernand at redhat.com> wrote:
>> On 10/03/2012 05:00 PM, Neil wrote:
>>> On Wed, Oct 3, 2012 at 4:41 PM, Itamar Heim <iheim at redhat.com> wrote:
>>>> On 10/03/2012 04:37 PM, Neil wrote:
>>>>>
>>>>> On Wed, Oct 3, 2012 at 4:20 PM, Itamar Heim <iheim at redhat.com> wrote:
>>>>>>
>>>>>> On 10/03/2012 04:17 PM, Neil wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 3, 2012 at 4:06 PM, Itamar Heim <iheim at redhat.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/03/2012 04:04 PM, Neil wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks for coming back to me.
>>>>>>>>>
>>>>>>>>> On Wed, Oct 3, 2012 at 4:00 PM, Itamar Heim <iheim at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> do you need to keep the VMs, or just move the LUNs to create a new
>>>>>>>>>> one?
>>>>>>>>>> if you just want to create a new one, you just need to clear the LUNs
>>>>>>>>>> (DD
>>>>>>>>>> over them) so engine will let you use them (or remove them from first
>>>>>>>>>> engine
>>>>>>>>>> which will format them for same end goal.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I need to keep the VM's unfortunately.
>>>>>>>>> Logically speaking all I need to do is detach the main data domain
>>>>>>>>> from one ovirt-engine and re-attach it to the new ovirt-engine.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> sadly, not that easy yet (though just discussed today the need to push
>>>>>>>> this
>>>>>>>> feature).
>>>>>>>>
>>>>>>>> easiest would be to export them to an nfs export domain, re-purpose the
>>>>>>>> LUNs, and import to the new system.
>>>>>>>>
>>>>>>>> if not feasible, need to hack a bit probably.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Oh crumbs! I thought that was wishful thinking though :)
>>>>>>>
>>>>>>> Exporting the VM's to NFS will take too long due to the total size
>>>>>>> being 4TB and the VM's are a mail, proxy and pdc servers so getting
>>>>>>> that much downtime won't be possible. Is attempting the upgrade
>>>>>>> path(http://wiki.ovirt.org/wiki/OVirt_3.0_to_3.1_upgrade) again my
>>>>>>> only option then?
>>>>>>> Even if I manage to get the "upgrade" working will I still need to
>>>>>>> export/import the VM's via NFS or will the datacentre move across once
>>>>>>> it can be detached?
>>>>>>>
>>>>>>
>>>>>> if you upgrade it the DC should be preserved.
>>>>>> juan - i remember there was a specific issue around upgrade to check, but
>>>>>> don't remember if was handled or not?
>>>>>
>>>>>
>>>>> Okay that is good news at least, very glad to hear!
>>>>> I am upgrading from a very early 3.1 release to the latest 3.1 using
>>>>> the dreyou repo, but encountered an issue after importing my DB I
>>>>> re-ran engine-setup and it kept asking for the engine password when it
>>>>> got to the point of "upgrading schema".
>>>>>
>>>>
>>>> oh, not sure - that depends on the various versions dreyou used.
>>>> so this is 3.1-->3.1 (dreyou), not 3.0-->3.1?
>>>
>>> Correct, it's 3.1.0_0001-1.8.el6.x86_64 --> 3.1.0-3.19.el6.noarch,
>>> and has no upgrade path. I'm also trying to separate my engine from
>>> one of the hosts, as this was installed on one of the hosts as a test
>>> and then we foolishy went live with it.
>>>
>>>>> An idea I've just thought of which might work, is if I allocate
>>>>> additional LUNS(as I have spare drives inside the SAN) and mount it
>>>>> locally on the new system, and then share this via NFS to the old
>>>>> system as an export domain, then export the machines, then re-purpose
>>>>> the old LUNS and add these as a new storage domain. Does this sound
>>>>> like it might work? Logically it means the data is just copying from
>>>>> one set of LUNS to the other but still remaining on the SAN.
>>>>
>>>> this should work.
>>>> though you are still copying all the data via the host, regardless of being
>>>> on same SAN.
>>>
>>> True! Sounds like the upgrade path is the best route. I have mailed
>>> the developer of dreyou as I see there is a
>>> patch(http://www.dreyou.org/ovirt/engine31.patch) which looks like it
>>> corrects the issues encountered, but not sure how to apply it.
>>>
>>> The only "guide" I've got to work with is the
>>> "OVirt_3.0_to_3.1_upgrade" not sure if this applies to me though
>>> considering I'm going from 3.1 to 3.1.
>>>
>>> These are the steps I've tried.
>>>
>>> 1.) Install fresh ovirt-engine
>>> 2.) Run through engine-setup using same parameters as old server
>>
>> Here make sure that the ovirt-engine service is stopped:
>>
>> service ovirt-engine stop
>>
>>> 3.) drop and import DB (http://wiki.ovirt.org/wiki/Backup_engine_db)
>>
>> Here, between step 3 and 4, you will need to update the database schema,
>> as there were probably a lot of changes between the two versions that
>> you are using. Go to the /usr/share/ovirt-engine/dbscripts directory and
>> try to run the following script:
>>
>> ./upgrade.sh -U postgres
>>
>> Does that work?
>>
>>> 4.) Restore previous keystore and preserve .sh scripts
>>> "http://wiki.ovirt.org/wiki/OVirt_3.0_to_3.1_upgrade" but not removing
>>> the new ovirt-engine because it's a new install on separate system.
>>
>> Correct, that should work.
>>
>>> 5.) Re-run engine-setup keeping same parameters as before, which is
>>> where it stops and keeps asking for the engine password when it tries
>>> to upgrade the DB schema, despite the passwords being correct.
>>
>> No, you should not run engine-setup again, just start the ovirt-engine
>> service again:
>>
>> service ovirt-engine start
>>
>>> Presumably once that works I can then shutdown my old DC, but do I
>>> need to remove the VM's once it's in maitenance? When I tried before
>>> it said "Cannot detach Storage Domain while VMs/Templates reside on
>>> it."
>>
>> Please report back your results or ping me in the #ovirt channel if you
>> have issues.
>
> Just to update everyone, with the assistance from Juan I have managed
> to complete the migration and I will send through the info on what was
> done to the list asap.
>
> Juan: If you wouldn't mind sending me the certificate re-generation
> steps when you have a chance please
>
> Thanks to everyone for their huge assistance!
>
> Kind regards.
>
> Neil Wilson.
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
--
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
------------------------------
_______________________________________________
Users mailing list
Users at ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
End of Users Digest, Vol 13, Issue 17
*************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20121006/c70af928/attachment-0001.html>
More information about the Users
mailing list