Re: [Engine-devel] [RFC] new power management protocol libvirtp
Dan Kenigsberg: On Tue, Apr 02, 2013 at 10:15:44AM +0800, Shu Ming wrote: Hi, In oVirt environment, power manager should be enabled for the host to support VM high availability in the cluster. Various kinds of physical power management protocol are supported, ie., ALOM, ILOetc. However, when the oVirt is running on a nested KVM environment, there is no feasible way to do the power management of the VDSM host(also a KVM virtual machine). A new protocol will be based on libvirt to achieve the power management of a virtual host. The new protocol can be named as libvirtp. In oVirt engine, a new type will be added to power management--- type libvirtp power management---address it will be the IP of the physical host where the virtual VDSM host is on when libvirtp is selected power management---user name it will be the user name to the libvirtd service power management---password it will be the password to the libvirtd service power management---port it will be the port to the libvirtd service Have you looked into fence_virsh or fence_virt ? Don't they provide what you want? Thanks for your reminder. I think fence_virsh or fence_virt can be leveraged to achieve the goal.. For fence_virsh, it requires virsh to be installed on the vdsm virtual host. For fence_virt, it requires fence_virtd to be installed on the vdsm virtual host and it is not libvirt centric. With these two power management protocol, the oVirt engine still need change to integrate these two protocols for the host power management. -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] [RFC] new power management protocol libvirtp
Hi, In oVirt environment, power manager should be enabled for the host to support VM high availability in the cluster. Various kinds of physical power management protocol are supported, ie., ALOM, ILOetc. However, when the oVirt is running on a nested KVM environment, there is no feasible way to do the power management of the VDSM host(also a KVM virtual machine). A new protocol will be based on libvirt to achieve the power management of a virtual host. The new protocol can be named as libvirtp. In oVirt engine, a new type will be added to power management--- type libvirtp power management---address it will be the IP of the physical host where the virtual VDSM host is on when libvirtp is selected power management---user name it will be the user name to the libvirtd service power management---password it will be the password to the libvirtd service power management---port it will be the port to the libvirtd service -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage.
Mark Wu : On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: - Original Message - Hi guys, Currently, ISO domain is only supported on NFS storage. It could improve the ease of use if it allows other types of file based storage to store ISO images. After an investigation, I found there's not any restriction on this idea. So the whole work is removing the limitation on engine side. That means engine should allow ISO domain could have different storage type from the data center it's attached, like what we do with nfs ISO domain in SAN DC. I start this idea with localfs. I know local storage can't be seen in cluster level. But it also provides a choice if no NFS available. VMs can be created on the host which has the ISO repo, and then be migrated to any other host in the cluster. I have done the initial patches: allow creation ISO domain on localfs [1] and support import ISO domain on localfs [2] I don't have much experience in java/j2ee/web development and engine architecture. The patches just work for me. I am not sure if it will bring some potential problems. So any feedback on the patch or the idea will be appreciated very much. Haven't looked at the patches yet, but wrt the idea, I agree on the need (being able to attach ISOs from anywhere and not just nfs) but I think the way to do this should be by getting rid of the ISO domain type altogether. I think ISO domain on localfs is useful for a simple setup or demo, such as oVirt all-in-one. Basically what we need is: 1. a way to connect to file based storage (let's leave block aside for now) - this already exists via the connectStorageServer verb 2. a way to list and present a file system tree in gui (give an arbitrary path to vdsm and list content) and possibly filter results by type (vfd, iso) - does not exist today. Possibly some security aspects here that need hashing out. 3. a way to specify a path to a file when attaching an iso/vfd to a VM - this is the way it works today This would devoid the need for isoUploader and allow users to simply manage an nfs export with files. Next step would be to make connectStorageServer support httpfs [1] and then we'd be able to mount ISOs directly over http (hopefully this would be sufficient to support ISOs stored on S3, swift, glance, etc). Actually, we could use the qemu curl backend image support directly. That means we don't need mount the place storing ISO images. We can just maintain a list of ISO image with its link, which could be http, ftp and ssh. That will be fine to start a VM on a existing extern ISO image. I also would like to maintain a ISO image cache on the local host to avoid to re-streaming the ISO image from the ISO image repositories every time. That will be helpful for people who is suffered from the network bottleneck. [1] http://httpfs.sourceforge.net/ Mark. [1] http://gerrit.ovirt.org/#/c/12687/ [2] http://gerrit.ovirt.org/#/c/12916/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] RFC: New Storage API
2013-1-15 5:34, Ayal Baron: image and volume are overused everywhere and it would be extremely confusing to have multiple meanings to the same terms in the same system (we have image today which means virtual disk and volume which means a part of a virtual disk). Personally I don't like the distinction between image and volume done in ec2/openstack/etc seeing as they're treated as different types of entities there while the only real difference is mutability (images are read-only, volumes are read-write). To move to the industry terminology we would need to first change all references we have today to image and volume in the system (I would say also in ovirt-engine side) to align with the new meaning. Despite my personal dislike of the terms, I definitely see the value in converging on the same terminology as the rest of the industry but to do so would be an arduous task which is out of scope of this discussion imo (patches welcome though ;) Another distinction between Openstack and oVirt is how the Nova/ovirt-engine look upon storage systems. In Openstack, a stand alone storage service(Cinder) exports the raw storage block device to Nova. On the other hand, in oVirt, storage system is highly bounded with the cluster scheduling system which integrates storage sub-system, VM dispatching sub-system, ISO image sub systems. This combination make all of the sub-system integrated in a whole which is easy to deploy, but it make the sub-system more opaque and not harder to reuse and maintain. This new storage API proposal give us an opportunity to distinct these sub-systems as new components which export better, loose-coupling APIs to VDSM. ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail:shum...@cn.ibm.com orshum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Live storage migration status in oVirt 3.2
于 2013-1-11 19:07, Daniel Erez 写道: - Original Message - From: Shu Ming shum...@linux.vnet.ibm.com To: engine-devel@ovirt.org, VDSM Project Development vdsm-de...@lists.fedorahosted.org Cc: Federico Simoncelli fsimo...@redhat.com, de...@redhat.com Sent: Friday, January 11, 2013 2:45:47 AM Subject: Live storage migration status in oVirt 3.2 Hi, I am reviewing the live storage migration with my oVirt environment updated from the public nightly repository two weeks ago. I found that the move button was still gray as before when the VM was up. Only after I deactivated the disk, did the button become into non-gray state. I am wondering if the live storage migration will be supported in oVirt 3.2 release or not. BTW: These patches below should enable the live storage migration already, but I can not see it enabled in my engine. http://gerrit.ovirt.org/5252 Change I91e641cb: pool: live storage migration implementation http://gerrit.ovirt.org/8105 Change subject: core: Live Storage Migration commands http://gerrit.ovirt.org/8103 Change subject: core: VDS Commands for Live Storage Migration http://gerrit.ovirt.org/8102 Change subject: core: Adding VDSM API for Live Storage Migration http://gerrit.ovirt.org/8470 Change subject: webadmin: Adding Live Storage Migration support http://gerrit.ovirt.org/8857 core: disable LiveStorageMigration on 3.1 -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC Hi Shu, When a VM is up, the move button is enabled only for Data Center version 3.2. Can you please verify that the selected disk resides on a 3.2 Data Center? I checked my data center compatibility version is 3.1. However, it is interesting that the compatibility version of the cluster in the data center is 3.2 Does the data center allow a higher version cluster? I will try to upgrade the data center version and try the migration again. Best Regards, Daniel -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] FW: Querying for and registering unknown disk images on a storage domain
2012-12-20 23:18, Morrissey, Christopher: Hi All, I've been working on a bit of functionality for the engine that will allow a user to query a domain for new disk images (GetUnregisteredImagesQuery) for which the engine was previously unaware and a separate command to register those images (ImportImageCommand). These commands will be exposed through the REST API. This functionality is needed as we are developing an extension/plugin to oVirt that will allow a NetApp storage controller to handle cloning the actual disks outside of oVirt and need to import them once they are cloned. We'll be using other existing APIs to attach the disk to the necessary VM once the disk is cloned. On the NetApp side, we'll ensure the disk is coalesced before cloning so as to avoid the issues of registering snapshots. I am just curious about how the third party tool like NetApp to make sure the disk of a running VM coalesced before cloning? By an agent in the VM to flush file-system cache out to the disk? GetUnregisteredImagesQuery will be accessible through the disks resource collection on a storage domain. A disks resource collection does not yet exist and will need to be added. To access the unregistered images, a parameter (maybe unregistered=true) would be passed. So the path to GET the unregistered disk images on a domain would be something like /api/storagedomains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=true. This will return a list of disk images that can be each used as input to the ImportImageCommand to get them added to oVirt. ImportImageCommand will be accessible through POSTing a disk to /api/disks?import=true. The disk will be added to the oVirt DB based on the information supplied and afterward would be available to attach to a VM. When querying for unregistered disk images, the GetUnregisteredImagesQuery command will use the getImagesList() VDSM command. Currently this only reports the GUIDs of all disk images in a domain. I had been using the getVolumesList() and getVolumeInfo() VDSM commands to fill in the information so that valid disk image objects could be registered in oVirt. It seems these two functions are set to be removed since they are too invasive into the internal VDSM workings. The VDSM team will need to either return more information about each disk as part of the getImagesList() function or add a new function getImageInfo() that will give the same information for a given image GUID. Here is the project proposal for floating disk in oVirt. I think unregistered images are also floating disks. http://www.ovirt.org/Features/DetailedFloatingDisk Note that much of this work had originally been submitted under patch http://gerrit.ovirt.org/#/c/9603/. After several reviews it was found to be lacking in its design and was using deprecated APIs that did not yet have replacements. I'm reworking the code now to conform to this design and asking for further input from the VDSM, core, and restapi teams to ensure we can get this done quickly and correctly as it is needed for the 3.2 release. -Chris *Chris Morrissey* Software Engineer NetApp Inc. 919.476.4428 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- --- ?? Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] RFC: New Storage API
optimized, degraded, or broken.
Optimized means that the image is available and you can run VMs of it.
Degraded means that the image is available and will run VMs but it might be a
better way VDSM can represent the underlying data.
What does the represent mean here?
Broken means that the image can't be used at the moment, probably because not
all the data has been set up on the volume.
Apart from that VDSM will also return the last persisted status information
which will conatin
hostID - the last host to try and optimize of fix the image
Any host can optimize the image? No need to be SDM?
stage - X/Y (eg. 1/10) the last persisted stage of the fix.
percent_complete - -1 or 0-100, the last persisted completion percentage of the
aforementioned stage. -1 means that no progress is available for that operation.
last_error - This will only be filled if the operation failed because of
something other then IO or a VDSM crash for obvious reasons.
It will usually be set if the task was manually stopped
The user can either be satisfied with that information or as the host specified
in host ID if it is still working on that image by checking it's running tasks.
So we need a function to know what tasks are running on the image
checkStorageRepository(self, repositoryId, options={}):
A method to go over a storage repository and scan for any existing problems.
This includes degraded\broken images and deleted images that have no yet been
physically deleted\merged.
It returns a list of Fix objects.
Fix objects come in 4 types:
clean - cleans data, run them to get more space.
optimize - run them to optimize a degraded image
merge - Merges two images together. Doing this sometimes
makes more images ready optimizing or cleaning.
The reason it is different from optimize is that
unmerged images are considered optimized.
mend - mends a broken image
The user can read these types and prioritize fixes. Fixes also contain opaque
FIX data and they should be sent as received to
fixStorageRepository(self, repositoryId, fix, options={}):
That will start a fix operation.
All major operations automatically start the appropriate Fix to bring the
created object to an optimize\degraded state (the one that is quicker) unless one of the
options is
AutoFix=False. This is only useful for repos that might not be able to create
volumes on all hosts (SDM) but would like to have the actual IO distributed in
the cluster.
Other common options is the strategy option:
It has currently 2 possible values
space and performance - In case VDSM has 2 ways of completing the same
operation it will tell it to value one over the other. For example, whether to
copy all the data or just create a qcow based of a snapshot.
The default is space.
You might have also noticed that it is never explicitly specified where to look
for existing images. This is done purposefully, VDSM will always look in all
connected repositories for existing objects.
For very large setups this might be problematic. To mitigate the problem you
have these options:
participatingRepositories=[repoId, ...] which tell VDSM to narrow the search to
just these repositories
and
imageHints={imgId: repoId} which will force VDSM to look for those image ID
just in those repositories and fail if it doesn't find them there.
___
vdsm-devel mailing list
vdsm-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
--
---
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or
shum...@linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] is gerrit.ovirt.org down? eom
It seems gerrit has downed for several times recently. Is there any special reason? 于 2012-9-12 22:45, Alon Bar-Lev: yes. - Original Message - From: Shireesh Anjal san...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, September 12, 2012 5:43:35 PM Subject: [Engine-devel] is gerrit.ovirt.org down? eom ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shum...@cn.ibm.com or shum...@linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Domain rescan action question
vdsm and from oVirt's database, finding the ones vdsm returns that oVirt doesn't have, and then either adding or returning those images. So oVirt's db will be used in the comparison. This will work only when scanning storage domains already attached and in use by the current oVirt setup. What I am talking about is what will happen if a LUN that used to be a SD in another oVirt setup is discovered and scanned, with no engine db to compare with. If we don't consider such a use case, life is definitely quite easy, and we're basically within the scope of the orphaned images feature This use case should definitely be considered, maybe have a separate case where the rescan would return all compatible disks (i.e. disks that aren't just partial snapshots and the like) if the domain has not yet been mounted. Essentially, it would run the same comparison, but compare against an empty list rather than a list of disks. There's no way it's as simple as that (I'm unsure of the methods oVirt uses to mount a domain), but it's a good starting point. As far as presenting the user with nameless disks, that's a point I hadn't considered; we could generate some sort of placeholder metadata upon addition to show the user that these are new/orphaned disks that were found on the storage domain. Is it safe to assume that the disks discovered by this feature won't be attached to anything? The oVirt paradigm says if it isn't in the engine db, it's not ours, so any LV or image we discover that is missing from the DB or the snapshot chain of the image in the DB, is nameless, and orphaned. Such an image on a current SD, belonging to a working oVirt setup is definitely an orphaned image. Attaching these to VMs is usually also useless, because they are more often than not discarded snapshots that didn't get discarded cleanly for some reason. Now, if we want to make this usable, we might want to actually check the qcow2 metadata of the image to see whether it's a mid-chain snapshot (and if so it's probably just a candidate for cleanup), or a standalone qcow2 or raw image, and then we can move on with the virt-* tools, to find out the image size and the filesystems it contains. This will at least provide the user with some usable information about the detected image. If we're talking about scanning an SD that doesn't presently belong to the current oVirt setup, then this is even more relevant, because all of the images will have no VM-related context. We're currently working on having disks created outside of the oVirt environment, so not all orphaned disks on the existing storage domain will be artifacts of supposedly-deleted data. For our use case, disk images created by us will be able to be imported into oVirt and attached to a VM created through the engine. Because of this, saying if it isn't in the engine db, it's not ours wouldn't necessarily be true. When you talk about checking the metadata, does either oVirt or vdsm have a simple way to do this? A query of some sort would be ideal for this, as it could be run for each image as a qualifier for import. Also, as far as writing the functionality itself, I'm gathering that it should be structured as a query to return these orphaned images, which can then be acted upon/added to the database through a separate command after checking the validity of each image? [1] or a subtab on the storage domain. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Regards, Dan Yasny Red Hat Israel +972 9769 2280 -- Regards, Dan Yasny Red Hat Israel +972 9769 2280 -- Regards, Dan Yasny Red Hat Israel +972 9769 2280 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Shu Ming shum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: Storage-Domain creation - Used Luns
On 2012-7-1 23:10, Andrew Cathrow wrote: - Original Message - From: Shu Ming shum...@linux.vnet.ibm.com To: Ori Liel ol...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, July 1, 2012 10:50:47 AM Subject: Re: [Engine-devel] restapi: Storage-Domain creation - Used Luns SHARED_LUN? We won't be sharing them, we'll be overwriting them. Maybe something like overwrite or force ? So does the lun still belongs to the VG? How about the VG operation to acess the lun while the new storage-domain is accessing the lun? On 2012-7-1 16:50, Ori Liel wrote: We need to enable passing 'used' luns for new storage-domain creation (used = the lun is part of a VG). We need a way in rest-api to explicitly approve the use of such luns. Does anyone have a suggestion for a good name for such a flag, a name that conveys: use the given luns even if they are part of a VG? Thanks, Ori. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Shu Ming shum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Shu Ming shum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [virt-node] VDSM as a general purpose virt host manager
On 2012-6-20 5:32, Saggi Mizrahi wrote: There is an important discussion starting about the future of the VDSM API on vdsm-devel. If you want to be involved in the future of the VDSM API don't miss out and join vdsm-devel. To sign up go to https://fedorahosted.org/mailman/listinfo/vdsm-devel There growing need for a way to more easily reuse of the functionality of VDSM in order to service projects other than Ovirt-Engine. Originally VDSM was created as a proprietary agent for the sole purpose of serving the then proprietary version of what is known as ovirt-engine. Red Hat, after acquiring the technology, pressed on with it's commitment to open source ideals and released the code. But just releasing code into the wild doesn't build a community or makes a project successful. Further more when building open source software you should aspire to build reusable components instead of monolithic stacks. We would like to expose a stable, documented, well supported API. This gives us a chance to rethink the VDSM API from the ground up. There is already work in progress of making the internal logic of VDSM separate enough from the API layer so we could continue feature development and bug fixing while designing the API of the future. In order to achieve this though we need to do several things: 1. Declare API supportability guidelines 2. Decide on an API transport (e.g. REST, ZMQ, AMQP) 3. Make the API easily consumable (e.g. proper docs, example code, extending the API, etc) 4. Implement the API itself Now, VDSM version was highly bound with oVirt Engine version. In order to make oVirt to work, both VDSM and ovirt engine should be synced with the latest binary, no back compatibility yet. If we want to break this binding out, we should classify the level of the VDSM APIs like these: 1) public stable 2) public evolving 3) undocumented volatile And the we should make sure public stable interfaces to be supported in a very long time as possible as we can. public evolving interfaces should keep the compatibility in the same major release(ie, 4.x.x). undocumented volatile is not recommended to the application and it is the responsibility of the application to take the risk. All of these are dependent on one another and the permutations are endless. This is why I think we should try and work on each one separately. All discussions will be done openly on the mailing list and until the final version comes out nothing is set in stone. If you think you have anything to contribute to this process, please do so either by commenting on the discussions or by sending code/docs/whatever patches. Once the API solidifies it will be quite difficult to change fundamental things, so speak now or forever hold your peace. Note that this is just an introductory email. There will be a quick follow up email to kick start the discussions. Don't forget to sign up to the vdsm-devel mailing list. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Shu Ming shum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Questions about ovirt engine
Hi, I created a VM in my engine. And I found that every time I run the VM after shutdown, the VM uuid was changed to a different not while the VM itself was not changed including the VM name. Why doesn't engine keep the UUID for a VM and use the UUID every time the VM starts? How can I persistent my setting to a VM with vdsClient, like the password set by the setVmTicket command? -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt integration
On 2012-5-30 17:38, Deepak C Shetty wrote: Hello All, I have a draft write-up on the VDSM-libstoragemgmt integration. I wanted to run this thru' the mailing list(s) to help tune and crystallize it, before putting it on the ovirt wiki. I have run this once thru Ayal and Tony, so have some of their comments incorporated. I still have few doubts/questions, which I have posted below with lines ending with '?' Comments / Suggestions are welcome appreciated. thanx, deepak [Ccing engine-devel and libstoragemgmt lists as this stuff is relevant to them too] -- 1) Background: VDSM provides high level API for node virtualization management. It acts in response to the requests sent by oVirt Engine, which uses VDSM to do all node virtualization related tasks, including but not limited to storage management. libstoragemgmt aims to provide vendor agnostic API for managing external storage array. It should help system administrators utilizing open source solutions have a way to programmatically manage their storage hardware in a vendor neutral way. It also aims to facilitate management automation, ease of use and take advantage of storage vendor supported features which improve storage performance and space utilization. Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/ libstoragemgmt (LSM) today supports C and python plugins for talking to external storage array using SMI-S as well as native interfaces (eg: netapp plugin ) Plan is to grow the SMI-S interface as needed over time and add more vendor specific plugins for exploiting features not possible via SMI-S or have better alternatives than using SMI-S. For eg: Many of the copy offload features require to use vendor specific commands, which justifies the need for a vendor specific plugin. 2) Goals: 2a) Ability to plugin external storage array into oVirt/VDSM virtualization stack, in a vendor neutral way. 2b) Ability to list features/capabilities and other statistical info of the array 2c) Ability to utilize the storage array offload capabilities from oVirt/VDSM. 3) Details: LSM will sit as a new repository engine in VDSM. VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192 Current plan is to have LSM co-exist with VDSM on the virtualization nodes. Does that mean LSM will be a different daemon process than VDSM? Also, how about the vendor's plugin, another process in the nodes? *Note : 'storage' used below is generic. It can be a file/nfs-export for NAS targets and LUN/logical-drive for SAN targets. VDSM can use LSM and do the following... - Provision storage - Consume storage 3.1) Provisioning Storage using LSM Typically this will be done by a Storage administrator. oVirt/VDSM should provide storage admin the - ability to list the different storage arrays along with their types (NAS/SAN), capabilities, free/used space. - ability to provision storage using any of the array capabilities (eg: thin provisioned lun or new NFS export ) - ability to manage the provisioned storage (eg: resize/delete storage) Once the storage is provisioned by the storage admin, VDSM will have to refresh the host(s) for them to be able to see the newly provisioned storage. 3.1.1) Potential flows: Mgmt - vdsm - lsm: create LUN + LUN Mapping / Zoning / whatever is needed to make LUN available to list of hosts passed by mgmt Mgmt - vdsm: getDeviceList (refreshes host and gets list of devices) Repeat above for all relevant hosts (depending on list passed earlier, mostly relevant when extending an existing VG) Mgmt - use LUN in normal flows. 3.1.2) How oVirt Engine will know which LSM to use ? Normally the way this works today is that user can choose the host to use (default today is SPM), however there are a few flows where mgmt will know which host to use: 1. extend storage domain (add LUN to existing VG) - Use SPM and make sure *all* hosts that need access to this SD can see the new LUN 2. attach new LUN to a VM which is pinned to a specific host - use this host 3. attach new LUN to a VM which is not pinned - use a host from the cluster the VM belongs to and make sure all nodes in cluster can see the new LUN So this model depend on the work of removing storage pool? Flows for which there is no clear candidate (Maybe we can use the SPM host itself which is the default ?) 1. create a new disk without attaching it to any VM So the new floating disk should be exported to all nodes and all VMs? 2. create a LUN for a new storage domain 3.2) Consuming storage using LSM Typically this will be done by a virtualization administrator oVirt/VDSM should allow virtualization admin to - Create a new storage domain using the storage on the array. - Be able to specify whether VDSM should use the storage offload capability (default)
[Engine-devel] A small patch foy iso-uploader
Hi Can some review and approve this small patch? http://gerrit.ovirt.org/#/c/4554/ -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] engine complained that it couldn't find the ovirtmgmt interface in my FC16 ovirt node
Hi, I found the followings logs in my engine and engine set the node to non-operation state. It is strange that I can see the ovirtmgmt network interface was there in the ovirt node. Below are the logs and steps I did in ovirt node. It seems that engine didn't get the right network interface information from ovirt node. Can any one show me some steps to debug this problem? In my engine log: 2012-06-06 00:45:00,185 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (QuartzScheduler_Worker-68) [897fad0] START, SetVdsStatusVDSCommand(vdsId = 848bcff0-ae2a-11e1-bb49-5254001498c4, status=NonOperational, nonOperationalReason=NETWORK_UNREACHABLE), log id: 53d27ec8 2012-06-06 00:45:00,188 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (QuartzScheduler_Worker-68) [897fad0] FINISH, SetVdsStatusVDSCommand, log id: 53d27ec8 2012-06-06 00:45:00,190 INFO [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand] (QuartzScheduler_Worker-68) [897fad0] Host ovirt-node1 is set to Non-Operational, it is missing the following networks: ovirtmgmt, 2012-06-06 00:45:00,198 INFO [org.ovirt.engine.core.bll.HandleVdsCpuFlagsOrClusterChangedCommand] (QuartzScheduler_Worker-68) [60291e0d] Running command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entities affected : ID: 848bcff0-ae2a-11e1-bb49-5254001498c4 Type: VDS However in my ovirt node, the ovirtmgmt interface was there. [root@ovirt-node1 ~]# brctl show bridge name bridge id STP enabled interfaces ovirtmgmt 8000.5cf3fce432a0 no eth0 [root@ovirt-node1 ~]# [root@ovirt-node1 ~]# ifconfig -a|more bond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) bond1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) bond2 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) bond3 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) bond4 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth0 Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A0 inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:315 errors:0 dropped:0 overruns:0 frame:0 TX packets:143 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:30785 (30.0 KiB) TX bytes:38501 (37.5 KiB) Interrupt:28 Memory:9200-92012800 eth1 Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A2 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:40 Memory:9400-94012800 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:13156 errors:0 dropped:0 overruns:0 frame:0 TX packets:13156 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3271301 (3.1 MiB) TX bytes:3271301 (3.1 MiB) ovirtmgmt Link encap:Ethernet HWaddr 5C:F3:FC:E4:32:A0 inet addr:9.181.129.110 Bcast:9.181.129.255 Mask:255.255.255.0 inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:182 errors:0 dropped:3 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16290 (15.9 KiB) TX
[Engine-devel] oVirt automated test suites
Hi, I need a reasonable test suites to test VDSM APIs. I know most of tests are done from the engine side manually. But I think we need a reasonable test suites to define the typical workflows of engine usage calling into VDSM APIs and make sure all the functions are doing well. As engine publics REST-APIs, an automated test suites can be created on top of the REST-APs without much difficult. Any other comments about this idea? -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] is gerrit.ovirt.org down?
It seems the ping latency is high. C:\Documents and Settings\Administratorping gerrit.ovirt.org Pinging gerrit.ovirt.org [107.22.212.69] with 32 bytes of data: Reply from 107.22.212.69: bytes=32 time=388ms TTL=46 Reply from 107.22.212.69: bytes=32 time=373ms TTL=46 Reply from 107.22.212.69: bytes=32 time=369ms TTL=46 Reply from 107.22.212.69: bytes=32 time=369ms TTL=46 Ping statistics for 107.22.212.69: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 369ms, Maximum = 388ms, Average = 374ms C:\Documents and Settings\Administrator On 2012-5-23 0:43, Shireesh Anjal wrote: I have been unable to access the web UI or work with the repository for around half an hour now... ~Shireesh ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Where is the git workspace of engine-iso-uploader?
Hi, From this page, I am told that it should be in the same workspace as ovirt-engine. http://www.ovirt.org/project/subprojects/ However, I can not find it in ovirt-engine workspace. Where does it go? -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Where is the git workspace of engine-iso-uploader?
On 2012-5-18 20:54, Juan Hernandez wrote: On 05/18/2012 11:04 AM, Shu Ming wrote: From this page, I am told that it should be in the same workspace as ovirt-engine. http://www.ovirt.org/project/subprojects/ However, I can not find it in ovirt-engine workspace. Where does it go? Try this: git clone git://gerrit.ovirt.org/ovirt-iso-uploader I tried git clone git://gerrit.ovirt.org/engine-iso-uploader, no luck to success. I think ovirt-iso-uploader and enginer-iso-uploader are misused in some time. -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Where is the git workspace of engine-iso-uploader?
On 2012-5-18 23:26, Juan Hernandez wrote: On 05/18/2012 05:19 PM, Shu Ming wrote: On 2012-5-18 20:54, Juan Hernandez wrote: On 05/18/2012 11:04 AM, Shu Ming wrote: From this page, I am told that it should be in the same workspace as ovirt-engine. http://www.ovirt.org/project/subprojects/ However, I can not find it in ovirt-engine workspace. Where does it go? Try this: git clone git://gerrit.ovirt.org/ovirt-iso-uploader I tried git clone git://gerrit.ovirt.org/engine-iso-uploader, no luck to success. I think ovirt-iso-uploader and enginer-iso-uploader are misused in some time. I just did it again and it works correctly for me: Sorry for confusing. I cloned ovirt-iso-uploader workspace sucessfully. I thought the workspace name was engine-iso-uploader before. $ git clone git://gerrit.ovirt.org/ovirt-iso-uploader Cloning into 'ovirt-iso-uploader'... remote: Counting objects: 37, done. remote: Compressing objects: 100% (20/20), done. remote: Total 37 (delta 10), reused 37 (delta 10) Receiving objects: 100% (37/37), 23.70 KiB, done. Resolving deltas: 100% (10/10), done. Network or DNS problems? -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Stuck at the firewall.conf in vds_bootstrap
Hi, My vds_installer was stuck at running vds_bootstrap when I tried to add one host node in my ovirt-engine. For some reasons, the /tmp/firewall.conf.* file was not downloaded and that caused vds_bootstrap's failure. Is there any quick way to disable the -f option for vds_bootstrap in engine server or in host node? That will not allow vdsm to overwrite the firewall configurations in host. --- From the vds_install.xx.log in my host, here is the command where the vds_installer was stuck. /tmp/vds_bootstrap_1a9728df-e3b4-4d7b-8258-835038587bad.py -v -O cstl -t 2012-05-09T16:00:04 -f /tmp/firewall.conf.1a9728df-e3b4-4d7b-8258-835038587bad http://ovirt-engine-112:80/Components/vds/ 9.181.129.110 1a9728df-e3b4-4d7b-8258-835038587bad -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Stuck at the firewall.conf in vds_bootstrap
After changing the ovirt-engine-base/scripts/vds_installer.py to remove the -f option and correct -v to '-V, the host node now can be installed and started. It looks like that the options of vds_installer.py or vds_bootstrap.py was broken. On 2012-5-10 0:23, Shu Ming wrote: Hi, My vds_installer was stuck at running vds_bootstrap when I tried to add one host node in my ovirt-engine. For some reasons, the /tmp/firewall.conf.* file was not downloaded and that caused vds_bootstrap's failure. Is there any quick way to disable the -f option for vds_bootstrap in engine server or in host node? That will not allow vdsm to overwrite the firewall configurations in host. --- From the vds_install.xx.log in my host, here is the command where the vds_installer was stuck. /tmp/vds_bootstrap_1a9728df-e3b4-4d7b-8258-835038587bad.py -v -O cstl -t 2012-05-09T16:00:04 -f /tmp/firewall.conf.1a9728df-e3b4-4d7b-8258-835038587bad http://ovirt-engine-112:80/Components/vds/ 9.181.129.110 1a9728df-e3b4-4d7b-8258-835038587bad -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] vds_bootstrap.py 's residency
Hi, I am checking the VDSM and ovirt-engine workspace for vds_bootstrap.py file. It was found that vds_bootstrap.py file was in VDSM workspace and was packaged into vdsm-bootstrap rpm package. Also, it was found that in the host installation process, host node will try to get the vds_bootstrap.py from the engine server. But vds_bootstrap.py is not included in any engine packages. Does that mean we should install vdsm-bootstrap package into engine server? Why not package this file into engine packages instead of vdsm packages? -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version
After touch engine.ear.doreply in /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, ovirt engine can be accessed now. Thanks for your support. On 2012-5-2 0:50, Ofer Schreiber wrote: What about creating the engine.ear.dodeploy file as suggested earlier? On 1 May 2012, at 18:15, Shu Ming shum...@linux.vnet.ibm.com mailto:shum...@linux.vnet.ibm.com wrote: Oops. Actually, I deleted the engine.ear.failed and engine.ear was there untouched. Her is the directory hierarchy now in jboss deployment directory. [root@ovirt-engine-112 deployments]# pwd /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments [root@ovirt-engine-112 deployments]# ls -l total 16 lrwxrwxrwx. 1 root root 34 Apr 28 01:14 engine.ear - /usr/share/ovirt-engine/engine.ear -rw-r--r--. 1 jboss-as jboss-as 8868 Dec 2 05:10 README.txt lrwxrwxrwx. 1 root root 48 Apr 28 01:14 ROOT.war - /usr/share/ovirt-engine/resources/jboss/ROOT.war -rw-rw-r--. 1 jboss-as jboss-as8 Apr 28 01:14 ROOT.war.deployed [root@ovirt-engine-112 deployments]# On 2012-5-1 4:11, Ofer Schreiber wrote: Please re create the link to engine.ear. That's the base java code that contains webadmin. If it doesn't deploy, create also engine.ear.dodeploy Ofer. On 30 Apr 2012, at 19:23, Shu Ming shum...@linux.vnet.ibm.com mailto:shum...@linux.vnet.ibm.com wrote: After deleting the engine.ear in /usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, I can access the page now. Thanks for you suggestions. However, when I tried to access Administrator Portal(no SSL). The following errors were encountered. HTTP Status 404 - /webadmin *type* Status report *message* _/webadmin_ *description* _The requested resource (/webadmin) is not available._ JBoss Web/7.0.3.Final On 2012-4-30 15:22, Ofer Schreiber wrote: Looks like something went wrong with the .ear deployment. (already saw such an issue inhttp://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html) Can you please: 1. Stop JBoss 2. Make sure jboss deployment directory contain a single engine.ear - Remove engine.ear.failed (or similar files if exists) 3. Start JBoss again - Original Message - On 2012-4-29 19:33, Ofer Schreiber wrote: I need more info about this: 1. It looks like a clean install (DB created from scratch). why do you call it an upgrade? Sorry for confusion here. I used engine-cleanup and ran engine-setup again after the 3.1 RPM package were installed. 2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as and /var/log/ovirt-engine usually) [root@ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log 01:15:16,901 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.1.0.Beta1b Tesla started in 2405ms - Started 140 of 203 services (61 services are passive or on-demand) 01:15:17,207 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment engine.ear 01:15:17,431 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment ROOT.war 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in deployment directory. To trigger deployment create a file called ROOT.war.dodeploy 01:15:17,432 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in deployment directory. To trigger deployment create a file called engine.ear.dodeploy 01:15:17,478 ERROR [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014612: Operation (add) failed - address: ([(deployment = engine.ear)]): java.lang.IllegalStateException: JBAS014666: Duplicate resource [(deployment = engine.ear)] at org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471) [jboss-as-controller-7.1.0.Beta1b.jar:] at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170) at java.util.concurrent.FutureTask.run(FutureTask.java:166) [:1.6.0_24] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) [:1.6.0_24] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_24] at java.lang.Thread.run(Thread.java:679) [:1.6.0_24
Re: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version
After deleting the engine.ear in
/usr/share/jboss-as-7.1.0.Beta1b/standalone/deployments, I can access
the page now. Thanks for you suggestions.
However, when I tried to access Administrator Portal(no SSL). The
following errors were encountered.
HTTP Status 404 - /webadmin
*type* Status report
*message* _/webadmin_
*description* _The requested resource (/webadmin) is not available._
JBoss Web/7.0.3.Final
On 2012-4-30 15:22, Ofer Schreiber wrote:
Looks like something went wrong with the .ear deployment. (already saw such an
issue in http://lists.ovirt.org/pipermail/engine-devel/2012-January/000483.html)
Can you please:
1. Stop JBoss
2. Make sure jboss deployment directory contain a single engine.ear
- Remove engine.ear.failed (or similar files if exists)
3. Start JBoss again
- Original Message -
On 2012-4-29 19:33, Ofer Schreiber wrote:
I need more info about this:
1. It looks like a clean install (DB created from scratch). why do
you call it an upgrade?
Sorry for confusion here. I used engine-cleanup and ran engine-setup
again after the 3.1 RPM package were installed.
2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as
and /var/log/ovirt-engine usually)
[root@ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log
01:15:16,901 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS
7.1.0.Beta1b Tesla started in 2405ms - Started 140 of 203 services
(61
services are passive or on-demand)
01:15:17,207 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
deployment engine.ear
01:15:17,431 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
deployment ROOT.war
01:15:17,432 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in
deployment
directory. To trigger deployment create a file called
ROOT.war.dodeploy
01:15:17,432 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in
deployment directory. To trigger deployment create a file called
engine.ear.dodeploy
01:15:17,478 ERROR [org.jboss.as.controller]
(DeploymentScanner-threads
- 2) JBAS014612: Operation (add) failed - address: ([(deployment
=
engine.ear)]): java.lang.IllegalStateException: JBAS014666:
Duplicate
resource [(deployment = engine.ear)]
at
org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503)
[jboss-as-controller-7.1.0.Beta1b.jar:]
at
org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471)
[jboss-as-controller-7.1.0.Beta1b.jar:]
at
org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
[:1.6.0_24]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
[:1.6.0_24]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_24]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
[jboss-threads-2.0.0.GA.jar:]
01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS014654: Composite operation was
rolled back
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS014654: Composite operation was
rolled back
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) {JBAS014653: Composite operation
failed
and was rolled back. Steps that failed: = {Operation step-1 =
JBAS014749: Operation handler failed: JBAS014666: Duplicate resource
[(\deployment\ = \engine.ear\)]}}
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) undefined
3. Any error in the httpd log?
[root@ovirt-engine-112 ~]# cat /var/log/httpd/access_log
9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] GET / HTTP/1.0 404 -
- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)
9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] GET /favicon.ico
HTTP/1.0 404 - - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)
9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] GET /favicon.ico
HTTP/1.0 404 - - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.28)
Re: [Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version
On 2012-4-29 19:33, Ofer Schreiber wrote:
I need more info about this:
1. It looks like a clean install (DB created from scratch). why do you call it
an upgrade?
Sorry for confusion here. I used engine-cleanup and ran engine-setup
again after the 3.1 RPM package were installed.
2. Do you see any error in JBoss/engine logs? (/var/log/jboss-as and
/var/log/ovirt-engine usually)
[root@ovirt-engine-112 ~]# cat /var/log/jboss-as/console.log
01:15:16,901 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS
7.1.0.Beta1b Tesla started in 2405ms - Started 140 of 203 services (61
services are passive or on-demand)
01:15:17,207 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
deployment engine.ear
01:15:17,431 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed
deployment ROOT.war
01:15:17,432 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015003: Found ROOT.war in deployment
directory. To trigger deployment create a file called ROOT.war.dodeploy
01:15:17,432 INFO [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS015003: Found engine.ear in
deployment directory. To trigger deployment create a file called
engine.ear.dodeploy
01:15:17,478 ERROR [org.jboss.as.controller] (DeploymentScanner-threads
- 2) JBAS014612: Operation (add) failed - address: ([(deployment =
engine.ear)]): java.lang.IllegalStateException: JBAS014666: Duplicate
resource [(deployment = engine.ear)]
at
org.jboss.as.controller.OperationContextImpl.addResource(OperationContextImpl.java:503)
[jboss-as-controller-7.1.0.Beta1b.jar:]
at
org.jboss.as.controller.OperationContextImpl.createResource(OperationContextImpl.java:471)
[jboss-as-controller-7.1.0.Beta1b.jar:]
at
org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:170)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
[:1.6.0_24]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
[:1.6.0_24]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_24]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
[jboss-threads-2.0.0.GA.jar:]
01:15:17,482 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS014654: Composite operation was
rolled back
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) JBAS014654: Composite operation was
rolled back
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) {JBAS014653: Composite operation failed
and was rolled back. Steps that failed: = {Operation step-1 =
JBAS014749: Operation handler failed: JBAS014666: Duplicate resource
[(\deployment\ = \engine.ear\)]}}
01:15:17,483 ERROR [org.jboss.as.server.deployment.scanner]
(DeploymentScanner-threads - 1) undefined
3. Any error in the httpd log?
[root@ovirt-engine-112 ~]# cat /var/log/httpd/access_log
9.181.193.205 - - [30/Apr/2012:00:28:27 +0800] GET / HTTP/1.0 404 -
- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)
9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] GET /favicon.ico
HTTP/1.0 404 - - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)
9.181.193.205 - - [30/Apr/2012:00:28:44 +0800] GET /favicon.ico
HTTP/1.0 404 - - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)
9.181.193.205 - - [30/Apr/2012:00:28:54 +0800] GET / HTTP/1.0 404 -
- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28)
Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)
9.181.193.205 - - [30/Apr/2012:00:28:55 +0800] GET /favicon.ico
HTTP/1.0 404 - - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 ( .NET CLR 3.5.30729)
[root@ovirt-engine-112 ~]#
[root@ovirt-engine-112 ~]# cat /var/log/httpd/error_log
[Sun Apr 29 03:36:02 2012] [notice] Digest: generating secret for digest
authentication ...
[Sun Apr 29 03:36:02 2012] [notice] Digest: done
[Sun Apr 29 03:36:02 2012] [notice] SSL FIPS mode disabled
[Sun Apr 29 03:36:02 2012] [notice] Apache/2.2.22 (Unix) DAV/2
mod_ssl/2.2.22 OpenSSL/1.0.0h-fips configured -- resuming normal operations
[root@ovirt-engine-112 ~]#
4. What happens if you stop iptables and access your server with :8080?
The
[Engine-devel] Updating ovirt engine from 3.0 to the 3.1.0 version
Hi, I built a set of ovirt engine RPM packages from near the latest ovirt engine source code. However, when I try to access the engine server with URL http://ovirt-engine-112:80;, the browser displayed a blank page without http error returned. Any clue about what is going on here? Why didn't the engine administrator home page be shown? And the packages were also installed successfully in my target system, checked this by rpm -q -a|grep engine. I) upgraded the packages to the 3.1 [root@ovirt-engine-112 ~]# rpm -q -a |grep engine ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-log-collector-3.0.0_0001-1.6.fc16.x86_64 ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-jbossas-1.2-2.fc16.x86_64 ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64 ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64 gtk2-engines-2.20.2-2.fc15.x86_64 Step II) Then I used engine-setup to setup the engine. It seems that everything is ok, see the log below. - [root@ovirt-engine-112 ~]# engine-setup Welcome to oVirt Engine setup utility HTTP Port [80] : HTTPS Port [443] : Host fully qualified domain name, note that this name should be fully resolvable [ovirt-engine-112] : ERROR: domain is not a valid domain name User input failed validation, do you still wish to use it? (yes|no): yes Password for Administrator (admin@internal) : Warning: Weak Password. Confirm password : Organization Name for the Certificate: cstl The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'] [NFS] : Enter DB type for installation ['remote'| 'local'] [local] : Local database password : Warning: Weak Password. Confirm password : Should the installer configure NFS share on this server to be used as an ISO Domain? ['yes'| 'no'] [yes] : Mount point path: /iso-dom ERROR: mount point already exists in /etc/exports Mount point path: /iso-dom Display name for the ISO Domain: iso-domains Firewall ports need to be opened. You can let the installer configure iptables automatically overriding the current configuration. The old configuration will be backed up. Alternately you can configure the firewall later using an example iptables file found under /usr/share/ovirt-engine/conf/iptables.example Configure iptables ? ['yes'| 'no']: yes oVirt Engine will be installed using the following configuration: = http-port: 80 https-port:443 host-fqdn: ovirt-engine-112 auth-pass: org-name: cstl default-dc-type: NFS db-remote-install: local db-local-pass: nfs-mp:/iso-dom iso-domain-name: iso-domains config-nfs:yes override-iptables: yes Proceed with the configuration listed above? (yes|no): yes Installing: Configuring oVirt-engine... [ DONE ] Creating CA... [ DONE ] Editing JBoss Configuration... [ DONE ] Setting Database Configuration...[ DONE ] Setting Database Security... [ DONE ] Creating Database... [ DONE ] Updating the Default Data Center Storage Type... [ DONE ] Editing oVirt Engine Configuration...[ DONE ] Editing Postgresql Configuration... [ DONE ] Configuring the Default ISO Domain...[ DONE ] Configuring Firewall (iptables)... [ DONE ] Starting JBoss Service...[ DONE ] Handling HTTPD...[ DONE ] Installation completed successfully ** (Please allow oVirt Engine a few moments to start up.) Additional information: * SSL Certificate fingerprint: C6:01:83:93:4B:2C:2A:38:65:C8:49:C9:17:34:FE:4B:1C:10:D5:FF * SSH Public key fingerprint: 69:8c:bd:05:43:17:0a:43:a3:cc:62:7e:f7:be:0c:42 * A default ISO share has been created on this host. If IP based access restrictions are required, please edit /iso-dom entry in /etc/exports * The firewall has been updated, the old iptables configuration file was saved to /usr/share/ovirt-engine/conf/iptables.backup.011513-04282012_2225 * The installation log file is available at:
Re: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for fedora 16
On 2012-3-15 4:45, Eyal Edri wrote: fyi, a new Jenkins job has been added to jenkins.ovirt.org. you can now d/l fresh ovirt-engine rpms after each commit. the rpms are created and latest are stored here: http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/ the job will also notify the author in case his/her commit will break the rpm build. How does it notify the submitter? By echoing messages or email notification? latest rpms for now: ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm Enjoy, Eyal Edri oVirt Infra Team ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] engine.log was gone
Hi, I deleted the engine.log under /var/log/ovirt-engine by mistake. It seems that the log file can not be recreated whatever engine-clean and engine-setup were run. Even rebooting the server didn't work. Is there any quick way to bring my engine.log back? -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] engine.log was gone
On 2012-2-15 18:30, David Jaša wrote: Shu Ming píše v St 15. 02. 2012 v 17:17 +0800: Hi, I deleted the engine.log under /var/log/ovirt-engine by mistake. It seems that the log file can not be recreated whatever engine-clean and engine-setup were run. Even rebooting the server didn't work. Is there any quick way to bring my engine.log back? I would try to touch the file, modify permissions to match those of other log files in directory and then restore its selinux context. That is what I did. But don't know hot to restore its selinux context, do have have an example? David -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
