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