[Engine-devel] oVirt Workshop at LinuxCon Japan 2012
by Leslie Hawthorn
Hello everyone,
As part of our efforts to raise awareness of and educate more developers
about the oVirt project, we will be holding an oVirt workshop at
LinuxCon Japan, taking place on June 8, 2012. You can find full details
of the workshop agenda on the LinuxCon Japan site. [0]
Registration for the workshop is now open and is free of charge for the
first 50 participants. We will also look at adding additional
participant slots to the workshop based on demand.
Attendees who register for LinuxCon Japan via the workshop registration
link [1] will also be eligible for a discount on their LinuxCon Japan
registration.
Please spread the word to folks you think would find the workshop
useful. If they have already registered for LinuxCon Japan, they can
simply edit their existing registration to include the workshop.
[0] -
https://events.linuxfoundation.org/events/linuxcon-japan/ovirt-gluster-wo...
[1] - http://www.regonline.com/Register/Checkin.aspx?EventID=1099949
Cheers,
LH
--
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat
identi.ca/lh
twitter.com/lhawthorn
12 years
[Engine-devel] Storage Device Management in VDSM and oVirt
by Shireesh Anjal
Hi all,
As part of adding Gluster support in ovirt, we need to introduce some
Storage Device management capabilities (on the host). Since these are
quite generic and not specific to Gluster as such, we think it might be
useful to add it as a core vdsm and oVirt feature. At a high level, this
involves following:
- A "Storage Devices" sub-tab on "Host" entity, displaying information
about all the storage devices*
- Listing of different types of storage devices of a host
- Regular Disks and Partitions*
- LVM*
- Software RAID*
- Various actions related to device configuration
- Partition disks*
- Format and mount disks / partitions*
- Create, resize and delete LVM Volume Groups (VGs)
- Create, resize, delete, format and mount LVM Logical Volumes (LVs)
- Create, resize, delete, partition, format and mount Software RAID
devices
- Edit properties of the devices
- UI can be modeled similar to the system-config-lvm tool
The items marked with (*) in above list are urgently required for the
Gluster feature, and will be developed first.
Comments / inputs welcome.
Thanks,
Shireesh
12 years
[Engine-devel] Using JBoss F17 RPMs
by Ofer Schreiber
As you probably know, we're aiming to use the new JBoss Fedora RPMs in the next version of oVirt.
If anyone have some info (or patches, we love patches) on how to do this change right, we would like to know.
Any input is appreciated.
Thanks,
---
Ofer Schreiber
oVirt Release Manager
12 years
[Engine-devel] restapi: 'gluster' prefix
by Ori Liel
We are introducing Gluster functionality into ovirt-engine REST-API.
Gluster entities are 'Volumes' and 'Bricks'. The question is: should
they be called: 'volume'/'brick' or 'gluster_volume/gluster_brick'?
(with or without the 'gluster' prefix)?
There was a short conversation about this in a patch in Gerrit:
http://gerrit.ovirt.org/#change,3918
Since there are conflicting opinions, I'm bringing it here for a resolution.
Thanks,
Ori.
12 years
[Engine-devel] auth issue
by Hui Kai Ran
Hi, all
When I access the REST API like this
====================================
import urllib2
theurl = 'http://9.181.129.112:8080/api'
username = 'admin@internal'
password = 'abcd1234'
# a great password
passman = urllib2.HTTPPasswordMgrWithDefaultRealm()
passman.add_password('ENGINE', theurl, username, password)
authhandler = urllib2.HTTPBasicAuthHandler(passman)
opener = urllib2.build_opener(authhandler)
urllib2.install_opener(opener)
pagehandle = urllib2.urlopen(theurl)
=========================================
urlopen failed.
then We do that another way like this, it is ok
========================================
import urllib2
import sys
import re
import base64
import xml.etree.ElementTree as etree
username='admin@internal'
password='abcd1234'
request = urllib2.Request("http://9.181.129.112:8080/api")
base64string = base64.encodestring('%s:%s' % (username,
password)).replace('\n', '')
request.add_header("Authorization", "Basic %s" % base64string)
result = urllib2.urlopen(request)
by catching the packets transfered, we found the response from
ovirt-engine server as below for failing case:
================================================================
GET /api HTTP/1.1
Accept-Encoding: identity
Host: 9.181.129.112:8080
Connection: close
User-Agent: Python-urllib/2.7
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: Basic realm = "ENGINE"
Content-Type: text/html;charset=utf-8
Content-Length: 956
Date: Fri, 04 May 2012 09:18:06 GMT
Connection: close
Is there anything wrong for oVirt-engine?
Thanks!
12 years
[Engine-devel] ovirt engine sync call
by Livnat Peer
Hi,
If you have something you think should be discussed today in the engine
core sync call let me know and we'll add it to the agenda.
Thanks, Livnat
12 years
Re: [Engine-devel] [vdsm] RFD: NEW API getAllTasks
by Doron Fediuck
On 07/05/12 21:33, Adam Litke wrote:
> The current APIs for retrieving all task information do not actually return all
> task information. I would like to introduce a new API that corrects this and
> other issues with the current API while preserving backwards compatibility with
> ovirt-engine for as long as is necessary.
>
> The current APIs:
>
> getAllTasksInfo(spUUID=None, options = None):
> - Returns a dictionary that maps a task UUID to a task verb.
> - Despite having 'all' in the name, this API only returns tasks that have an
> 'spm' tag.
> - This call returns only one piece of information for each task.
> - The spUUID parameter is deprecated and ignored.
>
> getAllTasksStatuses(spUUID=None, options = None):
> - Returns a dictionary of task status information.
> - Despite having 'all' in the name, this API only returns tasks that have an
> 'spm' tag.
> - The spUUID parameter is deprecated and ignored.
>
>
> I propose the following new API:
>
> getAllTasks(tag=None, options=None):
> - Returns a dictionary of task information. The info from both of the above
> functions would be merged into a single result set.
> - If tag is None, all tasks are returned. otherwise, only tasks matching the
> tag are returned.
> - The spUUID parameter is dropped. options is for future extension and is
> currently not used.
>
> This new API includes all functionality that is available in the old calls. In
> the future, ovirt-engine could switch to this API and preserve the current
> semantics by passing tag='spm' to getAllTasks. Meanwhile, API users that really
> want all tasks (gluster and the REST API) can get what they need.
>
> Thoughts on this idea?
>
(Adding engine-devel, as this relates to the engine API).
AFAIR, in the original design (when a-sync tasks where introduced into vdsm),
most (if not all) of the tasks were SPM tasks, and this is the reason for this
behavior.
Improving the API is welcomed. The suggested design should work.
I'd like to verify:
- Backwards compatibility works; so running engine's shouldn't be replaced.
Dan: any news on this?
- Going forward with potential changes in SPM concepts should be supported as well.
Dan/Ayal/Livnat: do you think it works? ie- anything else needed than alternate 'spm' tag?
--
/d
"All computers wait at the same speed."
12 years
Re: [Engine-devel] Supporting native USB in oVirt
by Eli Mesika
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Oved Ourfalli" <ovedo(a)redhat.com>, "Dave Allan" <dallan(a)redhat.com>
> Cc: "Dave Allan" <dallan(a)redhat.com>, "Jiri Denemark" <jdenemar(a)redhat.com>, "Michal Privoznik"
> <mprivozn(a)redhat.com>, "Itamar Heim" <iheim(a)redhat.com>, "Igor Lvovsky" <ilvovsky(a)redhat.com>, "Eli Mesika"
> <emesika(a)redhat.com>, "Hans de Goede" <hdegoede(a)redhat.com>, "Andrew Cathrow" <acathrow(a)redhat.com>
> Sent: Tuesday, May 8, 2012 11:41:25 AM
> Subject: Re: Supporting native USB in oVirt
>
> On Tue, May 08, 2012 at 03:19:32AM -0400, Oved Ourfalli wrote:
> > Hi,
> >
> > We are now working on adding the support for native USB devices on
> > oVirt.
> > As far as we understand, in order to use it we need to pass the
> > following devices with the following restrictions (according to
> > the EHCI spec):
> > 1. EHCI USB controller - with the highest function number, #7.
> >
> > devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}'
> >
> > 2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI
> > controller. Set the multifunction bit to on, on the controller
> > with function #0.
> >
> > devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}'
> > devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}'
> > devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}'
>
> I'd like to make it clear that the suggested API request Engine to
> pass
> a "master" attribute for the controller device, with a nested
> dictionary
> within. This makes sense, as I am certain that libvirt's modeling of
> the
> device has merits. However, AFAIK Engine does not do stuff like that
> at
> the momemnt.
And should not do in future IMHO, this should be transparent to the engine core that should know only the USB device.
>
> >
> > 3. USB redirect devices (according to the needed number of USB
> > slots, maximum 6) on the same bus, each one having a different
> > port.
> >
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}'
> >
> > 4. If we want more than 6 USB slots, we need to have 2 EHCI
> > controllers, and 6 UHCI controllers, that are consistent with the
> > restrictions above, on different bus.
> > (we need them to be on different bus, since the connection between
> > the redirect devices and the controllers is the bus).
> >
> > According to Hans (cc-ed), if we let libvirt pick its own
> > addresses, it will put each controller of the composite USB
> > controller device on its own pci slot, which is a violation of the
> > EHCI spec.
>
> Is there an open libvirt bug for this?
>
> >
> > The problem is that the oVirt engine is not aware of addresses.
> > They aren't managed by it.
> > They are chosen automatically by libvirt, returned to the engine,
> > and they saved in the engine database in order to provide the
> > ability to retain the same PCI addresses after VM restart.
>
> Yes, we should be able to trust libvirt's assignement, certainly for
> the
> masses of VMs. Few VMs of certain customer may want to tweak the
> location of their devices. Maybe Engine does not need to expose this
> feature at the moment (I think it is better that each device address
> is
> considered a "blob" by Engine), but the Engine/Vdsm API should
> support
> that.
I know that in future we may need to tweak the device location.
But still, the general principle of address allocation should be kept simple:
If you send an address, this address is honored by libvirt
If you don't, you will get a valid one from libvirt.
I think that engine should not handle any addresses apart from persisting the address in DB.
>
> >
> > So, in order to support the EHCI spec, oVirt will have to be aware
> > of addresses, manage them (allocate them, check for collisions,
> > update on every libvirt change regarding that, etc...). Obviously,
> > it doesn't feel right, and in fact it is also not feasible, to
> > manage these addresses in the oVirt domain.
>
> That's not obvious to me. Engine could have a hard-coded addresses
> for
> the usb device gang. Libvirt could arrange the rest of the devices
> around it, so Engine should not worry about collisions. Libvirt's
> stable
> API relieves Engine from worrying about "every libvirt change
> regarding
> that" - it is libvirt responsibility to make sure that every future
> libvirt version would handle the USB addresses properly.
A big hole for future bugs that will fall between libvirt & engine responsibility.
I don't like that idea of spreading responsibilities between separate components
and prefer that addresses will have one manager that is obviously libvirt.
>
> >
> > Is all the above correct, or are we missing something?
> > If so, can you address the issues above, and provide the ability to
> > manage these devices in libvirt?
> >
> > Regards,
> > Oved
>
12 years
Re: [Engine-devel] Supporting native USB in oVirt
by Oved Ourfalli
cc-ing engine-devel.
Oved
----- Original Message -----
> From: "Hans de Goede" <hdegoede(a)redhat.com>
> To: "Oved Ourfalli" <ovedo(a)redhat.com>
> Cc: "Dave Allan" <dallan(a)redhat.com>, "Jiri Denemark" <jdenemar(a)redhat.com>, "Michal Privoznik"
> <mprivozn(a)redhat.com>, "Itamar Heim" <iheim(a)redhat.com>, "Igor Lvovsky" <ilvovsky(a)redhat.com>, "Eli Mesika"
> <emesika(a)redhat.com>, "Dan Kenigsberg" <danken(a)redhat.com>, "Andrew Cathrow" <acathrow(a)redhat.com>
> Sent: Tuesday, May 8, 2012 10:48:32 AM
> Subject: Re: Supporting native USB in oVirt
>
> Hi,
>
> On 05/08/2012 09:19 AM, Oved Ourfalli wrote:
> > Hi,
> >
> > We are now working on adding the support for native USB devices on
> > oVirt.
> > As far as we understand, in order to use it we need to pass the
> > following devices with the following restrictions (according to
> > the EHCI spec):
> > 1. EHCI USB controller - with the highest function number, #7.
> >
> > devices='{type:controller,device:usb,model:ich9-ehci1,address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x7}}'
> >
> > 2. 3 UHCI USB controllers, on the same bus and PCI slot as the EHCI
> > controller. Set the multifunction bit to on, on the controller
> > with function #0.
> >
> > devices='{type:controller,device:usb,model:ich9-uhci1,master:{startport:0},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x0,multifunction:on}}'
> > devices='{type:controller,device:usb,model:ich9-uhci2,master:{startport:2},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x1}}'
> > devices='{type:controller,device:usb,model:ich9-uhci3,master:{startport:4},address:{type:pci,domain:0x0000,bus:0x00,slot:0x04,function:0x2}}'
> >
> > 3. USB redirect devices (according to the needed number of USB
> > slots, maximum 6) on the same bus, each one having a different
> > port.
> >
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:1}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:2}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:3}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:4}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:5}}'
> > devices='{type:redir,device:spicevmc,bus:usb,address:{type:usb,bus:0,port:6}}'
> >
>
> To the best of my knowledge, the above is all correct.
>
> > 4. If we want more than 6 USB slots, we need to have 2 EHCI
> > controllers, and 6 UHCI controllers, that are consistent with the
> > restrictions above, on different bus.
> > (we need them to be on different bus, since the connection between
> > the redirect devices and the controllers is the bus).
>
> Correct, note that this may change in the future. Specifically I'm
> thinking about
> adding support for USB-2 hubs, and then have libvirt automatically
> add new
> redir-devices when all but one are in use. This is all just an idea
> at the moment,
> so don't count on it, I just wanted you to know that we are thinking
> about making
> it easier to make the number of devices dynamic in the future. So for
> now you
> could consider simply limiting redirection to max 6 devices.
>
> > According to Hans (cc-ed), if we let libvirt pick its own
> > addresses, it will put each controller of the composite USB
> > controller device on its own pci slot, which is a violation of the
> > EHCI spec.
>
> Correct.
>
> > The problem is that the oVirt engine is not aware of addresses. They aren't managed by it.
> > They are chosen automatically by libvirt, returned to the engine, and they saved in the engine database in order to provide the ability to retain the same PCI addresses after VM restart.
> >
> >So, in order to support the EHCI spec, oVirt will have to be aware of addresses, manage them (allocate them, check for collisions, update on every libvirt change regarding that, etc...). Obviously, it doesn't feel right, and in fact it is also not feasible, to manage these addresses in the oVirt domain.
> >
> > Is all the above correct, or are we missing something?
> > If so, can you address the issues above, and provide the ability to manage these devices in libvirt?
> Regards,
>
> Hans
>
12 years
Re: [Engine-devel] Problem with detachment of host interface using ovirt-sdk
by Itzik Brown
Juan,
I used the repository git://gerrit.ovirt.org/ovirt-engine-sdk
Commit 3c721e60ab3af3ad07e1a20bc6fdbcdbc1344df0
The test script :
#!/usr/bin/python
import sys
from ovirtsdk.api import API
from ovirtsdk.xml import params
OVIRT_ENGINE_SERVER = 'server1'
OVIRT_ENGINE_PORT = '8080'
OVIRT_ENGINE_USER = 'admin@internal'
OVIRT_ENGINE_PASSWORD = 'password'
url = 'http://%s:%s' % (OVIRT_ENGINE_SERVER, OVIRT_ENGINE_PORT)
api = API(url = url, username = OVIRT_ENGINE_USER , password = OVIRT_ENGINE_PASSWORD)
host = 'host1'
if_name = 'eth4'
net_name = 'net1'
nic = api.hosts.get(name=host).nics.get(name=if_name)
net = params.Network(name=net_name)
act = params.Action(network=net)
nic.detach(act)
api.hosts.get(name=host).commitnetconfig()
Thanks,
Itzik
12 years
