- Devel - oVirt List Archives

Re: [Engine-devel] [vdsm] reserve virtio-balloon device created by libvirt
by Itamar Heim 01 May '12

01 May '12

On 04/29/2012 04:19 PM, Dan Kenigsberg wrote: > On Sun, Apr 29, 2012 at 07:24:52AM -0400, Andrew Cathrow wrote: >> >> >> ----- Original Message ----- >>> From: "Dan Kenigsberg"<danken(a)redhat.com> >>> To: "Gal Hammer"<ghammer(a)redhat.com> >>> Cc: vdsm-devel(a)lists.fedorahosted.org >>> Sent: Sunday, April 29, 2012 7:19:10 AM >>> Subject: Re: [vdsm] reserve virtio-balloon device created by libvirt >>> >>> On Mon, Apr 23, 2012 at 04:00:55PM +0300, Gal Hammer wrote: >>>> On 23/04/2012 12:26, Mark Wu wrote: >>>>> Hi guys, >>>>> >>>>> I saw that an option to create balloon device was added by Gal in >>>>> http://gerrit.ovirt.org/1573 >>>>> I have a question about it. Why don we preserve the old default >>>>> behaviour? I know it's not supported by ovirt-engine now, but I >>>>> can't >>>>> figure out what will break if it's not disabled explicitly. So do >>>>> you >>>>> think we can just make use of the balloon device added by libvirt? >>>> >>>> We didn't change the old behavior. >>>> >>>> Libvirt creates by default a memory-balloon device, so vdsm >>>> defaults >>>> was to disable it by adding a "none"-type device. This was done >>>> because vdsm didn't include an option to add such device. >>>> >>>> My patch added an option to create a memory-balloon through vdsm. >>>> If >>>> the user didn't request to add the device, the behavior is same as >>>> before, disabling the memory-balloon. >>> >>> I feel that it would be best not to flip Vdsm's default at the >>> moment, >>> even though it is the opposite of libvirt's. I would consider to flip >>> them only after your (Mark's) patches are in, tested, and proven >>> worthwhile for the common case. >>> >>> Currently, without any management for the balloon, reserving a guest >>> PCI >>> device was deemed wasteful. >> >> On the other side of the fence >> - We know that we do need to do ballooning >> - In the (next?) release we'll end up adding this support >> - There's no harm (see next point) in adding the device now in fact it saves a config change on upgrade. > > Well, there is a surprise factor, for someone running a guest generated > in a previous version. Suddenly, after Vdsm upgrade, it would see an > additional device. At the least, I would like Vdsm to have a > configurable option to keep the old behavior. please take into consideration engine has an algorithm testing max number of devices and it should be aware of newly introduced devices by vdsm or it will overflow. > >> - While it takes up a PCI slot it's going to be very, very rare deployments that will ever see the limit, libvirt/virtmanager/virt-install has done this forever without seeing push back. > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/vdsm-devel

3 2

Re: [Engine-devel] [vdsm] vdsm on openSuSE
by Doron Fediuck 01 May '12

01 May '12

On 30/04/12 19:23, Itamar Heim wrote: > On 04/30/2012 06:45 PM, Sascha Littel wrote: >> Am Montag, 30. April 2012, 16:45:12 schrieben Sie: >>> Hi Sasha, >>> This may be an issue of SSH authentication method. >>> Can you please check you SSH server in the host- >>> Password auth should be password and not Keyboard-interactive. >>> This may lead to SSH auth failure as you engine log indicates. >> Thanks dude this was the hint I need. I changed the PasswordAuthentication in >> /etc/ssh/sshd_config. Now I can add the vdsm into the oVirt engine host. Now >> the real work can beginn. > > Doron - can we catch this error and give this hint to users as something worth checking? > (added engine-devel, as this extends to the engine side). AFAICT, we get auth failure, with no reason. In order to handle it we can go in to ways (need to decide)- 1. Add the keyboard-interactive auth to Mina SSHD. There's a guy who added it[a] and we may try and ask for hints from him. I know that patches are welcomed there as well ;) 2. Try to diagnose the failure we get, or scan Mina's err / debug stream. I suspect we should be able to see something like: debug1: Authentications that can continue: password,publickey ... debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password So if server does not report 'password' as an option we could give a better auth-failure message. It will be nice if someone from our community could pick this up, and if not this would be a nice feature for one of the coming versions. [a] http://mail-archives.apache.org/mod_mbox/mina-dev/201112.mbox/%3CCACPdTxMmw… >>> >>>> Am Montag, 30. April 2012, 13:09:25 schrieben Sie: >>>>> On 04/30/2012 02:07 PM, Sascha Littel wrote: >>>>>> Am Montag, 30. April 2012, 05:04:09 schrieben Sie: >>>>>>> On 04/29/2012 10:24 PM, S. Littel wrote: >>>>>>>> Hi everybody, I'm working currently on a running version of vdsm >>>>>>>> 4.9.1 for openSuSE 11.3. I'm changing many lines in the start/stop >>>>>>>> scripts e.g. paths, rc commands. Most of this work looks fine but >>>>>>>> if I try to get a connection between the oVirt engine (runs on a >>>>>>>> openSuSE 12.1) and the vdsm host I get a ssl error. Also after >>>>>>>> setting ssl in vdsm.conf to false and changing the settings in >>>>>>>> oVirt engine database I still get this error. >>>>>>> >>>>>>> which settings are you changing in the db? >>>>>> >>>>>> I changed the seetings in the database with this 2 commands: >>>>> did you restart engine after changing these? >>>> >>>> Yes. I found this page in the oVirt Wiki: >>>> http://ovirt.org/w/index.php?title=OVirt_- >>>> _disable_SSL_in_VDSM&diff=3036&oldid=prev >>>> >>>>>> psql engine -U postgres -c "UPDATE vdc_options set option_value = >>>>>> 'false' where option_name = 'SSLEnabled'" >>>>>> >>>>>> psql engine -U postgres -c "UPDATE vdc_options set option_value = >>>>>> 'false' where option_name = 'UseSecureConnectionWithServers'" >>>>>> >>>>>>> UseSecureConnectionWithServers? >>>>>> >>>>>> Yes. >>>>>> >>>>>>>> So the general question, is there someone working on a openSuSE 11.3 >>>>>>>> or 11.4 version of vdsm? Or someone who has experience how to get >>>>>>>> it work? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Sascha Littel >>>>>> >>>>>> Here is the failure massage from the vdsm-reg.log I get on the vdsm >>>>>> host: >>>>>> >>>>>> SSLError: [Errno 185090050] _ssl.c:328: error:0B084002:x509 >>>>>> certificate routines:X509_load_cert_crl_file:system lib >>>>>> MainThread::DEBUG::::deployUtil::1413::root::getRemoteFile end. >>>>>> MainThread::DEBUG::::deployUtil::621::root::handleSSHKey start >>>>>> MainThread::ERROR::::deployUtil::614::root::restorecon >>>>>> /root/.ssh/authorized_keys failed >>>>>> >>>>>> And this is the failure message from engine.log on the oVirt engine >>>>>> host: >>>>>> >>>>>> ERROR [org.ovirt.engine.core.utils.hostinstall.MinaInstallWrapper] >>>>>> (http--0.0.0.0-8443-1) Could not connect to server >>>>>> xen007.f1.aiges.net: Failed connecting >>>>>> >>>>>> to xen007.f1.aiges.net using given password! Please verify your >>>>>> password is >>>>>> >>>>>> correct and that the host accepts password-based authentication >>>>>> WARN [org.ovirt.engine.core.bll.AddVdsCommand] (http--0.0.0.0-8443-1) >>>>>> CanDoAction of action AddVds failed. >>>>>> Reasons:VDS_CANNOT_CONNECT_TO_SERVER,VAR__ACTION >>>>>> __ADD,VAR__TYPE__HOST >>>>>> >>>>>> Regards >>>>>> >>>>>> Sascha Littel >> >> > -- /d Never say "OOPS!" always say "Ah, Interesting!"

2 1

[Engine-devel] signed-off-by in commit message
by Itamar Heim 30 Apr '12

30 Apr '12

per previous thread by Ryan Harper[1] and ovirt meeting today, starting may 1st gerrit policy will change for all projects to require signed-off-by in the commit message. vdsm and ovirt-node already have this active Thanks, Itamar for more details: http://kerneltrap.org/files/Jeremy/DCO.txt [1]http://www.mail-archive.com/arch@ovirt.org/msg00273.html

4 4

[Engine-devel] CPU topology in the API
by Simon Grinberg 30 Apr '12

30 Apr '12

Hi list, The current status is that though they look the same, CPU topology for hosts and VMs differ. In both you have <topology cores="N" sockets="Y"/> for hosts: Cores = Total cores on the host, Y=number of sockets for VMs: Cores = Cores per socket, Y=number of sockets This means that for a hosts that has 4 sockets with 8 cores per socket the topology will be presented as: <topology cores="32" sockets="4"/> While for VM with the same requested topology will show: <topology cores="8" sockets="4"/> I think they should not be different to avoid confusion but: * The information we displayed for the host can't count on the fact that cores are distributed evenly across sockets, because theoretically a host could contain several different CPUs, so it can't be displayed as a multiplication. * On the other hand changing the VM topology will break the API though it will make it aligned both with hosts and with the 'New VM' dialogue in the UI. For oVirt 3.x it may be that nothing can be changed however for oVirt it is allowed in theory to break the API (a bit :)) so the options as I see it are: 1. Don't touch, leave the confusion. 2. Make host align to VMs with the risk that on some hosts this may be a bit misleading - should be rare. 3. Make host topology looks like VM but allow multiple CPU topologies in the CPUs sub collection of the host. (This also requires change in VDSM API) 4. Align VMs to Hosts I would go for 4 or 2 Current CPU topology for the hosts is a new commit, thus it may be allowed to change it now since no one is using it yet. This works in favour of 2. In any case only 3 discloses all the information in all possible cases. Thoughts? Thanks, Simon.

3 5

[Engine-devel] Moving oVirt engine to Jboss AS 7.1.1
by Oved Ourfalli 29 Apr '12

29 Apr '12

Hey all, We have pushed patches that make the necessary adjustments to allow working with the newest Jboss version, Jboss AS 7.1.1 Final. After fetching please do the following: * Download Jboss AS 7.1.1.Final from http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1.1.F… * Change the JBOSS_HOME wherever you defined it. * Change the Jboss Home in ~/.m2/settings.xml. * Run a full build, including setup: mvn clean install -DskipTests -Psetup,dep (consider using flags -Dgwt.userAgent=gecko1_8 and -Dgwt.draftCompile=true to avoid compiling GWT on all permutations). * Run jboss as usual. If you have any issues, reply here and we'll do anything to help. The oVirt engine wiki page (http://www.ovirt.org/wiki/Building_oVirt_engine) was changes accordingly. Thank you, Oved

1 0

[Engine-devel] +1 in gerrit
by Laszlo Hornyak 29 Apr '12

29 Apr '12

Hi, Just an idea for the gerrit reviews: if you review a patch and give "+1 Looks good to me, but someone else must approve", then please add someone as reviewer, who might be the right person. And then after a while the patch will get to someone who knows if the patch is good or not. Laszlo

3 2

[Engine-devel] namingcontexts getting ignored.
by Sharad Mishra 29 Apr '12

29 Apr '12

Hi, I enter "getDefaultNamingContextFromNamingContexts()" with namingContexts set to - namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES, O=IBM.COM, O=DELETED.IBM.COM But this method only takes the first case "CN=SCHEMA" and ignores the rest. Actually I am interested in "O=IBM.COM". Is this working as designed or needs improvement? -Sharad Mishra IBM public class RootDSEData { private String domainDN = null; private LdapProviderType ldapProviderType = null; private final static String RHDS_NAMING_CONTEXT = "o=netscaperoot"; public static String getDefaultNamingContextFromNamingContexts(Attribute namingContexts) { for (int index = 0; index < namingContexts.size(); ++index) { String namingContext; try { namingContext = (String) namingContexts.get(index); } catch (NamingException e) { return null; } if (!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext)) { return namingContext; } } return null; }

3 4

[Engine-devel] bi-weekly status
by Livnat Peer 24 Apr '12

24 Apr '12

Hi All, It is memorial day in Israel tomorrow, so I am canceling tomorrow's ovirt-engine-core meeting. Please reply on the list if there is something that can't/shouldn't wait for next meeting and I'll schedule a meeting for next week instead of this one. Thanks, Livnat

1 0

[Engine-devel] upstream/downstream compat
by Ryan Harper 23 Apr '12

23 Apr '12

I've submitted some changes to start some of the work of removing the RHEV/RHEVM names throughout the vdsm code. In one of the patches, there's a good discussion on compatibility with downstream[1] And I wanted to continue that on the mailing list so we could have more eyes; it's not clear to me if everyone is able to see/participate in an inline thread to just one of my patches. To the point; as we look at moving toward an upstream vdsm which may be used stand-alone; ie, it may or may not having ovirt-engine/RHEVM driving actions. I'm interested in hearing details what our requirements for compatibility are and which parts of the tree might be affected. I'd like to posit that downstream compat is the responsibility of the distro versus the upstream community; though that's not a license to make things difficult. IMHO, this means we can do things that help clean up the code or move the project in a particular direction without having to always worry about what the package looks like in a particular distro. The other aspect to compatibility I'd like to hear details/discussion on the interfaces (explicit or implicit) between vdsm and ovirt-engine. I rekindled a discussion[2] on at least one known issue around engine including the qemu machine type in the database; Any pointers to other places would be helpful as I'm wrapping my head around the back and forth between vdsm and engine. 1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py 2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh(a)us.ibm.com

2 4

[Engine-devel] StorageHelperDirector "factory" and StorageType
by Yair Zaslavsky 23 Apr '12

23 Apr '12

Hi all, StorageHelperDirector.java implements a mechanism that creates instances of classes implementing IStorageHelper based on String value of StorageType enum. Although the InitializeHelpers method has an "automated" mechanism for creating the helpers, I think it causes some bad practice - It creates a tight coupling between the StorageType values and the class names of storage helpers, and a result of that, Java naming convention is broken (we use upper case enum literals at StorageType which yield class names such as LOCALFSStorageHelper. I think that this mechanism is an overkill, and during addition of new storage type, its easily to detect during development if one has forgotten to add the helper to the factory (if done manually). Thoughts about this issue are more than welcome Yair

3 2