From veillard at redhat.com Thu Mar 1 01:59:42 2012 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 1 Mar 2012 09:59:42 +0800 Subject: freenode vs. oftc In-Reply-To: <4F4E50B2.3060904@redhat.com> References: <4F4E50B2.3060904@redhat.com> Message-ID: <20120301015942.GN4691@redhat.com> On Wed, Feb 29, 2012 at 11:22:10AM -0500, Perry Myers wrote: > Now that we've gotten #ovirt at freenode unblocked and reopened... > > Thoughts on making freenode our primary channel and deprecating the oftc > #ovirt channel? > > Many of our other related projects are on freenode (vdsm for example), > and so we're sort of an outlier by being on oftc. Consolidation on a > single irc network may be desirable. > > +1 and -1's appreciated, and we'll see if there is a consensus -1 from me, my nick DV is repeteadly taken by someone else on freenode and on a regular basis I'm kicked out due to authentication troubles and it's a pain to reactivate. That's the major reason I don't go on the Fedora channels. I still stay in #kvm though, as I usually don't have the issue, but there is nothing more fustrating than joining an IRC channel and being denied parole. Maybe the authentication can be managed on a channle case by case basis Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ From pmyers at redhat.com Thu Mar 1 02:20:57 2012 From: pmyers at redhat.com (Perry Myers) Date: Wed, 29 Feb 2012 21:20:57 -0500 Subject: freenode vs. oftc In-Reply-To: <20120301015942.GN4691@redhat.com> References: <4F4E50B2.3060904@redhat.com> <20120301015942.GN4691@redhat.com> Message-ID: <4F4EDD09.8080407@redhat.com> > -1 from me, my nick DV is repeteadly taken by someone else Why don't you register your nick? pmyers is registered for me on both freenode and oftc, so no one can impersonate me :) (No idea why someone would, but one never knows) From veillard at redhat.com Thu Mar 1 03:04:53 2012 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 1 Mar 2012 11:04:53 +0800 Subject: freenode vs. oftc In-Reply-To: <4F4EDD09.8080407@redhat.com> References: <4F4E50B2.3060904@redhat.com> <20120301015942.GN4691@redhat.com> <4F4EDD09.8080407@redhat.com> Message-ID: <20120301030453.GO4691@redhat.com> On Wed, Feb 29, 2012 at 09:20:57PM -0500, Perry Myers wrote: > > -1 from me, my nick DV is repeteadly taken by someone else > > Why don't you register your nick? pmyers is registered for me on both > freenode and oftc, so no one can impersonate me :) (No idea why someone > would, but one never knows) Because others used to register it as I said ... then I'm stuck ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ From yzaslavs at redhat.com Thu Mar 1 05:59:44 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 01 Mar 2012 07:59:44 +0200 Subject: freenode vs. oftc In-Reply-To: <4F4EDD09.8080407@redhat.com> References: <4F4E50B2.3060904@redhat.com> <20120301015942.GN4691@redhat.com> <4F4EDD09.8080407@redhat.com> Message-ID: <4F4F1050.5010300@redhat.com> On 03/01/2012 04:20 AM, Perry Myers wrote: >> -1 from me, my nick DV is repeteadly taken by someone else > > Why don't you register your nick? pmyers is registered for me on both > freenode and oftc, so no one can impersonate me :) (No idea why someone > would, but one never knows) In case someone does not know how to register nicks on irc - some IRC servers have a nick services bot called nickserv - Feel free to /msg nickserv help and it will send you info on how to register your nicks. IIRC, If someone is "taking" your nick, and is refusing to let it go (and this nick got registered) sending a message to nickserv with identification details will cause your nick to get released (either this person gets brutally disconnected from the server or his nick gets changes to some GuestXYZW where XYZW is some number). Yair > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From ewarszaw at redhat.com Thu Mar 1 06:36:19 2012 From: ewarszaw at redhat.com (Eduardo Warszawski) Date: Thu, 01 Mar 2012 01:36:19 -0500 (EST) Subject: Direct LUN feature page In-Reply-To: Message-ID: We would like to expose any block device (e.g. an external storage lun, accessible to hosts) as a local disk in the VM. Feature page: http://www.ovirt.org/wiki/Features/Direct_Lun Comments are welcome. From kwade at redhat.com Thu Mar 1 22:03:03 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 01 Mar 2012 14:03:03 -0800 Subject: Need a co-guest for FLOSS Weekly 7 March In-Reply-To: <37835A7A-47C1-4575-9D03-0415E890A4CB@cisco.com> References: <4F4D6D1E.20307@redhat.com> <37835A7A-47C1-4575-9D03-0415E890A4CB@cisco.com> Message-ID: <4F4FF217.3020109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/29/2012 07:08 AM, Kyle Mestery (kmestery) wrote: > Hi Karsten: > > If no one else has volunteered yet, I can join you for this, > although I may be at the same depth as Chris and Jason. :) Kyle, As you saw, Itamar is available for the interview. Make more sense to have him take point here? (I'll feel like the whiny little manager standing behind the all-star ball player. ;-D ) I'd like to use the interview to set us up for coming back in 6 months, after we've a few more releases done and that much more to talk about. If you are amendable, I would love to pass the baton around to you and maybe someone else. cheers - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPT/IX2ZIOBq0ODEERAmemAJ9OLfCx04IwLOps92I+tFY7fd0H2QCcDicV KA6ZXlszPNFX73U9JdQhWMM= =/Eva -----END PGP SIGNATURE----- From kmestery at cisco.com Fri Mar 2 21:33:58 2012 From: kmestery at cisco.com (Kyle Mestery (kmestery)) Date: Fri, 2 Mar 2012 21:33:58 +0000 Subject: Need a co-guest for FLOSS Weekly 7 March In-Reply-To: <4F4FF217.3020109@redhat.com> References: <4F4D6D1E.20307@redhat.com> <37835A7A-47C1-4575-9D03-0415E890A4CB@cisco.com> <4F4FF217.3020109@redhat.com> Message-ID: <08E7163A-D650-4EF3-9E0C-B66688EE38A6@cisco.com> On Mar 1, 2012, at 4:03 PM, Karsten 'quaid' Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/29/2012 07:08 AM, Kyle Mestery (kmestery) wrote: >> Hi Karsten: >> >> If no one else has volunteered yet, I can join you for this, >> although I may be at the same depth as Chris and Jason. :) > > Kyle, > > As you saw, Itamar is available for the interview. Make more sense to > have him take point here? (I'll feel like the whiny little manager > standing behind the all-star ball player. ;-D ) > > I'd like to use the interview to set us up for coming back in 6 > months, after we've a few more releases done and that much more to > talk about. If you are amendable, I would love to pass the baton > around to you and maybe someone else. > > cheers - Karsten This sounds like a great plan. Thanks for the update Karsten. Kyle From smizrahi at redhat.com Fri Mar 2 00:25:59 2012 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Thu, 01 Mar 2012 19:25:59 -0500 (EST) Subject: PosixFS feature page In-Reply-To: Message-ID: <0b65254d-6664-4a71-adf7-43b8c98782fc@zmail16.collab.prod.int.phx2.redhat.com> Hi all, Following is the link to the PosixFS (connect to generic fs types, e.g. GFS, GPFS, gLuster, etc) feature description Wiki page: http://www.ovirt.org/wiki/Features/PosixFSConnection Regards, Saggi From iheim at redhat.com Sun Mar 4 21:07:35 2012 From: iheim at redhat.com (Itamar Heim) Date: Sun, 04 Mar 2012 23:07:35 +0200 Subject: Direct LUN feature page In-Reply-To: References: Message-ID: <4F53D997.7080705@redhat.com> On 03/01/2012 08:36 AM, Eduardo Warszawski wrote: > We would like to expose any block device (e.g. an external storage lun, accessible to hosts) as a local disk in the VM. > > Feature page: > http://www.ovirt.org/wiki/Features/Direct_Lun > > Comments are welcome. what is the permission model (which permission is required to add a direct LUN)? to attach a disk to a VM? From kwade at redhat.com Mon Mar 5 23:42:36 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 05 Mar 2012 15:42:36 -0800 Subject: Schedule for 21 March workshop In-Reply-To: <4F39B360.8010706@redhat.com> References: <4F39B360.8010706@redhat.com> Message-ID: <4F554F6C.9050402@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Based on the feedback in this thread I have cooked up this agenda: URL I decided not to poll wider than this list. We already have enough must-have items to cover the entire day, and anyone with real requests for this workshop at this stage of the project is likely on arch at ovirt.org already. After we agree this is the agenda, I'll turn it over to the workshop mailing list and ask for their input on sessions, content, and timing - - so we'll have a chance to tune this agenda to the needs of the actual attendees. For this list, I made the engine tools and the how-to-participate sessions 30 minutes each as they should be relatively quick items. I gave the dev environment setup an hour, everything else is 45 minutes. The sessions run from 08:30 to 17:30 with 1.5 hours of lunch and breaks in there. Regarding the dev environment, we should plan on having a local mirror of everything needed, if possible. We don't want to rely upon having flawless Internet for this to be successful. The same may be true for other sessions, so consider what you can do if you have limited or no network access during the sessions. - - Karsten On 02/13/2012 05:05 PM, Karsten 'quaid' Wade wrote: > We need to figure out a schedule for the upcoming workshop. Based > on the last workshop, it shouldn't be hard to figure out what we > want to cover. > > The Red Hat, IBM, and Intel teams will have just come out of a > two-day intensive on the 19th and 20th, so will all be better > prepared to deal with the open workshop. > > The materials in the open workshop will be the same topics, but > covered in less depth. > > Here are some topic ideas I've heard so far: * oVirt > intro/overview/architecture * oVirt architecture * Engine deep > dive * VDSM deep dive * Getting started with dev environment * > API/SDK/CLI * Node * History and reports * Guest agent * Engine > tools * How to interact & participate * Open discussion > > What ideas do you have? > > What do you think must be covered? > > What do you think should be covered? > > What is safe to not cover? > > Thanks - Karsten _______________________________________________ > Arch mailing list Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPVU9s2ZIOBq0ODEERAlVaAJ9/g4HKmCn2exqZ4vWNr3IVUv5ofQCgqIlf vOsVbA2Tx0JiPMlgPJ+K2LM= =cSrG -----END PGP SIGNATURE----- From kwade at redhat.com Mon Mar 5 23:43:39 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 05 Mar 2012 15:43:39 -0800 Subject: Schedule for 21 March workshop In-Reply-To: <4F554F6C.9050402@redhat.com> References: <4F39B360.8010706@redhat.com> <4F554F6C.9050402@redhat.com> Message-ID: <4F554FAB.40308@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/05/2012 03:42 PM, Karsten 'quaid' Wade wrote: > Based on the feedback in this thread I have cooked up this agenda: > > URL http://www.ovirt.org/news-and-events/workshop/ I should stop typing URL as a placeholder and use ATTACH URL instead, so Thunderbird reminds me based on the keyword. :) - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPVU+r2ZIOBq0ODEERAms6AJ435x6f+FcIcVHrlcDBgq3Ui9ZSQwCaA36a omlXVdwQNz7MJZBs7bQlQLY= =i0eC -----END PGP SIGNATURE----- From fsimonce at redhat.com Tue Mar 6 09:24:35 2012 From: fsimonce at redhat.com (Federico Simoncelli) Date: Tue, 06 Mar 2012 04:24:35 -0500 (EST) Subject: Disk hotplug and snapshots In-Reply-To: Message-ID: Hi, looking at the disk hotplug feature in the wiki I was wondering how that fits with the current implementation of the snapshots on the engine side. As far as I know the snapshots are at VM level now (no sigle disk snapshots), so what happens when you hotplug a new disk (no snapshots) into a VM that already has one or more snapshots? (and the other way around if possible). It might be worth documenting it in the wiki. -- Federico From mkolesni at redhat.com Tue Mar 6 09:47:57 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Tue, 06 Mar 2012 04:47:57 -0500 (EST) Subject: Disk hotplug and snapshots In-Reply-To: Message-ID: <4ba5fe13-2968-491f-a828-a6cfda14a69b@zmail14.collab.prod.int.phx2.redhat.com> > Hi, > looking at the disk hotplug feature in the wiki I was wondering how > that fits with the current implementation of the snapshots on the > engine > side. > As far as I know the snapshots are at VM level now (no sigle disk > snapshots), > so what happens when you hotplug a new disk (no snapshots) into a VM > that > already has one or more snapshots? (and the other way around if > possible). What do you mean by 'hotplug'? By feature description, the disk is always part of VM even if it's unplugged. This is not the same as adding/removing disk to/from VM.. Snapshots should contain configuration which states if disk is plugged/unplugged - so if this configuration is present, it is used to determine the state of disks at that snapshot. Snapshots also contain a list of the disks that existed when snapshot was taken, so adding a new disk will not affect old snapshots either way. You can then hotplug this disk, but this has no affect on existing snapshots. When you unplug disk, it is still part of the VM and this also doesn't affect past snapshots. > It might be worth documenting it in the wiki. > > -- > Federico From fsimonce at redhat.com Tue Mar 6 10:42:30 2012 From: fsimonce at redhat.com (Federico Simoncelli) Date: Tue, 06 Mar 2012 05:42:30 -0500 (EST) Subject: Disk hotplug and snapshots In-Reply-To: <4ba5fe13-2968-491f-a828-a6cfda14a69b@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > From: "Mike Kolesnik" > To: "Federico Simoncelli" > Cc: "oVirt Arch" > Sent: Tuesday, March 6, 2012 10:47:57 AM > Subject: Re: Disk hotplug and snapshots > > > Hi, > > looking at the disk hotplug feature in the wiki I was wondering > > how > > that fits with the current implementation of the snapshots on the > > engine > > side. > > As far as I know the snapshots are at VM level now (no sigle disk > > snapshots), > > so what happens when you hotplug a new disk (no snapshots) into a > > VM > > that > > already has one or more snapshots? (and the other way around if > > possible). > > What do you mean by 'hotplug'? > By feature description, the disk is always part of VM even if it's > unplugged. > This is not the same as adding/removing disk to/from VM.. The real value of this feature is being able to dynamically add and remove disks from a running VM. Even if technically there's a difference (and btw only in the specific implementation in the engine) between hotplugging and adding/removing disks to/from a VM, they'll often be used together. > Snapshots should contain configuration which states if disk is > plugged/unplugged - so if this configuration is present, it is used > to determine the state of disks at that snapshot. > > Snapshots also contain a list of the disks that existed when snapshot > was taken, so adding a new disk will not affect old snapshots either > way. > You can then hotplug this disk, but this has no affect on existing > snapshots. > > When you unplug disk, it is still part of the VM and this also > doesn't affect past snapshots. One of the uses of the disk hotplug is being able to move disks from one VM to another. We have two special cases here: 1. you're removing a disk that was part of previous snapshot on the old VM (what happens if the user tries to revert? any spurious error since the disk is not there anymore?) 2. you're adding the disk that already contains a snapshot to a new VM, and you won't be able to control it anymore (merge, revert). Is this scenario not supported yet? -- Federico From mkolesni at redhat.com Tue Mar 6 12:33:03 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Tue, 06 Mar 2012 07:33:03 -0500 (EST) Subject: Disk hotplug and snapshots In-Reply-To: Message-ID: ----- Original Message ----- > ----- Original Message ----- > > From: "Mike Kolesnik" > > To: "Federico Simoncelli" > > Cc: "oVirt Arch" > > Sent: Tuesday, March 6, 2012 10:47:57 AM > > Subject: Re: Disk hotplug and snapshots > > > > > Hi, > > > looking at the disk hotplug feature in the wiki I was wondering > > > how > > > that fits with the current implementation of the snapshots on the > > > engine > > > side. > > > As far as I know the snapshots are at VM level now (no sigle disk > > > snapshots), > > > so what happens when you hotplug a new disk (no snapshots) into a > > > VM > > > that > > > already has one or more snapshots? (and the other way around if > > > possible). > > > > What do you mean by 'hotplug'? > > By feature description, the disk is always part of VM even if it's > > unplugged. > > This is not the same as adding/removing disk to/from VM.. > > The real value of this feature is being able to dynamically add and > remove disks from a running VM. > Even if technically there's a difference (and btw only in the > specific > implementation in the engine) between hotplugging and adding/removing > disks to/from a VM, they'll often be used together. It is a conceptual difference, not a technical one. > > > Snapshots should contain configuration which states if disk is > > plugged/unplugged - so if this configuration is present, it is used > > to determine the state of disks at that snapshot. > > > > Snapshots also contain a list of the disks that existed when > > snapshot > > was taken, so adding a new disk will not affect old snapshots > > either > > way. > > You can then hotplug this disk, but this has no affect on existing > > snapshots. > > > > When you unplug disk, it is still part of the VM and this also > > doesn't affect past snapshots. > > One of the uses of the disk hotplug is being able to move disks from > one VM to another. We have two special cases here: > > 1. you're removing a disk that was part of previous snapshot on the > old VM (what happens if the user tries to revert? any spurious > error since the disk is not there anymore?) What is the correct behavior here? Is the removed disk kept in the old VM's history, or is it removed also from history of the old VM? > 2. you're adding the disk that already contains a snapshot to a new > VM, and you won't be able to control it anymore (merge, revert). How is this possible? How do you get to a disk that has the history and is not part of VM? > > Is this scenario not supported yet? > > -- > Federico > From lpeer at redhat.com Tue Mar 6 14:35:24 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 06 Mar 2012 16:35:24 +0200 Subject: Disk hotplug and snapshots In-Reply-To: References: Message-ID: <4F5620AC.3060308@redhat.com> On 06/03/12 12:42, Federico Simoncelli wrote: > ----- Original Message ----- >> From: "Mike Kolesnik" >> To: "Federico Simoncelli" >> Cc: "oVirt Arch" >> Sent: Tuesday, March 6, 2012 10:47:57 AM >> Subject: Re: Disk hotplug and snapshots >> >>> Hi, >>> looking at the disk hotplug feature in the wiki I was wondering >>> how >>> that fits with the current implementation of the snapshots on the >>> engine >>> side. >>> As far as I know the snapshots are at VM level now (no sigle disk >>> snapshots), >>> so what happens when you hotplug a new disk (no snapshots) into a >>> VM >>> that >>> already has one or more snapshots? (and the other way around if >>> possible). >> >> What do you mean by 'hotplug'? >> By feature description, the disk is always part of VM even if it's >> unplugged. >> This is not the same as adding/removing disk to/from VM.. > > The real value of this feature is being able to dynamically add and > remove disks from a running VM. There are 2 different usages to this feature one of them is what you described above and the other is being able to start a VM without a specific disk but still have the disk connected to the VM (and have it available as part of the export flow for example). The API the engine exposes uses a little different terminology - we have activate/deactivate disk and attach/detach disk. The implementation of activate/deactivate a disk are either update the engine DB if the VM is down or hot plug the disk if the VM is up. The implementation of attach/detach is as follows - when a user attaches a disk he can choose if he wants to attach it as active or not, when a user detach a disk if the disk is active the user will get a warning in the UI, after confirming he wants to detach the disk inspite of it being active, the implementation is to unplug and detach the disk from the VM. > Even if technically there's a difference (and btw only in the specific > implementation in the engine) between hotplugging and adding/removing > disks to/from a VM, they'll often be used together. > >> Snapshots should contain configuration which states if disk is >> plugged/unplugged - so if this configuration is present, it is used >> to determine the state of disks at that snapshot. >> >> Snapshots also contain a list of the disks that existed when snapshot >> was taken, so adding a new disk will not affect old snapshots either >> way. >> You can then hotplug this disk, but this has no affect on existing >> snapshots. >> >> When you unplug disk, it is still part of the VM and this also >> doesn't affect past snapshots. > > One of the uses of the disk hotplug is being able to move disks from > one VM to another. We have two special cases here: > > 1. you're removing a disk that was part of previous snapshot on the > old VM (what happens if the user tries to revert? any spurious > error since the disk is not there anymore?) When removing a disk there are two behaviors we should support, remove with history or remove from active snapshot. Removing with history is translated to remove the disk and all the related volumes (except from the base one if it is part of template). Removing a disk only from active snapshot is a gap at this point and we need to implement it in the future. > 2. you're adding the disk that already contains a snapshot to a new > VM, and you won't be able to control it anymore (merge, revert). > Today snapshot is a VM snapshot there is no disk snapshot. Currently the engine blocks detaching a disk if it is part of a VM snapshot. There are some rejection on this behavior but I am not sure we'll be able to fix it anytime soon. > Is this scenario not supported yet? > From abaron at redhat.com Tue Mar 6 21:10:06 2012 From: abaron at redhat.com (Ayal Baron) Date: Tue, 06 Mar 2012 16:10:06 -0500 (EST) Subject: Schedule for 21 March workshop In-Reply-To: <4F554FAB.40308@redhat.com> Message-ID: <4ecbc6e4-f72d-4efb-8115-95270ea0485a@zmail13.collab.prod.int.phx2.redhat.com> Karsten, IIUC we would not be able to start so early and end so late? If that is correct then we'll need to cut to the bone here as there is just no way we'll cover so much in such short a time. 15:45 :: Getting started with development environment Unfortunately I do not believe that we'd be able to cover the getting started part. I suggest to send instructions on how to get started right away and urge participants to do it *before* the workshop and we'll help on the mailing lists so that when they arrive they already have a working setup (and a clue what oVirt is so that workshop could be done at a faster pace) I'd suggest the following revised schedule for a shorter 1 day workshop: (assuming 09:00 - 16:30. If this can be extended it would be preferable) 09:00 :: Registration 09:30 :: Welcome 09:45 :: oVirt Introduction and Overview 10:45 :: oVirt architecture 11:45 :: BREAK 12:00 :: Engine overview 12:45 :: LUNCH 13:45 :: VDSM overview 14:30 :: API/SDK/CLI 15:00 :: How to interact & participate 15:30 :: BREAK 15:45 :: Open discussion and feedback 16:30 :: DINNER ----- Original Message ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/05/2012 03:42 PM, Karsten 'quaid' Wade wrote: > > Based on the feedback in this thread I have cooked up this agenda: > > > > URL > > http://www.ovirt.org/news-and-events/workshop/ > > I should stop typing URL as a placeholder and use ATTACH URL instead, > so Thunderbird reminds me based on the keyword. :) > > - - Karsten > - -- > name: Karsten 'quaid' Wade, Sr. Community Architect > team: Red Hat Community Architecture & Leadership > uri: http://communityleadershipteam.org > http://TheOpenSourceWay.org > gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFPVU+r2ZIOBq0ODEERAms6AJ435x6f+FcIcVHrlcDBgq3Ui9ZSQwCaA36a > omlXVdwQNz7MJZBs7bQlQLY= > =i0eC > -----END PGP SIGNATURE----- > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From kwade at redhat.com Wed Mar 7 14:09:15 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 07 Mar 2012 06:09:15 -0800 Subject: Meeting today 1500 UTC #ovirt Message-ID: <4F576C0B.3020204@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A reminder about today's meeting. Agenda items I have: * Update on release process. * Beijing workshop status. ** 3/5ths full ** New pages with Chinese translations: http://www.ovirt.org/news-and-events/workshop/ http://lists.ovirt.org/project/resources/workshop-invitation/ ** Need to finalize open workshop agenda on arch@ - give your input * Anything else? - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPV2wL2ZIOBq0ODEERAq9IAKCRbTnwMUCRuLhfIq8KawluzsPejQCeMgfv H4gdH81E1NXzVm8WEmPRqvY= =xejE -----END PGP SIGNATURE----- From sgordon at redhat.com Wed Mar 7 15:51:49 2012 From: sgordon at redhat.com (Steve Gordon) Date: Wed, 07 Mar 2012 10:51:49 -0500 (EST) Subject: Release criteria for next ovirt release In-Reply-To: <77413083-8663-4b30-a6b5-97f399f06eee@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4ce5f952-070b-42fc-b8f1-03a7adbc3736@zmail15.collab.prod.int.phx2.redhat.com> Hi guys, Just a reminder, updates to the release criteria for the next release were originally due today (March 7th). Given the lack of activity on the page we have pushed it back to March 14th. Please ensure you review the criteria and update the page for us to discuss in the next meeting! http://www.ovirt.org/wiki/Second_Release Steve From mgoldboi at redhat.com Wed Mar 7 16:08:02 2012 From: mgoldboi at redhat.com (Moran Goldboim) Date: Wed, 07 Mar 2012 18:08:02 +0200 Subject: release blocking features for oVirt 3.1 Message-ID: <4F5787E2.4040403@redhat.com> for the upcoming ovirt release we have the following (http://www.ovirt.org/wiki/Second_Release): MUST * *MUST*: Upgrade from previous release * *MUST*: ovirt-node full cycle (register, approve and running VM) * *MUST*: No known data corruptors * *MUST*: Can define NFS, iSCSI, FC and local based storage domains * *MUST*: Can define VLAN based networks, bond interfaces, and have VLANs over bonded interfaces * *MUST*: Can authenticate users against at least one external LDAP server * *MUST*: Can run multiple VMs * *MUST*: Can connect to VMs using SPICE i would recommend adding (Musts): * no blockers on the lower level components - libvirt, lvm, device-mapper,qemu-kvm * all image related operations work - copy, move, import, export, snapshot (vm and template) * ovirt/host installation should work flawlessly (w/o ssl) * can do all above operations (define DC hierarchy so you can run vm) with gui/cli/python-api/rest-api * vm life-cycle is working flawlessly (start,suspend,resume,stop,migrate) additions, objections, thoughts? Moran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwade at redhat.com Thu Mar 8 01:14:45 2012 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Mar 2012 20:14:45 -0500 (EST) Subject: oVirt on FLOSS Weekly In-Reply-To: <391e00fd-d671-4fe5-8afd-78e30059943d@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <4ff2ded4-9b8a-42c8-9324-22cf3141f2a8@zmail12.collab.prod.int.phx2.redhat.com> Today Itamar and I were on FLOSS Weekly to talk about oVirt: http://twit.tv/show/floss-weekly/203 The show has a general-interest free/libre/open source software audience, so Itamar and I covered a bit of ground without digging to deep. Things went well, we can probably go back on the show in the future when we have something new to talk about :) ... and maybe next time it will be a few of you who do the interview instead. - Karsten -- name: Karsten 'quaid' Wade, Sr. Community Gardener team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 From iheim at redhat.com Thu Mar 8 07:28:28 2012 From: iheim at redhat.com (Itamar Heim) Date: Thu, 08 Mar 2012 09:28:28 +0200 Subject: release blocking features for oVirt 3.1 In-Reply-To: <4F5787E2.4040403@redhat.com> References: <4F5787E2.4040403@redhat.com> Message-ID: <4F585F9C.8090003@redhat.com> On 03/07/2012 06:08 PM, Moran Goldboim wrote: > i would recommend adding (Musts): > > * no blockers on the lower level components - libvirt, lvm, > device-mapper,qemu-kvm How do we quantify this - on their upstream latest version? in a specific distro? in all distros? From mgoldboi at redhat.com Thu Mar 8 12:34:54 2012 From: mgoldboi at redhat.com (Moran Goldboim) Date: Thu, 08 Mar 2012 14:34:54 +0200 Subject: release blocking features for oVirt 3.1 In-Reply-To: <4F585F9C.8090003@redhat.com> References: <4F5787E2.4040403@redhat.com> <4F585F9C.8090003@redhat.com> Message-ID: <4F58A76E.8000004@redhat.com> On 03/08/2012 09:28 AM, Itamar Heim wrote: > On 03/07/2012 06:08 PM, Moran Goldboim wrote: > >> i would recommend adding (Musts): >> >> * no blockers on the lower level components - libvirt, lvm, >> device-mapper,qemu-kvm > > How do we quantify this - on their upstream latest version? in a > specific distro? in all distros? i actually forgot to add two important deps - Jboss and Postgres since the release is per distro, the definition should be- no blockers on the lower layer components per distro released by oVirt on the go/no-go meeting. an example for it should be the iscsi-initiator problem we faced before first release on fedora. maybe each dev lead needs to define musts and shoulds for his component (different components within jboss we aren't depended to work with) Moran. From anthony at codemonkey.ws Sat Mar 10 18:24:47 2012 From: anthony at codemonkey.ws (Anthony Liguori) Date: Sat, 10 Mar 2012 12:24:47 -0600 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120310155843.GJ2914@otherpad.lan.raisama.net> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> Message-ID: <4F5B9C6F.3050705@codemonkey.ws> On 03/10/2012 09:58 AM, Eduardo Habkost wrote: > On Sat, Mar 10, 2012 at 12:42:46PM +0000, Daniel P. Berrange wrote: >>> >>> I could have sworn we had this discussion a year ago or so, and had decided >>> that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf >>> and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf >>> would be solely for end user configuration changes, not for QEMU builtin >>> defaults. >>> >>> But looking at the code in QEMU, it doesn't seem we ever implemented this ? >> >> Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but, >> contrary to our normal RHEL development practice, it was not based on >> a cherry-pick of an upstream patch :-( >> >> For sake of reference, I'm attaching the two patches from the RHEL6 source >> RPM that do what I'm describing >> >> NB, I'm not neccessarily advocating these patches for upstream. I still >> maintain that libvirt should write out a config file containing the >> exact CPU model description it desires and specify that with -readconfig. >> The end result would be identical from QEMU's POV and it would avoid >> playing games with QEMU's config loading code. > > I agree that libvirt should just write the config somewhere. The problem > here is to define: 1) what information should be mandatory on that > config data; 2) who should be responsible to test and maintain sane > defaults (and where should they be maintained). > > The current cpudef definitions are simply too low-level to require it to > be written from scratch. Lots of testing have to be done to make sure we > have working combinations of CPUID bits defined, so they can be used as > defaults or templates. Not facilitating reuse of those tested > defauls/templates by libvirt is duplication of efforts. > > Really, if we expect libvirt to define all the CPU bits from scratch on > a config file, we could as well just expect libvirt to open /dev/kvm > itself and call the all CPUID setup ioctl()s itself. That's how > low-level some of the cpudef bits are. Let's step back here. Why are you writing these patches? It's probably not because you have a desire to say -cpu Westmere when you run QEMU on your laptop. I'd wager to say that no human has ever done that or that if they had, they did so by accident because they read documentation and thought they had to. Humans probably do one of two things: 1) no cpu option or 2) -cpu host. So then why are you introducing -cpu Westmere? Because ovirt-engine has a concept of datacenters and the entire datacenter has to use a compatible CPU model to allow migration compatibility. Today, the interface that ovirt-engine exposes is based on CPU codenames. Presumably ovirt-engine wants to add a Westmere CPU group and as such have levied a requirement down the stack to QEMU. But there's no intrinsic reason why it uses CPU model names. VMware doesn't do this. It has a concept of compatibility groups[1]. oVirt could just as well define compatibility groups like GroupA, GroupB, GroupC, etc. and then the -cpu option we would be discussing would be -cpu GroupA. This is why it's a configuration option and not builtin to QEMU. It's a user interface as as such, should be defined at a higher level. Perhaps it really should be VDSM that is providing the model info to libvirt? Then they can add whatever groups then want whenever they want as long as we have the appropriate feature bits. P.S. I spent 30 minutes the other day helping a user who was attempting to figure out whether his processor was a Conroe, Penryn, etc. Making this determination is fairly difficult and it makes me wonder whether having CPU code names is even the best interface for oVirt.. [1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991 Regards, Anthony Liguori > > (Also, there are additional low-level bits that really have to be > maintained somewhere, just to have sane defaults. Currently many CPUID > leafs are exposed to the guest without letting the user control them, > and worse: without keeping stability of guest-visible bits when > upgrading Qemu or the host kernel. And that's what machine-types are > for: to have sane defaults to be used as base.) > > Let me give you a practical example: I had a bug report about improper > CPU topology information[1]. After investigating it, I have found out > that the "level" cpudef field is too low; CPU core topology information > is provided on CPUID leaf 4, and most of the Intel CPU models on Qemu > have level=2 today (I don't know why). So, Qemu is responsible for > exposing CPU topology information set using '-smp' to the guest OS, but > libvirt would have to be responsible for choosing a proper "level" value > that makes that information visible to the guest. We can _allow_ libvirt > to fiddle with these low-level bits, of course, but requiring every > management layer to build this low-level information from scratch is > just a recipe to waste developer time. > > (And I really hope that there's no plan to require all those low-level > bits to appear as-is on the libvirt XML definitions. Because that would > require users to read the Intel 64 and IA-32 Architectures Software > Developer's Manual, or the AMD64 Architecture Programmer's Manual and > BIOS and Kernel Developer's Guides, just to understand why something is > not working on his Virtual Machine.) > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=689665 > From acathrow at redhat.com Sun Mar 11 00:55:25 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Sat, 10 Mar 2012 19:55:25 -0500 (EST) Subject: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5B9C6F.3050705@codemonkey.ws> Message-ID: ----- Original Message ----- > From: "Anthony Liguori" > To: "Daniel P. Berrange" , libvir-list at redhat.com, qemu-devel at nongnu.org, "Gleb Natapov" > , "Jiri Denemark" , "Avi Kivity" , arch at ovirt.org > Sent: Saturday, March 10, 2012 1:24:47 PM > Subject: Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt > > On 03/10/2012 09:58 AM, Eduardo Habkost wrote: > > On Sat, Mar 10, 2012 at 12:42:46PM +0000, Daniel P. Berrange wrote: > >>> > >>> I could have sworn we had this discussion a year ago or so, and > >>> had decided > >>> that the default CPU models would be in something like > >>> /usr/share/qemu/cpu-x86_64.conf > >>> and loaded regardless of the -nodefconfig setting. > >>> /etc/qemu/target-x86_64.conf > >>> would be solely for end user configuration changes, not for QEMU > >>> builtin > >>> defaults. > >>> > >>> But looking at the code in QEMU, it doesn't seem we ever > >>> implemented this ? > >> > >> Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu > >> RPMs but, > >> contrary to our normal RHEL development practice, it was not based > >> on > >> a cherry-pick of an upstream patch :-( > >> > >> For sake of reference, I'm attaching the two patches from the > >> RHEL6 source > >> RPM that do what I'm describing > >> > >> NB, I'm not neccessarily advocating these patches for upstream. I > >> still > >> maintain that libvirt should write out a config file containing > >> the > >> exact CPU model description it desires and specify that with > >> -readconfig. > >> The end result would be identical from QEMU's POV and it would > >> avoid > >> playing games with QEMU's config loading code. > > > > I agree that libvirt should just write the config somewhere. The > > problem > > here is to define: 1) what information should be mandatory on that > > config data; 2) who should be responsible to test and maintain sane > > defaults (and where should they be maintained). > > > > The current cpudef definitions are simply too low-level to require > > it to > > be written from scratch. Lots of testing have to be done to make > > sure we > > have working combinations of CPUID bits defined, so they can be > > used as > > defaults or templates. Not facilitating reuse of those tested > > defauls/templates by libvirt is duplication of efforts. > > > > Really, if we expect libvirt to define all the CPU bits from > > scratch on > > a config file, we could as well just expect libvirt to open > > /dev/kvm > > itself and call the all CPUID setup ioctl()s itself. That's how > > low-level some of the cpudef bits are. > > Let's step back here. > > Why are you writing these patches? It's probably not because you > have a desire > to say -cpu Westmere when you run QEMU on your laptop. I'd wager to > say that no > human has ever done that or that if they had, they did so by accident > because > they read documentation and thought they had to. > > Humans probably do one of two things: 1) no cpu option or 2) -cpu > host. > > So then why are you introducing -cpu Westmere? Because ovirt-engine > has a > concept of datacenters and the entire datacenter has to use a > compatible CPU > model to allow migration compatibility. Today, the interface that > ovirt-engine > exposes is based on CPU codenames. Presumably ovirt-engine wants to > add a > Westmere CPU group and as such have levied a requirement down the > stack to QEMU. > > But there's no intrinsic reason why it uses CPU model names. VMware > doesn't do > this. It has a concept of compatibility groups[1]. s/has/had That was back in the 3.5 days and it was hit and miss, it relied on a user putting the same kind of machines in the resource groups and often caused issues. Now they've moved up to a model very similar to what we're using: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212 > > oVirt could just as well define compatibility groups like GroupA, > GroupB, > GroupC, etc. and then the -cpu option we would be discussing would be > -cpu GroupA. > > This is why it's a configuration option and not builtin to QEMU. > It's a user > interface as as such, should be defined at a higher level. > > Perhaps it really should be VDSM that is providing the model info to > libvirt? > Then they can add whatever groups then want whenever they want as > long as we > have the appropriate feature bits. I think the "real" (model specific) names are the best place to start. But if a user wants to override those with their own specific types then it should be allowed > > P.S. I spent 30 minutes the other day helping a user who was > attempting to > figure out whether his processor was a Conroe, Penryn, etc. Making > this > determination is fairly difficult and it makes me wonder whether > having CPU code > names is even the best interface for oVirt.. I think that was more about a bad choice in UI than a bad choice in the architecture. It should be made clear to a user what kind of machine they have and what it's capabilities are This bug was borne out of that issue https://bugzilla.redhat.com/show_bug.cgi?id=799708 > > [1] > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991 > > Regards, > > Anthony Liguori > > > > > (Also, there are additional low-level bits that really have to be > > maintained somewhere, just to have sane defaults. Currently many > > CPUID > > leafs are exposed to the guest without letting the user control > > them, > > and worse: without keeping stability of guest-visible bits when > > upgrading Qemu or the host kernel. And that's what machine-types > > are > > for: to have sane defaults to be used as base.) > > > > Let me give you a practical example: I had a bug report about > > improper > > CPU topology information[1]. After investigating it, I have found > > out > > that the "level" cpudef field is too low; CPU core topology > > information > > is provided on CPUID leaf 4, and most of the Intel CPU models on > > Qemu > > have level=2 today (I don't know why). So, Qemu is responsible for > > exposing CPU topology information set using '-smp' to the guest OS, > > but > > libvirt would have to be responsible for choosing a proper "level" > > value > > that makes that information visible to the guest. We can _allow_ > > libvirt > > to fiddle with these low-level bits, of course, but requiring every > > management layer to build this low-level information from scratch > > is > > just a recipe to waste developer time. > > > > (And I really hope that there's no plan to require all those > > low-level > > bits to appear as-is on the libvirt XML definitions. Because that > > would > > require users to read the Intel 64 and IA-32 Architectures Software > > Developer's Manual, or the AMD64 Architecture Programmer's Manual > > and > > BIOS and Kernel Developer's Guides, just to understand why > > something is > > not working on his Virtual Machine.) > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=689665 > > > > -- > libvir-list mailing list > libvir-list at redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > From anthony at codemonkey.ws Sun Mar 11 14:12:58 2012 From: anthony at codemonkey.ws (Anthony Liguori) Date: Sun, 11 Mar 2012 09:12:58 -0500 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120311132755.GJ17882@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> Message-ID: <4F5CB2EA.10000@codemonkey.ws> On 03/11/2012 08:27 AM, Gleb Natapov wrote: > On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: >> Let's step back here. >> >> Why are you writing these patches? It's probably not because you >> have a desire to say -cpu Westmere when you run QEMU on your laptop. >> I'd wager to say that no human has ever done that or that if they >> had, they did so by accident because they read documentation and >> thought they had to. >> > I'd be glad if QEMU will chose -cpu Westmere for me if it detects > Westmere host CPU as a default. This is -cpu best that Alex proposed FWIW. >> Humans probably do one of two things: 1) no cpu option or 2) -cpu host. >> > And both are not optimal. Actually both are bad. First one because > default cpu is very conservative and the second because there is no > guaranty that guest will continue to work after qemu or kernel upgrade. > > Let me elaborate about the later. Suppose host CPU has kill_guest > feature and at the time a guest was installed it was not implemented by > kvm. Since it was not implemented by kvm it was not present in vcpu > during installation and the guest didn't install "workaround kill_guest" > module. Now unsuspecting user upgrades the kernel and tries to restart > the guest and fails. He writes angry letter to qemu-devel and is asked to > reinstall his guest and move along. -cpu best wouldn't solve this. You need a read/write configuration file where QEMU probes the available CPU and records it to be used for the lifetime of the VM. >> So then why are you introducing -cpu Westmere? Because ovirt-engine >> has a concept of datacenters and the entire datacenter has to use a >> compatible CPU model to allow migration compatibility. Today, the >> interface that ovirt-engine exposes is based on CPU codenames. >> Presumably ovirt-engine wants to add a Westmere CPU group and as >> such have levied a requirement down the stack to QEMU. >> > First of all this is not about live migration only. Guest visible vcpu > should not change after guest reboot (or hibernate/resume) too. And > second this concept exists with only your laptop and single guest on it > too. There are three inputs into a "CPU model module": 1) host cpu, 2) > qemu capabilities, 3) kvm capabilities. With datacenters scenario all > three can change, with your laptop only last two can change (first one > can change too when you'll get new laptop) , but the net result is that > guest visible cpuid can change and it shouldn't. This is the goal of > introducing -cpu Westmere, to prevent it from happening. This discussion isn't about whether QEMU should have a Westmere processor definition. In fact, I think I already applied that patch. It's a discussion about how we handle this up and down the stack. The question is who should define and manage CPU compatibility. Right now QEMU does to a certain degree, libvirt discards this and does it's own thing, and VDSM/ovirt-engine assume that we're providing something and has built a UI around it. What I'm proposing we consider: have VDSM manage CPU definitions in order to provide a specific user experience in ovirt-engine. We would continue to have Westmere/etc in QEMU exposed as part of the user configuration. But I don't think it makes a lot of sense to have to modify QEMU any time a new CPU comes out. Regards, Anthony Liguori From anthony at codemonkey.ws Sun Mar 11 15:33:15 2012 From: anthony at codemonkey.ws (Anthony Liguori) Date: Sun, 11 Mar 2012 10:33:15 -0500 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120311145655.GK17882@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> Message-ID: <4F5CC5BB.3070000@codemonkey.ws> On 03/11/2012 09:56 AM, Gleb Natapov wrote: > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >> -cpu best wouldn't solve this. You need a read/write configuration >> file where QEMU probes the available CPU and records it to be used >> for the lifetime of the VM. > That what I thought too, but this shouldn't be the case (Avi's idea). > We need two things: 1) CPU model config should be per machine type. > 2) QEMU should refuse to start if it cannot create cpu exactly as > specified by model config. This would either mean: A. pc-1.1 uses -cpu best with a fixed mask for 1.1 B. pc-1.1 hardcodes Westmere or some other family (A) would imply a different CPU if you moved the machine from one system to another. I would think this would be very problematic from a user's perspective. (B) would imply that we had to choose the least common denominator which is essentially what we do today with qemu64. If you want to just switch qemu64 to Conroe, I don't think that's a huge difference from what we have today. >> It's a discussion about how we handle this up and down the stack. >> >> The question is who should define and manage CPU compatibility. >> Right now QEMU does to a certain degree, libvirt discards this and >> does it's own thing, and VDSM/ovirt-engine assume that we're >> providing something and has built a UI around it. > If we want QEMU to be usable without management layer then QEMU should > provide stable CPU models. Stable in a sense that qemu, kernel or CPU > upgrade does not change what guest sees. We do this today by exposing -cpu qemu64 by default. If all you're advocating is doing -cpu Conroe by default, that's fine. But I fail to see where this fits into the larger discussion here. The problem to solve is: I want to use the largest possible subset of CPU features available uniformly throughout my datacenter. QEMU and libvirt have single node views so they cannot solve this problem on their own. Whether that subset is a generic Westmere-like processor that never existed IRL or a specific Westmere processor seems like a decision that should be made by the datacenter level manager with the node level view. If I have a homogeneous environments of Xeon 7540, I would probably like to see a Xeon 7540 in my guest. Doesn't it make sense to enable the management tool to make this decision? Regards, Anthony Liguori From hkran at cn.ibm.com Wed Mar 7 10:58:42 2012 From: hkran at cn.ibm.com (Hui Kai Ran) Date: Wed, 7 Mar 2012 18:58:42 +0800 Subject: Fw: oVirt workshop In-Reply-To: <4F5648F7.1050909@redhat.com> References: <20120305154944.GE21384@us.ibm.com> <4F5648F7.1050909@redhat.com> Message-ID: The draft agenda is based on all the topics that Jason sent to me, if you have update those~, let us change it~ It is a challenge that most of audience are chinese and all speakers give presentations in english~. So, we are planning to select some volunteers from our team to take the role of translators who will help audience to understand what the speakers say. Of couse, they need to do some pratices on 19,20 March and make themselves get familiar with the contents ahead of time ~ here are some infos about the venue for your reference: we have two conference rooms: one with the capability of 84 fixed seats, the othter with the capability of 24 seats which can be extended to 35 Hui Kai Ran, Staff Software Engineer, KVM Development Tel : 86-10-82451628 E-mail: hkran at cn.ibm.com From: "Karsten 'quaid' Wade" To: Hui Kai Ran/China/IBM at IBMCN Cc: Frank Novak , agl at linux.vnet.ibm.com, Chang Ming Bai/China/IBM at IBMCN, De Xin AD Wu/China/IBM at IBMCN, Ming M Shu/China/IBM at IBMCN, Shao He Feng/China/IBM at IBMCN, Wen Jun Luo/China/IBM at IBMCN, Wen Ruo Lv/China/IBM at IBMCN, Jason Brooks Date: 03/07/2012 02:55 AM Subject: Re: Fw: oVirt workshop -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/2012 01:50 AM, Hui Kai Ran wrote: > Hi, > > After some adjustment to the agenda on 21 March, I'd like to put it > here and get Redhat involved in to discuss it. (I'd like to end the > workshop at 5PM rather than later, because chinese attendees > generally do not get used to such a "long workshop", which maybe is > a "china feature". ) Thank you very much for adjusting my initial ideas to the local culture and expectations. Your list may have dropped some items that others said are MUST topics in the discussion on arch at ovirt.org. Perhaps we can give less time to more topics? Could you forward your suggestions to the thread on arch at ovirt.org? We need to discuss with that group what are the real topics we want and can cover. > BTW, Karsten, how about the agenda on 19,20 March? Could you give > us the agenda on the two days? I have only been working on the open workshop agenda. My understanding is the Red Hat team want to cover all the topics I included in the open agenda at more depth and breadth. It would be good to hear from IBM and Intel what they want to hear about in the 2-day workshop. Do we know who is attending this workshop? Maybe we can make a mailing list for just those people to discuss the agenda, etc. - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPVkj32ZIOBq0ODEERAoueAKCEdi+IVX0lWs2md3mmjZQA9k/3QwCguw7Q MQKGknxcEwIWX/GPUElQACw= =TcoI -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From afaerber at suse.de Sat Mar 10 18:37:28 2012 From: afaerber at suse.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sat, 10 Mar 2012 19:37:28 +0100 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5B9C6F.3050705@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> Message-ID: <4F5B9F68.3050802@suse.de> Am 10.03.2012 19:24, schrieb Anthony Liguori: > Humans probably do one of two things: 1) no cpu option or 2) -cpu host. > > So then why are you introducing -cpu Westmere? [...] > P.S. I spent 30 minutes the other day helping a user who was attempting > to figure out whether his processor was a Conroe, Penryn, etc. Making > this determination is fairly difficult and it makes me wonder whether > having CPU code names is even the best interface for oVirt.. That's why Alex suggested -cpu best, which goes through all those definitions whatever their name and chooses the closest one IIUC. http://patchwork.ozlabs.org/patch/134955/ Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg From cardoe at gentoo.org Sat Mar 10 22:39:21 2012 From: cardoe at gentoo.org (Doug Goldstein) Date: Sat, 10 Mar 2012 16:39:21 -0600 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5B9C6F.3050705@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> Message-ID: On Sat, Mar 10, 2012 at 12:24 PM, Anthony Liguori wrote: > On 03/10/2012 09:58 AM, Eduardo Habkost wrote: >> >> On Sat, Mar 10, 2012 at 12:42:46PM +0000, Daniel P. Berrange wrote: >>>> >>>> >>>> I could have sworn we had this discussion a year ago or so, and had >>>> decided >>>> that the default CPU models would be in something like >>>> /usr/share/qemu/cpu-x86_64.conf >>>> and loaded regardless of the -nodefconfig setting. >>>> /etc/qemu/target-x86_64.conf >>>> would be solely for end user configuration changes, not for QEMU builtin >>>> defaults. >>>> >>>> But looking at the code in QEMU, it doesn't seem we ever implemented >>>> this ? >>> >>> >>> Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs >>> but, >>> contrary to our normal RHEL development practice, it was not based on >>> a cherry-pick of an upstream patch :-( >>> >>> For sake of reference, I'm attaching the two patches from the RHEL6 >>> source >>> RPM that do what I'm describing >>> >>> NB, I'm not neccessarily advocating these patches for upstream. I still >>> maintain that libvirt should write out a config file containing the >>> exact CPU model description it desires and specify that with -readconfig. >>> The end result would be identical from QEMU's POV and it would avoid >>> playing games with QEMU's config loading code. >> >> >> I agree that libvirt should just write the config somewhere. The problem >> here is to define: 1) what information should be mandatory on that >> config data; 2) who should be responsible to test and maintain sane >> defaults (and where should they be maintained). >> >> The current cpudef definitions are simply too low-level to require it to >> be written from scratch. Lots of testing have to be done to make sure we >> have working combinations of CPUID bits defined, so they can be used as >> defaults or templates. Not facilitating reuse of those tested >> defauls/templates by libvirt is duplication of efforts. >> >> Really, if we expect libvirt to define all the CPU bits from scratch on >> a config file, we could as well just expect libvirt to open /dev/kvm >> itself and call the all CPUID setup ioctl()s itself. That's how >> low-level some of the cpudef bits are. > > > Let's step back here. > > Why are you writing these patches? ?It's probably not because you have a > desire to say -cpu Westmere when you run QEMU on your laptop. ?I'd wager to > say that no human has ever done that or that if they had, they did so by > accident because they read documentation and thought they had to. > > Humans probably do one of two things: 1) no cpu option or 2) -cpu host. > > So then why are you introducing -cpu Westmere? ?Because ovirt-engine has a > concept of datacenters and the entire datacenter has to use a compatible CPU > model to allow migration compatibility. ?Today, the interface that > ovirt-engine exposes is based on CPU codenames. ?Presumably ovirt-engine > wants to add a Westmere CPU group and as such have levied a requirement down > the stack to QEMU. > > But there's no intrinsic reason why it uses CPU model names. ?VMware doesn't > do this. ?It has a concept of compatibility groups[1]. > > oVirt could just as well define compatibility groups like GroupA, GroupB, > GroupC, etc. and then the -cpu option we would be discussing would be -cpu > GroupA. > > This is why it's a configuration option and not builtin to QEMU. ?It's a > user interface as as such, should be defined at a higher level. > > Perhaps it really should be VDSM that is providing the model info to > libvirt? Then they can add whatever groups then want whenever they want as > long as we have the appropriate feature bits. > > P.S. I spent 30 minutes the other day helping a user who was attempting to > figure out whether his processor was a Conroe, Penryn, etc. ?Making this > determination is fairly difficult and it makes me wonder whether having CPU > code names is even the best interface for oVirt.. > > [1] > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991 > > Regards, > > Anthony Liguori FWIW, as a user this would be a good improvement. As it stands right now when a cluster of machines is established as being redundant migratable machines for each other I must do the following for each machine: virsh -c qemu://machine/system capabilities | xpath /capabilities/host/cpu > machine-cpu.xml Once I have that data I combine them together and use virsh cpu-baseline, which is a handy addition from the past of doing it manually, but still not optimal. This gives me a model which is mostly meaningless and uninteresting to me, but I know all the guests must use Penryn for example. If ovirt and by extension libvirt let me know that guest X is running on CPU-A, I know I could migrate it to any other machine supporting CPU-A or CPU-B (assuming B is a super set of A). -- Doug Goldstein From gleb at redhat.com Sun Mar 11 13:27:55 2012 From: gleb at redhat.com (Gleb Natapov) Date: Sun, 11 Mar 2012 15:27:55 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5B9C6F.3050705@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> Message-ID: <20120311132755.GJ17882@redhat.com> On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > Let's step back here. > > Why are you writing these patches? It's probably not because you > have a desire to say -cpu Westmere when you run QEMU on your laptop. > I'd wager to say that no human has ever done that or that if they > had, they did so by accident because they read documentation and > thought they had to. > I'd be glad if QEMU will chose -cpu Westmere for me if it detects Westmere host CPU as a default. > Humans probably do one of two things: 1) no cpu option or 2) -cpu host. > And both are not optimal. Actually both are bad. First one because default cpu is very conservative and the second because there is no guaranty that guest will continue to work after qemu or kernel upgrade. Let me elaborate about the later. Suppose host CPU has kill_guest feature and at the time a guest was installed it was not implemented by kvm. Since it was not implemented by kvm it was not present in vcpu during installation and the guest didn't install "workaround kill_guest" module. Now unsuspecting user upgrades the kernel and tries to restart the guest and fails. He writes angry letter to qemu-devel and is asked to reinstall his guest and move along. > So then why are you introducing -cpu Westmere? Because ovirt-engine > has a concept of datacenters and the entire datacenter has to use a > compatible CPU model to allow migration compatibility. Today, the > interface that ovirt-engine exposes is based on CPU codenames. > Presumably ovirt-engine wants to add a Westmere CPU group and as > such have levied a requirement down the stack to QEMU. > First of all this is not about live migration only. Guest visible vcpu should not change after guest reboot (or hibernate/resume) too. And second this concept exists with only your laptop and single guest on it too. There are three inputs into a "CPU model module": 1) host cpu, 2) qemu capabilities, 3) kvm capabilities. With datacenters scenario all three can change, with your laptop only last two can change (first one can change too when you'll get new laptop) , but the net result is that guest visible cpuid can change and it shouldn't. This is the goal of introducing -cpu Westmere, to prevent it from happening. > But there's no intrinsic reason why it uses CPU model names. VMware > doesn't do this. It has a concept of compatibility groups[1]. > As Andrew noted, not any more. There is no intrinsic reason, but people are more familiar with Intel terminology than random hypervisor terminology. > oVirt could just as well define compatibility groups like GroupA, > GroupB, GroupC, etc. and then the -cpu option we would be discussing > would be -cpu GroupA. It could, but I can't see why this is less confusing. > > This is why it's a configuration option and not builtin to QEMU. > It's a user interface as as such, should be defined at a higher > level. This is not the only configuration that is builtin in QEMU. As it stands now QEMU does not even allow configuring cpuid enough to define those compatibility groups outside of QEMU. And after the work is done to allow enough configurability there is no much left to provide compatibility groups in QEMU itself. > > Perhaps it really should be VDSM that is providing the model info to > libvirt? Then they can add whatever groups then want whenever they > want as long as we have the appropriate feature bits. > > P.S. I spent 30 minutes the other day helping a user who was > attempting to figure out whether his processor was a Conroe, Penryn, > etc. Making this determination is fairly difficult and it makes me > wonder whether having CPU code names is even the best interface for > oVirt.. > > [1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991 > > Regards, > > Anthony Liguori > > > > >(Also, there are additional low-level bits that really have to be > >maintained somewhere, just to have sane defaults. Currently many CPUID > >leafs are exposed to the guest without letting the user control them, > >and worse: without keeping stability of guest-visible bits when > >upgrading Qemu or the host kernel. And that's what machine-types are > >for: to have sane defaults to be used as base.) > > > >Let me give you a practical example: I had a bug report about improper > >CPU topology information[1]. After investigating it, I have found out > >that the "level" cpudef field is too low; CPU core topology information > >is provided on CPUID leaf 4, and most of the Intel CPU models on Qemu > >have level=2 today (I don't know why). So, Qemu is responsible for > >exposing CPU topology information set using '-smp' to the guest OS, but > >libvirt would have to be responsible for choosing a proper "level" value > >that makes that information visible to the guest. We can _allow_ libvirt > >to fiddle with these low-level bits, of course, but requiring every > >management layer to build this low-level information from scratch is > >just a recipe to waste developer time. > > > >(And I really hope that there's no plan to require all those low-level > >bits to appear as-is on the libvirt XML definitions. Because that would > >require users to read the Intel 64 and IA-32 Architectures Software > >Developer's Manual, or the AMD64 Architecture Programmer's Manual and > >BIOS and Kernel Developer's Guides, just to understand why something is > >not working on his Virtual Machine.) > > > >[1] https://bugzilla.redhat.com/show_bug.cgi?id=689665 > > -- Gleb. From gleb at redhat.com Sun Mar 11 14:56:55 2012 From: gleb at redhat.com (Gleb Natapov) Date: Sun, 11 Mar 2012 16:56:55 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5CB2EA.10000@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> Message-ID: <20120311145655.GK17882@redhat.com> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > >>Let's step back here. > >> > >>Why are you writing these patches? It's probably not because you > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > >>I'd wager to say that no human has ever done that or that if they > >>had, they did so by accident because they read documentation and > >>thought they had to. > >> > >I'd be glad if QEMU will chose -cpu Westmere for me if it detects > >Westmere host CPU as a default. > > This is -cpu best that Alex proposed FWIW. > I didn't look at exact implementation but I doubt it does exactly what we need because currently we do not have infrastructure for that. If qemu is upgraded with support for new cpuid bits and -cpu best will pass them to a guest on next boot then this is not the same. -cpu Westmere can mean different thing for different machine types with proper infrastructure in place. > >>Humans probably do one of two things: 1) no cpu option or 2) -cpu host. > >> > >And both are not optimal. Actually both are bad. First one because > >default cpu is very conservative and the second because there is no > >guaranty that guest will continue to work after qemu or kernel upgrade. > > > >Let me elaborate about the later. Suppose host CPU has kill_guest > >feature and at the time a guest was installed it was not implemented by > >kvm. Since it was not implemented by kvm it was not present in vcpu > >during installation and the guest didn't install "workaround kill_guest" > >module. Now unsuspecting user upgrades the kernel and tries to restart > >the guest and fails. He writes angry letter to qemu-devel and is asked to > >reinstall his guest and move along. > > -cpu best wouldn't solve this. You need a read/write configuration > file where QEMU probes the available CPU and records it to be used > for the lifetime of the VM. That what I thought too, but this shouldn't be the case (Avi's idea). We need two things: 1) CPU model config should be per machine type. 2) QEMU should refuse to start if it cannot create cpu exactly as specified by model config. With two conditions above if user creates VM with qemu 1.0 and cpu model Westmere which has no kill_guest feature he will still be able to run it in QEMU 1.1 (where kill_guest is added to Westmere model) and new kvm that support kill_guest by providing -M pc-1.0 flag (old definition of Westmere will be used). If user will try to create VM with QEMU 1.1 on a kernel that does not support kill_guest QEMU will refuse to start. > > >>So then why are you introducing -cpu Westmere? Because ovirt-engine > >>has a concept of datacenters and the entire datacenter has to use a > >>compatible CPU model to allow migration compatibility. Today, the > >>interface that ovirt-engine exposes is based on CPU codenames. > >>Presumably ovirt-engine wants to add a Westmere CPU group and as > >>such have levied a requirement down the stack to QEMU. > >> > >First of all this is not about live migration only. Guest visible vcpu > >should not change after guest reboot (or hibernate/resume) too. And > >second this concept exists with only your laptop and single guest on it > >too. There are three inputs into a "CPU model module": 1) host cpu, 2) > >qemu capabilities, 3) kvm capabilities. With datacenters scenario all > >three can change, with your laptop only last two can change (first one > >can change too when you'll get new laptop) , but the net result is that > >guest visible cpuid can change and it shouldn't. This is the goal of > >introducing -cpu Westmere, to prevent it from happening. > > This discussion isn't about whether QEMU should have a Westmere > processor definition. In fact, I think I already applied that > patch. > > It's a discussion about how we handle this up and down the stack. > > The question is who should define and manage CPU compatibility. > Right now QEMU does to a certain degree, libvirt discards this and > does it's own thing, and VDSM/ovirt-engine assume that we're > providing something and has built a UI around it. If we want QEMU to be usable without management layer then QEMU should provide stable CPU models. Stable in a sense that qemu, kernel or CPU upgrade does not change what guest sees. If libvirt wants to override QEMU we should have a way to allow that, but than compatibility becomes libvirt problem. Figuring out what minimal CPU model that can be used across a cluster of different machines should be ovirt task. > > What I'm proposing we consider: have VDSM manage CPU definitions in > order to provide a specific user experience in ovirt-engine. > > We would continue to have Westmere/etc in QEMU exposed as part of > the user configuration. But I don't think it makes a lot of sense > to have to modify QEMU any time a new CPU comes out. > If new cpu does not provide any new instruction set or capability that can be passed to a guest then there is no point creating CPU model for it in QEMU. If it does it is just a matter of updating config file. New CPUs are not something that pops up twice a month. -- Gleb. From gleb at redhat.com Sun Mar 11 16:16:25 2012 From: gleb at redhat.com (Gleb Natapov) Date: Sun, 11 Mar 2012 18:16:25 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5CC5BB.3070000@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> Message-ID: <20120311161625.GN17882@redhat.com> On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: > On 03/11/2012 09:56 AM, Gleb Natapov wrote: > >On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > >>-cpu best wouldn't solve this. You need a read/write configuration > >>file where QEMU probes the available CPU and records it to be used > >>for the lifetime of the VM. > >That what I thought too, but this shouldn't be the case (Avi's idea). > >We need two things: 1) CPU model config should be per machine type. > >2) QEMU should refuse to start if it cannot create cpu exactly as > >specified by model config. > > This would either mean: > > A. pc-1.1 uses -cpu best with a fixed mask for 1.1 > > B. pc-1.1 hardcodes Westmere or some other family > This would mean neither A nor B. May be it wasn't clear but I didn't talk about -cpu best above. I am talking about any CPU model with fixed meaning (not host or best which are host cpu dependant). Lets take Nehalem for example (just to move from Westmere :)). Currently it has level=2. Eduardo wants to fix it to be 11, but old guests, installed with -cpu Nehalem, should see the same CPU exactly. How do you do it? Have different Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). Lets get back to Westmere. It actually has level=11, but that's only expose another problem. Kernel 3.3 and qemu-1.1 combo will support architectural PMU which is exposed in cpuid leaf 10. We do not want guests installed with -cpu Westmere and qemu-1.0 to see architectural PMU after upgrade. How do you do it? Have different Westmere definitions for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without PMU support)? Qemu will fail to start. > (A) would imply a different CPU if you moved the machine from one > system to another. I would think this would be very problematic > from a user's perspective. > > (B) would imply that we had to choose the least common denominator > which is essentially what we do today with qemu64. If you want to > just switch qemu64 to Conroe, I don't think that's a huge difference > from what we have today. > > >>It's a discussion about how we handle this up and down the stack. > >> > >>The question is who should define and manage CPU compatibility. > >>Right now QEMU does to a certain degree, libvirt discards this and > >>does it's own thing, and VDSM/ovirt-engine assume that we're > >>providing something and has built a UI around it. > >If we want QEMU to be usable without management layer then QEMU should > >provide stable CPU models. Stable in a sense that qemu, kernel or CPU > >upgrade does not change what guest sees. > > We do this today by exposing -cpu qemu64 by default. If all you're > advocating is doing -cpu Conroe by default, that's fine. I am not advocating that. I am saying we should be able to amend qemu64 definition without breaking older guests that use it. > > But I fail to see where this fits into the larger discussion here. > The problem to solve is: I want to use the largest possible subset > of CPU features available uniformly throughout my datacenter. > > QEMU and libvirt have single node views so they cannot solve this > problem on their own. Whether that subset is a generic > Westmere-like processor that never existed IRL or a specific > Westmere processor seems like a decision that should be made by the > datacenter level manager with the node level view. > > If I have a homogeneous environments of Xeon 7540, I would probably > like to see a Xeon 7540 in my guest. Doesn't it make sense to > enable the management tool to make this decision? > Of course neither QEMU nor libvirt can't made a cluster wide decision. If QEMU provides sane CPU model definitions (usable even with -nodefconfig) it would be always possible to find the model that fits best. If the oldest CPU in data center is Nehalem then probably -cpu Nehalem will do. But our CPU model definitions have a lot of shortcomings and we were talking with Edurado how to fix them when he brought this thread back to life, so may be I stirred the discussion a little bit in the wrong direction, but I do think those things are connected. If QEMU CPU model definitions are not stable across upgrades how can we say to management that it is safe to use them? Instead they insist in reimplementing the same logic in mngmt layer and do it badly (because the lack of info). -- Gleb. From ehabkost at redhat.com Mon Mar 12 12:52:27 2012 From: ehabkost at redhat.com (Eduardo Habkost) Date: Mon, 12 Mar 2012 09:52:27 -0300 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5CB2EA.10000@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> Message-ID: <20120312125227.GA20654@otherpad.lan.raisama.net> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > >>Let's step back here. > >> > >>Why are you writing these patches? It's probably not because you > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > >>I'd wager to say that no human has ever done that or that if they > >>had, they did so by accident because they read documentation and > >>thought they had to. No, it's because libvirt doesn't handle all the tiny small details involved in specifying a CPU. All libvirty knows about are a set of CPU flag bits, but it knows nothing about 'level', 'family', and 'xlevel', but we would like to allow it to expose a Westmere-like CPU to the guest. libvirt does know how to use the Westmere CPU model today, if it is not disabled by -nodefconfig. The interface it uses for probing has deficiencies, but it works right now. > >>Humans probably do one of two things: 1) no cpu option or 2) -cpu host. > >> > >And both are not optimal. Actually both are bad. First one because > >default cpu is very conservative and the second because there is no > >guaranty that guest will continue to work after qemu or kernel upgrade. > > > >Let me elaborate about the later. Suppose host CPU has kill_guest > >feature and at the time a guest was installed it was not implemented by > >kvm. Since it was not implemented by kvm it was not present in vcpu > >during installation and the guest didn't install "workaround kill_guest" > >module. Now unsuspecting user upgrades the kernel and tries to restart > >the guest and fails. He writes angry letter to qemu-devel and is asked to > >reinstall his guest and move along. > > -cpu best wouldn't solve this. You need a read/write configuration > file where QEMU probes the available CPU and records it to be used > for the lifetime of the VM. If the CPU records are used for probing, this is yet another reason they are not "configuration", but "defaults/templates to be used to build the actual configuration". IMHO, having to generate an opaque config file based on the results of probing is poor interface design, for humans _and_ for machines. If we have any bug on the probing, or on the data used as base for the probing, or on the config generation, it will be impossible to deploy a fix for the users. This is why machine-types exist: you have the ability to implement probing and/or sane defaults, but at the same time you can change the probing behavior or the set of defaults without breaking existing machines. This way, the config file contains only what the user really wanted to configure, not some complex and opaque result of a probing process. Tthe fact that we have a _set_ of CPU definitions to choose from (or to use as input for probing) instead of a single default "CPU" definition that the user can change is a sign that that the cpudefs are _not_ user configuration, but just templates/defaults. [...] > This discussion isn't about whether QEMU should have a Westmere > processor definition. In fact, I think I already applied that patch. > > It's a discussion about how we handle this up and down the stack. Agreed on this point. > > The question is who should define and manage CPU compatibility. > Right now QEMU does to a certain degree, libvirt discards this and > does it's own thing, and VDSM/ovirt-engine assume that we're > providing something and has built a UI around it. libvirt doesn't discard this. If it just discarded this and properly defined its own models, I wouldn't even have (re-)started this thread. (Well, maybe I would have started a similar thread arguing that we are wasting time working on equivalent known-to-work CPU model definitions on Qemu and libvirt. Today we don't waste time doing it because libvirt currently expects -nodefconfig to not disable the existing default models). > > What I'm proposing we consider: have VDSM manage CPU definitions in > order to provide a specific user experience in ovirt-engine. I don't disagree completely with that. The problem is defining what's "CPU definitions". The current cpudef semantics is simply too low level, it impacts other features that are _already_ managed by Qemu. Let me try to enumerate: - Some CPUID leafs are defined based on -smp; - Some CPUID leafs depend on kernel capabilities; - The availability of some CPUID leafs depend on some features being enabled or not, but they are simply not exposed if a proper 'level' value is set. We could have two approaches here: we can define some details of CPU definitions as "not configurable" and others as "must-be configurable", and force management layer to agree with us about what should be configurable or not. Or, we could simply define that a sane set of CPU definitions are part of a machine-type, and let managment to reconfigure parts of it if desired, but do not force it to configure it if not needed. > > We would continue to have Westmere/etc in QEMU exposed as part of the > user configuration. But I don't think it makes a lot of sense to > have to modify QEMU any time a new CPU comes out. Today we have to, because libvirt doesn't handle all the details of CPU definitions. I would be happy if libvirt took to itself the responsibility of defining all those CPUs, but that's not true today. And even if we all agree that in the future libvirt will manage every single detail of the CPU. I would still argue that CPU definition defaults (especially if they are used as input for probing) should be part of machine-type definitions, as not everybody uses libvirt. -- Eduardo From berrange at redhat.com Mon Mar 12 13:04:19 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 12 Mar 2012 13:04:19 +0000 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312125227.GA20654@otherpad.lan.raisama.net> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> Message-ID: <20120312130419.GF20867@redhat.com> On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > >>Let's step back here. > > >> > > >>Why are you writing these patches? It's probably not because you > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > >>I'd wager to say that no human has ever done that or that if they > > >>had, they did so by accident because they read documentation and > > >>thought they had to. > > No, it's because libvirt doesn't handle all the tiny small details > involved in specifying a CPU. All libvirty knows about are a set of CPU > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > but we would like to allow it to expose a Westmere-like CPU to the > guest. This is easily fixable in libvirt - so for the point of going discussion, IMHO, we can assume libvirt will support level, family, xlevel, etc. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From gleb at redhat.com Mon Mar 12 13:15:32 2012 From: gleb at redhat.com (Gleb Natapov) Date: Mon, 12 Mar 2012 15:15:32 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312130419.GF20867@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> <20120312130419.GF20867@redhat.com> Message-ID: <20120312131532.GB2304@redhat.com> On Mon, Mar 12, 2012 at 01:04:19PM +0000, Daniel P. Berrange wrote: > On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > > >>Let's step back here. > > > >> > > > >>Why are you writing these patches? It's probably not because you > > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > > >>I'd wager to say that no human has ever done that or that if they > > > >>had, they did so by accident because they read documentation and > > > >>thought they had to. > > > > No, it's because libvirt doesn't handle all the tiny small details > > involved in specifying a CPU. All libvirty knows about are a set of CPU > > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > > but we would like to allow it to expose a Westmere-like CPU to the > > guest. > > This is easily fixable in libvirt - so for the point of going discussion, > IMHO, we can assume libvirt will support level, family, xlevel, etc. > And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG is used, replicating QEMU logic? And since QEMU should be usable without libvirt the same logic should be implemented in QEMU anyway. -- Gleb. From ehabkost at redhat.com Mon Mar 12 13:32:21 2012 From: ehabkost at redhat.com (Eduardo Habkost) Date: Mon, 12 Mar 2012 10:32:21 -0300 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312131532.GB2304@redhat.com> References: <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> <20120312130419.GF20867@redhat.com> <20120312131532.GB2304@redhat.com> Message-ID: <20120312133221.GC20654@otherpad.lan.raisama.net> On Mon, Mar 12, 2012 at 03:15:32PM +0200, Gleb Natapov wrote: > On Mon, Mar 12, 2012 at 01:04:19PM +0000, Daniel P. Berrange wrote: > > On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > > > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > > > >>Let's step back here. > > > > >> > > > > >>Why are you writing these patches? It's probably not because you > > > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > > > >>I'd wager to say that no human has ever done that or that if they > > > > >>had, they did so by accident because they read documentation and > > > > >>thought they had to. > > > > > > No, it's because libvirt doesn't handle all the tiny small details > > > involved in specifying a CPU. All libvirty knows about are a set of CPU > > > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > > > but we would like to allow it to expose a Westmere-like CPU to the > > > guest. > > > > This is easily fixable in libvirt - so for the point of going discussion, > > IMHO, we can assume libvirt will support level, family, xlevel, etc. > > > And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG > is used, replicating QEMU logic? And since QEMU should be usable without > libvirt the same logic should be implemented in QEMU anyway. To implement this properly, libvirt will need a proper probing interface to know what exactly is available and can be enabled. I plan to implement that. I am have no problem in giving to libvirt the power to shoot itself in the foot. I believe libvirt developers can handle that. I have a problem with requiring every user (human or machine) to handle a weapon that can shoot their foot (that means, requiring the user to write the CPU model definition from scratch, or requiring the user to blindly copy&paste the default config file). -- Eduardo From gleb at redhat.com Mon Mar 12 13:34:20 2012 From: gleb at redhat.com (Gleb Natapov) Date: Mon, 12 Mar 2012 15:34:20 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312133221.GC20654@otherpad.lan.raisama.net> References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> <20120312130419.GF20867@redhat.com> <20120312131532.GB2304@redhat.com> <20120312133221.GC20654@otherpad.lan.raisama.net> Message-ID: <20120312133420.GD2304@redhat.com> On Mon, Mar 12, 2012 at 10:32:21AM -0300, Eduardo Habkost wrote: > On Mon, Mar 12, 2012 at 03:15:32PM +0200, Gleb Natapov wrote: > > On Mon, Mar 12, 2012 at 01:04:19PM +0000, Daniel P. Berrange wrote: > > > On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > > > > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > > > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > > > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > > > > >>Let's step back here. > > > > > >> > > > > > >>Why are you writing these patches? It's probably not because you > > > > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > > > > >>I'd wager to say that no human has ever done that or that if they > > > > > >>had, they did so by accident because they read documentation and > > > > > >>thought they had to. > > > > > > > > No, it's because libvirt doesn't handle all the tiny small details > > > > involved in specifying a CPU. All libvirty knows about are a set of CPU > > > > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > > > > but we would like to allow it to expose a Westmere-like CPU to the > > > > guest. > > > > > > This is easily fixable in libvirt - so for the point of going discussion, > > > IMHO, we can assume libvirt will support level, family, xlevel, etc. > > > > > And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG > > is used, replicating QEMU logic? And since QEMU should be usable without > > libvirt the same logic should be implemented in QEMU anyway. > > To implement this properly, libvirt will need a proper probing interface > to know what exactly is available and can be enabled. I plan to > implement that. > > I am have no problem in giving to libvirt the power to shoot itself in > the foot. I believe libvirt developers can handle that. I have a problem > with requiring every user (human or machine) to handle a weapon that can > shoot their foot (that means, requiring the user to write the CPU model > definition from scratch, or requiring the user to blindly copy&paste the > default config file). > You are dangerous person Eduardo! -- Gleb. From berrange at redhat.com Mon Mar 12 13:50:18 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 12 Mar 2012 13:50:18 +0000 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312131532.GB2304@redhat.com> References: <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> <20120312130419.GF20867@redhat.com> <20120312131532.GB2304@redhat.com> Message-ID: <20120312135018.GI20867@redhat.com> On Mon, Mar 12, 2012 at 03:15:32PM +0200, Gleb Natapov wrote: > On Mon, Mar 12, 2012 at 01:04:19PM +0000, Daniel P. Berrange wrote: > > On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > > > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > > > >>Let's step back here. > > > > >> > > > > >>Why are you writing these patches? It's probably not because you > > > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > > > >>I'd wager to say that no human has ever done that or that if they > > > > >>had, they did so by accident because they read documentation and > > > > >>thought they had to. > > > > > > No, it's because libvirt doesn't handle all the tiny small details > > > involved in specifying a CPU. All libvirty knows about are a set of CPU > > > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > > > but we would like to allow it to expose a Westmere-like CPU to the > > > guest. > > > > This is easily fixable in libvirt - so for the point of going discussion, > > IMHO, we can assume libvirt will support level, family, xlevel, etc. > > > And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG > is used, replicating QEMU logic? And since QEMU should be usable without > libvirt the same logic should be implemented in QEMU anyway. I'm not refering to that. I'm saying that any data QEMU has in its config file (/etc/qemu/target-x86_64.conf) should be represented in the libvirt CPU XML. family, model, stepping, xlevel and model_id are currently in QEMU CPU configs, but not in libvirt XML, which is something we will fix. The other issues you mention are completely independant of that. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From gleb at redhat.com Mon Mar 12 13:53:38 2012 From: gleb at redhat.com (Gleb Natapov) Date: Mon, 12 Mar 2012 15:53:38 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312135018.GI20867@redhat.com> References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> <20120312130419.GF20867@redhat.com> <20120312131532.GB2304@redhat.com> <20120312135018.GI20867@redhat.com> Message-ID: <20120312135338.GE2304@redhat.com> On Mon, Mar 12, 2012 at 01:50:18PM +0000, Daniel P. Berrange wrote: > On Mon, Mar 12, 2012 at 03:15:32PM +0200, Gleb Natapov wrote: > > On Mon, Mar 12, 2012 at 01:04:19PM +0000, Daniel P. Berrange wrote: > > > On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > > > > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > > > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > > > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > > > > >>Let's step back here. > > > > > >> > > > > > >>Why are you writing these patches? It's probably not because you > > > > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > > > > >>I'd wager to say that no human has ever done that or that if they > > > > > >>had, they did so by accident because they read documentation and > > > > > >>thought they had to. > > > > > > > > No, it's because libvirt doesn't handle all the tiny small details > > > > involved in specifying a CPU. All libvirty knows about are a set of CPU > > > > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > > > > but we would like to allow it to expose a Westmere-like CPU to the > > > > guest. > > > > > > This is easily fixable in libvirt - so for the point of going discussion, > > > IMHO, we can assume libvirt will support level, family, xlevel, etc. > > > > > And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG > > is used, replicating QEMU logic? And since QEMU should be usable without > > libvirt the same logic should be implemented in QEMU anyway. > > I'm not refering to that. I'm saying that any data QEMU has in its > config file (/etc/qemu/target-x86_64.conf) should be represented > in the libvirt CPU XML. family, model, stepping, xlevel and > model_id are currently in QEMU CPU configs, but not in libvirt XML, > which is something we will fix. The other issues you mention are > completely independant of that. > Eduardo is going to extend what can be configured in /etc/qemu/target-x86_64.conf and make CPU models name per machine type. What QEMU has now is not good enough. I doubt libvirt goal is to be as bad as QEMU :) -- Gleb. From berrange at redhat.com Mon Mar 12 13:55:34 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 12 Mar 2012 13:55:34 +0000 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312135338.GE2304@redhat.com> References: <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> <20120312130419.GF20867@redhat.com> <20120312131532.GB2304@redhat.com> <20120312135018.GI20867@redhat.com> <20120312135338.GE2304@redhat.com> Message-ID: <20120312135533.GJ20867@redhat.com> On Mon, Mar 12, 2012 at 03:53:38PM +0200, Gleb Natapov wrote: > On Mon, Mar 12, 2012 at 01:50:18PM +0000, Daniel P. Berrange wrote: > > On Mon, Mar 12, 2012 at 03:15:32PM +0200, Gleb Natapov wrote: > > > On Mon, Mar 12, 2012 at 01:04:19PM +0000, Daniel P. Berrange wrote: > > > > On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > > > > > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > > > > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > > > > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > > > > > >>Let's step back here. > > > > > > >> > > > > > > >>Why are you writing these patches? It's probably not because you > > > > > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > > > > > >>I'd wager to say that no human has ever done that or that if they > > > > > > >>had, they did so by accident because they read documentation and > > > > > > >>thought they had to. > > > > > > > > > > No, it's because libvirt doesn't handle all the tiny small details > > > > > involved in specifying a CPU. All libvirty knows about are a set of CPU > > > > > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > > > > > but we would like to allow it to expose a Westmere-like CPU to the > > > > > guest. > > > > > > > > This is easily fixable in libvirt - so for the point of going discussion, > > > > IMHO, we can assume libvirt will support level, family, xlevel, etc. > > > > > > > And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG > > > is used, replicating QEMU logic? And since QEMU should be usable without > > > libvirt the same logic should be implemented in QEMU anyway. > > > > I'm not refering to that. I'm saying that any data QEMU has in its > > config file (/etc/qemu/target-x86_64.conf) should be represented > > in the libvirt CPU XML. family, model, stepping, xlevel and > > model_id are currently in QEMU CPU configs, but not in libvirt XML, > > which is something we will fix. The other issues you mention are > > completely independant of that. > > > Eduardo is going to extend what can be configured in /etc/qemu/target-x86_64.conf > and make CPU models name per machine type. What QEMU has now is not > good enough. I doubt libvirt goal is to be as bad as QEMU :) Of course not - libvirt will obviously be extended to cope with this too Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From gleb at redhat.com Mon Mar 12 14:01:02 2012 From: gleb at redhat.com (Gleb Natapov) Date: Mon, 12 Mar 2012 16:01:02 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312135533.GJ20867@redhat.com> References: <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120312125227.GA20654@otherpad.lan.raisama.net> <20120312130419.GF20867@redhat.com> <20120312131532.GB2304@redhat.com> <20120312135018.GI20867@redhat.com> <20120312135338.GE2304@redhat.com> <20120312135533.GJ20867@redhat.com> Message-ID: <20120312140102.GF2304@redhat.com> On Mon, Mar 12, 2012 at 01:55:34PM +0000, Daniel P. Berrange wrote: > On Mon, Mar 12, 2012 at 03:53:38PM +0200, Gleb Natapov wrote: > > On Mon, Mar 12, 2012 at 01:50:18PM +0000, Daniel P. Berrange wrote: > > > On Mon, Mar 12, 2012 at 03:15:32PM +0200, Gleb Natapov wrote: > > > > On Mon, Mar 12, 2012 at 01:04:19PM +0000, Daniel P. Berrange wrote: > > > > > On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote: > > > > > > On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > > > > > > > On 03/11/2012 08:27 AM, Gleb Natapov wrote: > > > > > > > >On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: > > > > > > > >>Let's step back here. > > > > > > > >> > > > > > > > >>Why are you writing these patches? It's probably not because you > > > > > > > >>have a desire to say -cpu Westmere when you run QEMU on your laptop. > > > > > > > >>I'd wager to say that no human has ever done that or that if they > > > > > > > >>had, they did so by accident because they read documentation and > > > > > > > >>thought they had to. > > > > > > > > > > > > No, it's because libvirt doesn't handle all the tiny small details > > > > > > involved in specifying a CPU. All libvirty knows about are a set of CPU > > > > > > flag bits, but it knows nothing about 'level', 'family', and 'xlevel', > > > > > > but we would like to allow it to expose a Westmere-like CPU to the > > > > > > guest. > > > > > > > > > > This is easily fixable in libvirt - so for the point of going discussion, > > > > > IMHO, we can assume libvirt will support level, family, xlevel, etc. > > > > > > > > > And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG > > > > is used, replicating QEMU logic? And since QEMU should be usable without > > > > libvirt the same logic should be implemented in QEMU anyway. > > > > > > I'm not refering to that. I'm saying that any data QEMU has in its > > > config file (/etc/qemu/target-x86_64.conf) should be represented > > > in the libvirt CPU XML. family, model, stepping, xlevel and > > > model_id are currently in QEMU CPU configs, but not in libvirt XML, > > > which is something we will fix. The other issues you mention are > > > completely independant of that. > > > > > Eduardo is going to extend what can be configured in /etc/qemu/target-x86_64.conf > > and make CPU models name per machine type. What QEMU has now is not > > good enough. I doubt libvirt goal is to be as bad as QEMU :) > > Of course not - libvirt will obviously be extended to cope with this > too > So you goal is to follow closely what QEMU does? Fine by me, but then QEMU design decisions in this ares should not rely on libvirt (as in "this is libvirt job"). -- Gleb. From aliguori at us.ibm.com Mon Mar 12 14:48:11 2012 From: aliguori at us.ibm.com (Anthony Liguori) Date: Mon, 12 Mar 2012 09:48:11 -0500 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120311161625.GN17882@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> Message-ID: <4F5E0CAB.1010901@us.ibm.com> On 03/11/2012 11:16 AM, Gleb Natapov wrote: > On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: >> On 03/11/2012 09:56 AM, Gleb Natapov wrote: >>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>>> -cpu best wouldn't solve this. You need a read/write configuration >>>> file where QEMU probes the available CPU and records it to be used >>>> for the lifetime of the VM. >>> That what I thought too, but this shouldn't be the case (Avi's idea). >>> We need two things: 1) CPU model config should be per machine type. >>> 2) QEMU should refuse to start if it cannot create cpu exactly as >>> specified by model config. >> >> This would either mean: >> >> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 >> >> B. pc-1.1 hardcodes Westmere or some other family >> > This would mean neither A nor B. May be it wasn't clear but I didn't talk > about -cpu best above. I am talking about any CPU model with fixed meaning > (not host or best which are host cpu dependant). Lets take Nehalem for > example (just to move from Westmere :)). Currently it has level=2. Eduardo > wants to fix it to be 11, but old guests, installed with -cpu Nehalem, > should see the same CPU exactly. How do you do it? Have different > Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). > Lets get back to Westmere. It actually has level=11, but that's only > expose another problem. Kernel 3.3 and qemu-1.1 combo will support > architectural PMU which is exposed in cpuid leaf 10. We do not want > guests installed with -cpu Westmere and qemu-1.0 to see architectural > PMU after upgrade. How do you do it? Have different Westmere definitions > for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens > if you'll try to run qemu-1.1 -cpu Westmere on Kernel< 3.3 (without > PMU support)? Qemu will fail to start. So, you're essentially proposing that -cpu Westmere becomes a machine option and that we let the machines interpret it as they see fit? So --machine pc-1.0,cpu=Westmere would result in something different than --machine pc-1.1,cpu=Westmere? That's something pretty different than what we're doing today. I think that we would have a single CPUX86 object and that part of the pc initialization process was to create an appropriately configured CPUx86 object. Regards, Anthony Liguori From ehabkost at redhat.com Mon Mar 12 15:16:37 2012 From: ehabkost at redhat.com (Eduardo Habkost) Date: Mon, 12 Mar 2012 12:16:37 -0300 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E0CAB.1010901@us.ibm.com> References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E0CAB.1010901@us.ibm.com> Message-ID: <20120312151637.GC6807@otherpad.lan.raisama.net> On Mon, Mar 12, 2012 at 09:48:11AM -0500, Anthony Liguori wrote: > On 03/11/2012 11:16 AM, Gleb Natapov wrote: > >On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: > >>On 03/11/2012 09:56 AM, Gleb Natapov wrote: > >>>On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > >>>>-cpu best wouldn't solve this. You need a read/write configuration > >>>>file where QEMU probes the available CPU and records it to be used > >>>>for the lifetime of the VM. > >>>That what I thought too, but this shouldn't be the case (Avi's idea). > >>>We need two things: 1) CPU model config should be per machine type. > >>>2) QEMU should refuse to start if it cannot create cpu exactly as > >>>specified by model config. > >> > >>This would either mean: > >> > >>A. pc-1.1 uses -cpu best with a fixed mask for 1.1 > >> > >>B. pc-1.1 hardcodes Westmere or some other family > >> > >This would mean neither A nor B. May be it wasn't clear but I didn't talk > >about -cpu best above. I am talking about any CPU model with fixed meaning > >(not host or best which are host cpu dependant). Lets take Nehalem for > >example (just to move from Westmere :)). Currently it has level=2. Eduardo > >wants to fix it to be 11, but old guests, installed with -cpu Nehalem, > >should see the same CPU exactly. How do you do it? Have different > >Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). > >Lets get back to Westmere. It actually has level=11, but that's only > >expose another problem. Kernel 3.3 and qemu-1.1 combo will support > >architectural PMU which is exposed in cpuid leaf 10. We do not want > >guests installed with -cpu Westmere and qemu-1.0 to see architectural > >PMU after upgrade. How do you do it? Have different Westmere definitions > >for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens > >if you'll try to run qemu-1.1 -cpu Westmere on Kernel< 3.3 (without > >PMU support)? Qemu will fail to start. > > So, you're essentially proposing that -cpu Westmere becomes a machine > option and that we let the machines interpret it as they see fit? > > So --machine pc-1.0,cpu=Westmere would result in something different > than --machine pc-1.1,cpu=Westmere? Exactly. > That's something pretty different than what we're doing today. I > think that we would have a single CPUX86 object and that part of the > pc initialization process was to create an appropriately configured > CPUx86 object. Yes, that's different from what we're doing today, and it has to be fixed. (And, BTW, I'm really worried about your proposal that machine-types would suddenly disappear when using -nodefconfig in case we decide to move machine-type data to an external file one day. Design decisions aside, this would break an interface that management tools already have today.) -- Eduardo From afaerber at suse.de Mon Mar 12 15:49:47 2012 From: afaerber at suse.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Mon, 12 Mar 2012 16:49:47 +0100 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120311161625.GN17882@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> Message-ID: <4F5E1B1B.1040606@suse.de> Am 11.03.2012 17:16, schrieb Gleb Natapov: > On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: >> On 03/11/2012 09:56 AM, Gleb Natapov wrote: >>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>>> -cpu best wouldn't solve this. You need a read/write configuration >>>> file where QEMU probes the available CPU and records it to be used >>>> for the lifetime of the VM. >>> That what I thought too, but this shouldn't be the case (Avi's idea). >>> We need two things: 1) CPU model config should be per machine type. >>> 2) QEMU should refuse to start if it cannot create cpu exactly as >>> specified by model config. >> >> This would either mean: >> >> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 >> >> B. pc-1.1 hardcodes Westmere or some other family >> > This would mean neither A nor B. May be it wasn't clear but I didn't talk > about -cpu best above. I am talking about any CPU model with fixed meaning > (not host or best which are host cpu dependant). Lets take Nehalem for > example (just to move from Westmere :)). Currently it has level=2. Eduardo > wants to fix it to be 11, but old guests, installed with -cpu Nehalem, > should see the same CPU exactly. How do you do it? Have different > Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). > Lets get back to Westmere. It actually has level=11, but that's only > expose another problem. Kernel 3.3 and qemu-1.1 combo will support > architectural PMU which is exposed in cpuid leaf 10. We do not want > guests installed with -cpu Westmere and qemu-1.0 to see architectural > PMU after upgrade. How do you do it? Have different Westmere definitions > for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens > if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without > PMU support)? Qemu will fail to start. This sounds pretty much like what Liu Jinsong and Jan are discussing in the TSC thread on qemu-devel. (cc'ing) IMO interpreting an explicit -cpu parameter depending on -M would be wrong. Changing the default CPU based on -M is fine with me. For an explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the user gets what the user asks for, without unexpected magic. Note that on my qom-cpu-wip branch [1] (that I hope to have cleaned up and sent out by tomorrow), all built-in CPUs become statically registered QOM types. The external definitions that get passed in via -cpudef become dynamically registered QOM types; I took care to allow overriding existing classes with the specified -cpudef fields (but untested). Setting family, level, etc. for -cpu is done on the X86CPU object instance. [2] What I don't have yet are QOM properties to set the fields from, e.g., machine code, but those should be fairly easy to add. Andreas [1] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-wip [2] http://repo.or.cz/w/qemu/afaerber.git/commit/8a6ede101a2722b790489989f21cad38d3e41fb5 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg From ehabkost at redhat.com Mon Mar 12 16:50:14 2012 From: ehabkost at redhat.com (Eduardo Habkost) Date: Mon, 12 Mar 2012 13:50:14 -0300 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E1B1B.1040606@suse.de> References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> Message-ID: <20120312165014.GA25451@otherpad.lan.raisama.net> On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas F?rber wrote: > Am 11.03.2012 17:16, schrieb Gleb Natapov: > > On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: > >> On 03/11/2012 09:56 AM, Gleb Natapov wrote: > >>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > >>>> -cpu best wouldn't solve this. You need a read/write configuration > >>>> file where QEMU probes the available CPU and records it to be used > >>>> for the lifetime of the VM. > >>> That what I thought too, but this shouldn't be the case (Avi's idea). > >>> We need two things: 1) CPU model config should be per machine type. > >>> 2) QEMU should refuse to start if it cannot create cpu exactly as > >>> specified by model config. > >> > >> This would either mean: > >> > >> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 > >> > >> B. pc-1.1 hardcodes Westmere or some other family > >> > > This would mean neither A nor B. May be it wasn't clear but I didn't talk > > about -cpu best above. I am talking about any CPU model with fixed meaning > > (not host or best which are host cpu dependant). Lets take Nehalem for > > example (just to move from Westmere :)). Currently it has level=2. Eduardo > > wants to fix it to be 11, but old guests, installed with -cpu Nehalem, > > should see the same CPU exactly. How do you do it? Have different > > Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). > > Lets get back to Westmere. It actually has level=11, but that's only > > expose another problem. Kernel 3.3 and qemu-1.1 combo will support > > architectural PMU which is exposed in cpuid leaf 10. We do not want > > guests installed with -cpu Westmere and qemu-1.0 to see architectural > > PMU after upgrade. How do you do it? Have different Westmere definitions > > for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens > > if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without > > PMU support)? Qemu will fail to start. > > This sounds pretty much like what Liu Jinsong and Jan are discussing in > the TSC thread on qemu-devel. (cc'ing) I'll look for that thread. Thanks! > > IMO interpreting an explicit -cpu parameter depending on -M would be > wrong. Changing the default CPU based on -M is fine with me. For an > explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the > user gets what the user asks for, without unexpected magic. It is not unexpected magic. It would be a documented mechanism: "-cpu Nehalem-1.0" and "-cpu Nehalem-1.1" would have the same meaning every time, with any machine-type, but "-cpu Nehalem" would be an alias, whose meaning depends on the machine-type. Otherwise we would be stuck with a broken "Nehalem" model forever, and we don't want that. > Note that on my qom-cpu-wip branch [1] (that I hope to have cleaned up > and sent out by tomorrow), all built-in CPUs become statically > registered QOM types. The external definitions that get passed in via > -cpudef become dynamically registered QOM types; I took care to allow > overriding existing classes with the specified -cpudef fields (but > untested). Setting family, level, etc. for -cpu is done on the X86CPU > object instance. [2] > What I don't have yet are QOM properties to set the fields from, e.g., > machine code, but those should be fairly easy to add. Sounds interesting. I will have to take a look at the code to understand how it affects what's being discussed in this thread. > > Andreas > > [1] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-wip > > [2] > http://repo.or.cz/w/qemu/afaerber.git/commit/8a6ede101a2722b790489989f21cad38d3e41fb5 > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg -- Eduardo From afaerber at suse.de Mon Mar 12 17:41:06 2012 From: afaerber at suse.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Mon, 12 Mar 2012 18:41:06 +0100 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312165014.GA25451@otherpad.lan.raisama.net> References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> Message-ID: <4F5E3532.4060003@suse.de> Am 12.03.2012 17:50, schrieb Eduardo Habkost: > On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas F?rber wrote: >> Am 11.03.2012 17:16, schrieb Gleb Natapov: >>> On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: >>>> On 03/11/2012 09:56 AM, Gleb Natapov wrote: >>>>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>>>>> -cpu best wouldn't solve this. You need a read/write configuration >>>>>> file where QEMU probes the available CPU and records it to be used >>>>>> for the lifetime of the VM. >>>>> That what I thought too, but this shouldn't be the case (Avi's idea). >>>>> We need two things: 1) CPU model config should be per machine type. >>>>> 2) QEMU should refuse to start if it cannot create cpu exactly as >>>>> specified by model config. >>>> >>>> This would either mean: >>>> >>>> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 >>>> >>>> B. pc-1.1 hardcodes Westmere or some other family >>>> >>> This would mean neither A nor B. May be it wasn't clear but I didn't talk >>> about -cpu best above. I am talking about any CPU model with fixed meaning >>> (not host or best which are host cpu dependant). Lets take Nehalem for >>> example (just to move from Westmere :)). Currently it has level=2. Eduardo >>> wants to fix it to be 11, but old guests, installed with -cpu Nehalem, >>> should see the same CPU exactly. How do you do it? Have different >>> Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). >>> Lets get back to Westmere. It actually has level=11, but that's only >>> expose another problem. Kernel 3.3 and qemu-1.1 combo will support >>> architectural PMU which is exposed in cpuid leaf 10. We do not want >>> guests installed with -cpu Westmere and qemu-1.0 to see architectural >>> PMU after upgrade. How do you do it? Have different Westmere definitions >>> for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens >>> if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without >>> PMU support)? Qemu will fail to start. [...] >> IMO interpreting an explicit -cpu parameter depending on -M would be >> wrong. Changing the default CPU based on -M is fine with me. For an >> explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the >> user gets what the user asks for, without unexpected magic. > > It is not unexpected magic. It would be a documented mechanism: > "-cpu Nehalem-1.0" and "-cpu Nehalem-1.1" would have the same meaning > every time, with any machine-type, but "-cpu Nehalem" would be an alias, > whose meaning depends on the machine-type. > > Otherwise we would be stuck with a broken "Nehalem" model forever, and > we don't want that. Not quite what I meant: In light of QOM we should be able to instantiate a CPU based on its name and optional parameters IMO. No dependency on the machine, please. An alias sure, but if the user explicitly says -cpu Nehalem then on 1.1 it should always be an alias to Nehalem-1.1 whether the machine is -M pc-0.15 or pc. If no -cpu was specified by the user, then choosing a default of Nehalem-1.0 for pc-1.0 is fine. Just trying to keep separate things separate here. Also keep in mind linux-user. There's no concept of a machine there, but there's a cpu_copy() function used for forking that tries to re-create the CPU based on its model. So currently cpu_*_init(env->cpu_model_str) needs to be able to recreate an identical CPU through the central code path, without access to a QEMUMachine. (I'd really like to fix this "reentrancy" but we can't just trivially memcpy().) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg From peter.maydell at linaro.org Mon Mar 12 17:47:31 2012 From: peter.maydell at linaro.org (Peter Maydell) Date: Mon, 12 Mar 2012 17:47:31 +0000 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E3532.4060003@suse.de> References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> Message-ID: On 12 March 2012 17:41, Andreas F?rber wrote: > Also keep in mind linux-user. There's no concept of a machine there, but > there's a cpu_copy() function used for forking that tries to re-create > the CPU based on its model. Incidentally, do you know why the linux-user code calls cpu_reset on the newly copied CPU state but only for TARGET_I386/SPARC/PPC ? That looks very odd to me... -- PMM From gleb at redhat.com Mon Mar 12 17:52:09 2012 From: gleb at redhat.com (Gleb Natapov) Date: Mon, 12 Mar 2012 19:52:09 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E3532.4060003@suse.de> References: <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> Message-ID: <20120312175209.GI12353@redhat.com> On Mon, Mar 12, 2012 at 06:41:06PM +0100, Andreas F?rber wrote: > Am 12.03.2012 17:50, schrieb Eduardo Habkost: > > On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas F?rber wrote: > >> Am 11.03.2012 17:16, schrieb Gleb Natapov: > >>> On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote: > >>>> On 03/11/2012 09:56 AM, Gleb Natapov wrote: > >>>>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: > >>>>>> -cpu best wouldn't solve this. You need a read/write configuration > >>>>>> file where QEMU probes the available CPU and records it to be used > >>>>>> for the lifetime of the VM. > >>>>> That what I thought too, but this shouldn't be the case (Avi's idea). > >>>>> We need two things: 1) CPU model config should be per machine type. > >>>>> 2) QEMU should refuse to start if it cannot create cpu exactly as > >>>>> specified by model config. > >>>> > >>>> This would either mean: > >>>> > >>>> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 > >>>> > >>>> B. pc-1.1 hardcodes Westmere or some other family > >>>> > >>> This would mean neither A nor B. May be it wasn't clear but I didn't talk > >>> about -cpu best above. I am talking about any CPU model with fixed meaning > >>> (not host or best which are host cpu dependant). Lets take Nehalem for > >>> example (just to move from Westmere :)). Currently it has level=2. Eduardo > >>> wants to fix it to be 11, but old guests, installed with -cpu Nehalem, > >>> should see the same CPU exactly. How do you do it? Have different > >>> Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11). > >>> Lets get back to Westmere. It actually has level=11, but that's only > >>> expose another problem. Kernel 3.3 and qemu-1.1 combo will support > >>> architectural PMU which is exposed in cpuid leaf 10. We do not want > >>> guests installed with -cpu Westmere and qemu-1.0 to see architectural > >>> PMU after upgrade. How do you do it? Have different Westmere definitions > >>> for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens > >>> if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without > >>> PMU support)? Qemu will fail to start. > [...] > >> IMO interpreting an explicit -cpu parameter depending on -M would be > >> wrong. Changing the default CPU based on -M is fine with me. For an > >> explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the > >> user gets what the user asks for, without unexpected magic. > > > > It is not unexpected magic. It would be a documented mechanism: > > "-cpu Nehalem-1.0" and "-cpu Nehalem-1.1" would have the same meaning > > every time, with any machine-type, but "-cpu Nehalem" would be an alias, > > whose meaning depends on the machine-type. > > > > Otherwise we would be stuck with a broken "Nehalem" model forever, and > > we don't want that. > > Not quite what I meant: In light of QOM we should be able to instantiate > a CPU based on its name and optional parameters IMO. No dependency on > the machine, please. An alias sure, but if the user explicitly says -cpu > Nehalem then on 1.1 it should always be an alias to Nehalem-1.1 whether > the machine is -M pc-0.15 or pc. If no -cpu was specified by the user, > then choosing a default of Nehalem-1.0 for pc-1.0 is fine. Just trying > to keep separate things separate here. > Those things are not separate. If user will get Nehalem-1.1 with -M pc-0.15 on qemu-1.1 it will get broken VM. If user uses -M pc-0.15 it should get exactly same machine it gets by running qemu-0.15. Guest should not be able to tell the difference. This is the reason -M exists, anything else is a bug. -- Gleb. From afaerber at suse.de Mon Mar 12 17:53:27 2012 From: afaerber at suse.de (=?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?=) Date: Mon, 12 Mar 2012 18:53:27 +0100 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> Message-ID: <4F5E3817.4010105@suse.de> Am 12.03.2012 18:47, schrieb Peter Maydell: > On 12 March 2012 17:41, Andreas F?rber wrote: >> Also keep in mind linux-user. There's no concept of a machine there, but >> there's a cpu_copy() function used for forking that tries to re-create >> the CPU based on its model. > > Incidentally, do you know why the linux-user code calls cpu_reset on > the newly copied CPU state but only for TARGET_I386/SPARC/PPC ? That > looks very odd to me... Incidentally for i386 I do: cpu_reset() is intentionally not part of cpu_init() there because afterwards the machine or something sets whether this CPU is a "bsp" (Board Support Package? ;)) and only then resets it. For ppc and sparc I don't know but I'd be surprised if it's necessary for ppc... Alex? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg From gleb at redhat.com Mon Mar 12 17:55:24 2012 From: gleb at redhat.com (Gleb Natapov) Date: Mon, 12 Mar 2012 19:55:24 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E3817.4010105@suse.de> References: <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> <4F5E3817.4010105@suse.de> Message-ID: <20120312175523.GJ12353@redhat.com> On Mon, Mar 12, 2012 at 06:53:27PM +0100, Andreas F?rber wrote: > Am 12.03.2012 18:47, schrieb Peter Maydell: > > On 12 March 2012 17:41, Andreas F?rber wrote: > >> Also keep in mind linux-user. There's no concept of a machine there, but > >> there's a cpu_copy() function used for forking that tries to re-create > >> the CPU based on its model. > > > > Incidentally, do you know why the linux-user code calls cpu_reset on > > the newly copied CPU state but only for TARGET_I386/SPARC/PPC ? That > > looks very odd to me... > > Incidentally for i386 I do: cpu_reset() is intentionally not part of > cpu_init() there because afterwards the machine or something sets > whether this CPU is a "bsp" (Board Support Package? ;)) and only then Boot Strap Processor I guess :) > resets it. > > For ppc and sparc I don't know but I'd be surprised if it's necessary > for ppc... Alex? > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg -- Gleb. From agraf at suse.de Mon Mar 12 17:59:29 2012 From: agraf at suse.de (Alexander Graf) Date: Mon, 12 Mar 2012 18:59:29 +0100 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E3817.4010105@suse.de> References: <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> <4F5E3817.4010105@suse.de> Message-ID: <2957353A-E5BE-4487-B713-37EBC4ED8A94@suse.de> On 12.03.2012, at 18:53, Andreas F?rber wrote: > Am 12.03.2012 18:47, schrieb Peter Maydell: >> On 12 March 2012 17:41, Andreas F?rber wrote: >>> Also keep in mind linux-user. There's no concept of a machine there, but >>> there's a cpu_copy() function used for forking that tries to re-create >>> the CPU based on its model. >> >> Incidentally, do you know why the linux-user code calls cpu_reset on >> the newly copied CPU state but only for TARGET_I386/SPARC/PPC ? That >> looks very odd to me... > > Incidentally for i386 I do: cpu_reset() is intentionally not part of > cpu_init() there because afterwards the machine or something sets > whether this CPU is a "bsp" (Board Support Package? ;)) and only then > resets it. > > For ppc and sparc I don't know but I'd be surprised if it's necessary > for ppc... Alex? Phew - no idea. Does git blame know more there? :) Alex From ehabkost at redhat.com Mon Mar 12 18:30:36 2012 From: ehabkost at redhat.com (Eduardo Habkost) Date: Mon, 12 Mar 2012 15:30:36 -0300 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E3532.4060003@suse.de> References: <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> Message-ID: <20120312183036.GK20654@otherpad.lan.raisama.net> On Mon, Mar 12, 2012 at 06:41:06PM +0100, Andreas F?rber wrote: > Am 12.03.2012 17:50, schrieb Eduardo Habkost: > > On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas F?rber wrote: [...] > >> IMO interpreting an explicit -cpu parameter depending on -M would be > >> wrong. Changing the default CPU based on -M is fine with me. For an > >> explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the > >> user gets what the user asks for, without unexpected magic. > > > > It is not unexpected magic. It would be a documented mechanism: > > "-cpu Nehalem-1.0" and "-cpu Nehalem-1.1" would have the same meaning > > every time, with any machine-type, but "-cpu Nehalem" would be an alias, > > whose meaning depends on the machine-type. > > > > Otherwise we would be stuck with a broken "Nehalem" model forever, and > > we don't want that. > > Not quite what I meant: In light of QOM we should be able to instantiate > a CPU based on its name and optional parameters IMO. No dependency on > the machine, please. An alias sure, but if the user explicitly says -cpu > Nehalem then on 1.1 it should always be an alias to Nehalem-1.1 whether > the machine is -M pc-0.15 or pc. If no -cpu was specified by the user, > then choosing a default of Nehalem-1.0 for pc-1.0 is fine. Just trying > to keep separate things separate here. As Gleb explained, things aren't really separated: "qemu-1.1 -M pc-1.0 -cpu Nehalem" should result in the same machine as "qemu-1.0 -cpu Nehalem", no difference should be visible to the guest. simply make incompatible changes. > > Also keep in mind linux-user. There's no concept of a machine there, but > there's a cpu_copy() function used for forking that tries to re-create > the CPU based on its model. So currently cpu_*_init(env->cpu_model_str) > needs to be able to recreate an identical CPU through the central code > path, without access to a QEMUMachine. So just translate the CPU alias given to "-cpu" to the true CPU model name as soon as possible, at the command-line-handling code, so the rest of the code always see the true CPU model name. After all, the need to make the aliases is a command-line interface compatibility problem, so it makes sense to handle this at the command-line-handling code. -- Eduardo From anthony at codemonkey.ws Mon Mar 12 18:42:09 2012 From: anthony at codemonkey.ws (Anthony Liguori) Date: Mon, 12 Mar 2012 13:42:09 -0500 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <20120312183036.GK20654@otherpad.lan.raisama.net> References: <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <20120311161625.GN17882@redhat.com> <4F5E1B1B.1040606@suse.de> <20120312165014.GA25451@otherpad.lan.raisama.net> <4F5E3532.4060003@suse.de> <20120312183036.GK20654@otherpad.lan.raisama.net> Message-ID: <4F5E4381.2010003@codemonkey.ws> On 03/12/2012 01:30 PM, Eduardo Habkost wrote: > On Mon, Mar 12, 2012 at 06:41:06PM +0100, Andreas F?rber wrote: >> Am 12.03.2012 17:50, schrieb Eduardo Habkost: >>> On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas F?rber wrote: > [...] >>>> IMO interpreting an explicit -cpu parameter depending on -M would be >>>> wrong. Changing the default CPU based on -M is fine with me. For an >>>> explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the >>>> user gets what the user asks for, without unexpected magic. >>> >>> It is not unexpected magic. It would be a documented mechanism: >>> "-cpu Nehalem-1.0" and "-cpu Nehalem-1.1" would have the same meaning >>> every time, with any machine-type, but "-cpu Nehalem" would be an alias, >>> whose meaning depends on the machine-type. >>> >>> Otherwise we would be stuck with a broken "Nehalem" model forever, and >>> we don't want that. >> >> Not quite what I meant: In light of QOM we should be able to instantiate >> a CPU based on its name and optional parameters IMO. No dependency on >> the machine, please. An alias sure, but if the user explicitly says -cpu >> Nehalem then on 1.1 it should always be an alias to Nehalem-1.1 whether >> the machine is -M pc-0.15 or pc. If no -cpu was specified by the user, >> then choosing a default of Nehalem-1.0 for pc-1.0 is fine. Just trying >> to keep separate things separate here. > > As Gleb explained, things aren't really separated: > "qemu-1.1 -M pc-1.0 -cpu Nehalem" should result in the same machine as > "qemu-1.0 -cpu Nehalem", no difference should be visible to the guest. > simply make incompatible changes. So this is easy. CPU's need to be qdev/QOM and the various cpuid settings need to be done through qdev properties. Then you can just add globals to the machine definition. No different than what we do with virtio-blk. Regards, Anthony Liguori > >> >> Also keep in mind linux-user. There's no concept of a machine there, but >> there's a cpu_copy() function used for forking that tries to re-create >> the CPU based on its model. So currently cpu_*_init(env->cpu_model_str) >> needs to be able to recreate an identical CPU through the central code >> path, without access to a QEMUMachine. > > So just translate the CPU alias given to "-cpu" to the true CPU model > name as soon as possible, at the command-line-handling code, so the rest > of the code always see the true CPU model name. > > After all, the need to make the aliases is a command-line interface > compatibility problem, so it makes sense to handle this at the > command-line-handling code. > From iheim at redhat.com Mon Mar 12 18:53:09 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 12 Mar 2012 20:53:09 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5CC5BB.3070000@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> Message-ID: <4F5E4615.8020205@redhat.com> On 03/11/2012 05:33 PM, Anthony Liguori wrote: > On 03/11/2012 09:56 AM, Gleb Natapov wrote: >> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>> -cpu best wouldn't solve this. You need a read/write configuration >>> file where QEMU probes the available CPU and records it to be used >>> for the lifetime of the VM. >> That what I thought too, but this shouldn't be the case (Avi's idea). >> We need two things: 1) CPU model config should be per machine type. >> 2) QEMU should refuse to start if it cannot create cpu exactly as >> specified by model config. > > This would either mean: > > A. pc-1.1 uses -cpu best with a fixed mask for 1.1 > > B. pc-1.1 hardcodes Westmere or some other family > > (A) would imply a different CPU if you moved the machine from one system > to another. I would think this would be very problematic from a user's > perspective. > > (B) would imply that we had to choose the least common denominator which > is essentially what we do today with qemu64. If you want to just switch > qemu64 to Conroe, I don't think that's a huge difference from what we > have today. > >>> It's a discussion about how we handle this up and down the stack. >>> >>> The question is who should define and manage CPU compatibility. >>> Right now QEMU does to a certain degree, libvirt discards this and >>> does it's own thing, and VDSM/ovirt-engine assume that we're >>> providing something and has built a UI around it. >> If we want QEMU to be usable without management layer then QEMU should >> provide stable CPU models. Stable in a sense that qemu, kernel or CPU >> upgrade does not change what guest sees. > > We do this today by exposing -cpu qemu64 by default. If all you're > advocating is doing -cpu Conroe by default, that's fine. > > But I fail to see where this fits into the larger discussion here. The > problem to solve is: I want to use the largest possible subset of CPU > features available uniformly throughout my datacenter. > > QEMU and libvirt have single node views so they cannot solve this > problem on their own. Whether that subset is a generic Westmere-like > processor that never existed IRL or a specific Westmere processor seems > like a decision that should be made by the datacenter level manager with > the node level view. > > If I have a homogeneous environments of Xeon 7540, I would probably like > to see a Xeon 7540 in my guest. Doesn't it make sense to enable the > management tool to make this decision? literally, or in capabilities? literally means you want to allow passing the cpu name to be exposed to the guest? if in capabilities, how would it differ from choosing the correct "cpu family"? it wouldn't really be identical (say, number of cores/sockets and no VT for time being) ovirt allows to set "cpu family" per cluster. assume tomorrow it could do it an even more granular way. it could also do it automatically based on subset of flags on all hosts - but would it really make sense to expose a set of capabilities which doesn't exist in the real world (which iiuc, is pretty much aligned with the cpu families?), that users understand? From anthony at codemonkey.ws Mon Mar 12 19:01:25 2012 From: anthony at codemonkey.ws (Anthony Liguori) Date: Mon, 12 Mar 2012 14:01:25 -0500 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E4615.8020205@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <4F5E4615.8020205@redhat.com> Message-ID: <4F5E4805.1060402@codemonkey.ws> On 03/12/2012 01:53 PM, Itamar Heim wrote: > On 03/11/2012 05:33 PM, Anthony Liguori wrote: >> On 03/11/2012 09:56 AM, Gleb Natapov wrote: >>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>>> -cpu best wouldn't solve this. You need a read/write configuration >>>> file where QEMU probes the available CPU and records it to be used >>>> for the lifetime of the VM. >>> That what I thought too, but this shouldn't be the case (Avi's idea). >>> We need two things: 1) CPU model config should be per machine type. >>> 2) QEMU should refuse to start if it cannot create cpu exactly as >>> specified by model config. >> >> This would either mean: >> >> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 >> >> B. pc-1.1 hardcodes Westmere or some other family >> >> (A) would imply a different CPU if you moved the machine from one system >> to another. I would think this would be very problematic from a user's >> perspective. >> >> (B) would imply that we had to choose the least common denominator which >> is essentially what we do today with qemu64. If you want to just switch >> qemu64 to Conroe, I don't think that's a huge difference from what we >> have today. >> >>>> It's a discussion about how we handle this up and down the stack. >>>> >>>> The question is who should define and manage CPU compatibility. >>>> Right now QEMU does to a certain degree, libvirt discards this and >>>> does it's own thing, and VDSM/ovirt-engine assume that we're >>>> providing something and has built a UI around it. >>> If we want QEMU to be usable without management layer then QEMU should >>> provide stable CPU models. Stable in a sense that qemu, kernel or CPU >>> upgrade does not change what guest sees. >> >> We do this today by exposing -cpu qemu64 by default. If all you're >> advocating is doing -cpu Conroe by default, that's fine. >> >> But I fail to see where this fits into the larger discussion here. The >> problem to solve is: I want to use the largest possible subset of CPU >> features available uniformly throughout my datacenter. >> >> QEMU and libvirt have single node views so they cannot solve this >> problem on their own. Whether that subset is a generic Westmere-like >> processor that never existed IRL or a specific Westmere processor seems >> like a decision that should be made by the datacenter level manager with >> the node level view. >> >> If I have a homogeneous environments of Xeon 7540, I would probably like >> to see a Xeon 7540 in my guest. Doesn't it make sense to enable the >> management tool to make this decision? > > literally, or in capabilities? > literally means you want to allow passing the cpu name to be exposed to the guest? Yes, literally. Xen exposes the host CPUID to the guest for PV. Both PHYP (IBM System P) and z/VM (IBM System Z) do the same. What does VMware expose to guests by default? > if in capabilities, how would it differ from choosing the correct "cpu family"? > it wouldn't really be identical (say, number of cores/sockets and no VT for time > being) It's a trade off. From a RAS perspective, it's helpful to have information about the host available in the guest. If you're already exposing a compatible family, exposing the actual processor seems to be worth the extra effort. > ovirt allows to set "cpu family" per cluster. assume tomorrow it could do it an > even more granular way. > it could also do it automatically based on subset of flags on all hosts - but > would it really make sense to expose a set of capabilities which doesn't exist > in the real world (which iiuc, is pretty much aligned with the cpu families?), > that users understand? No, I think the lesson we've learned in QEMU (the hard way) is that exposing a CPU that never existed will cause something to break. Often times, that something is glibc or GCC which tends to be rather epic in terms of failure. Regards, Anthony Liguori > > > From iheim at redhat.com Mon Mar 12 19:12:40 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 12 Mar 2012 21:12:40 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E4805.1060402@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <4F5E4615.8020205@redhat.com> <4F5E4805.1060402@codemonkey.ws> Message-ID: <4F5E4AA8.6020200@redhat.com> On 03/12/2012 09:01 PM, Anthony Liguori wrote: > On 03/12/2012 01:53 PM, Itamar Heim wrote: >> On 03/11/2012 05:33 PM, Anthony Liguori wrote: >>> On 03/11/2012 09:56 AM, Gleb Natapov wrote: >>>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>>>> -cpu best wouldn't solve this. You need a read/write configuration >>>>> file where QEMU probes the available CPU and records it to be used >>>>> for the lifetime of the VM. >>>> That what I thought too, but this shouldn't be the case (Avi's idea). >>>> We need two things: 1) CPU model config should be per machine type. >>>> 2) QEMU should refuse to start if it cannot create cpu exactly as >>>> specified by model config. >>> >>> This would either mean: >>> >>> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 >>> >>> B. pc-1.1 hardcodes Westmere or some other family >>> >>> (A) would imply a different CPU if you moved the machine from one system >>> to another. I would think this would be very problematic from a user's >>> perspective. >>> >>> (B) would imply that we had to choose the least common denominator which >>> is essentially what we do today with qemu64. If you want to just switch >>> qemu64 to Conroe, I don't think that's a huge difference from what we >>> have today. >>> >>>>> It's a discussion about how we handle this up and down the stack. >>>>> >>>>> The question is who should define and manage CPU compatibility. >>>>> Right now QEMU does to a certain degree, libvirt discards this and >>>>> does it's own thing, and VDSM/ovirt-engine assume that we're >>>>> providing something and has built a UI around it. >>>> If we want QEMU to be usable without management layer then QEMU should >>>> provide stable CPU models. Stable in a sense that qemu, kernel or CPU >>>> upgrade does not change what guest sees. >>> >>> We do this today by exposing -cpu qemu64 by default. If all you're >>> advocating is doing -cpu Conroe by default, that's fine. >>> >>> But I fail to see where this fits into the larger discussion here. The >>> problem to solve is: I want to use the largest possible subset of CPU >>> features available uniformly throughout my datacenter. >>> >>> QEMU and libvirt have single node views so they cannot solve this >>> problem on their own. Whether that subset is a generic Westmere-like >>> processor that never existed IRL or a specific Westmere processor seems >>> like a decision that should be made by the datacenter level manager with >>> the node level view. >>> >>> If I have a homogeneous environments of Xeon 7540, I would probably like >>> to see a Xeon 7540 in my guest. Doesn't it make sense to enable the >>> management tool to make this decision? >> >> literally, or in capabilities? >> literally means you want to allow passing the cpu name to be exposed >> to the guest? > > Yes, literally. > > Xen exposes the host CPUID to the guest for PV. Both PHYP (IBM System P) > and z/VM (IBM System Z) do the same. > > What does VMware expose to guests by default? > >> if in capabilities, how would it differ from choosing the correct "cpu >> family"? >> it wouldn't really be identical (say, number of cores/sockets and no >> VT for time >> being) > > It's a trade off. From a RAS perspective, it's helpful to have > information about the host available in the guest. > > If you're already exposing a compatible family, exposing the actual > processor seems to be worth the extra effort. only if the entire cluster is (and will be?) identical cpu. or if you don't care about live migration i guess, which could be hte case for clouds, then again, not sure a cloud provider would want to expose the physical cpu to the tenant. > >> ovirt allows to set "cpu family" per cluster. assume tomorrow it could >> do it an >> even more granular way. >> it could also do it automatically based on subset of flags on all >> hosts - but >> would it really make sense to expose a set of capabilities which >> doesn't exist >> in the real world (which iiuc, is pretty much aligned with the cpu >> families?), >> that users understand? > > No, I think the lesson we've learned in QEMU (the hard way) is that > exposing a CPU that never existed will cause something to break. Often > times, that something is glibc or GCC which tends to be rather epic in > terms of failure. good to hear - I think this is the important part. so from that perspective, cpu families sounds the right abstraction for general use case to me. for ovirt, could improve on smaller/dynamic subsets of migration domains rather than current clusters and sounds like you would want to see "expose host cpu for non migratable guests, or for identical clusters". From pmyers at redhat.com Mon Mar 12 19:39:27 2012 From: pmyers at redhat.com (Perry Myers) Date: Mon, 12 Mar 2012 15:39:27 -0400 Subject: freenode vs. oftc In-Reply-To: <4F4E50B2.3060904@redhat.com> References: <4F4E50B2.3060904@redhat.com> Message-ID: <4F5E50EF.3060708@redhat.com> On 02/29/2012 11:22 AM, Perry Myers wrote: > Now that we've gotten #ovirt at freenode unblocked and reopened... > > Thoughts on making freenode our primary channel and deprecating the oftc > #ovirt channel? > > Many of our other related projects are on freenode (vdsm for example), > and so we're sort of an outlier by being on oftc. Consolidation on a > single irc network may be desirable. > > +1 and -1's appreciated, and we'll see if there is a consensus Revisiting... IMO it does not sound like there is consensus here since there are more related projects on OFTC already than I had originally known about. I think the answer then is to just keep things exactly the way they are today. :) We'll keep the #ovirt channel on Freenode open however, if for no other reason than to redirect folks to the OFTC channel From aliguori at us.ibm.com Mon Mar 12 19:50:09 2012 From: aliguori at us.ibm.com (Anthony Liguori) Date: Mon, 12 Mar 2012 14:50:09 -0500 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E4AA8.6020200@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <4F5E4615.8020205@redhat.com> <4F5E4805.1060402@codemonkey.ws> <4F5E4AA8.6020200@redhat.com> Message-ID: <4F5E5371.1080300@us.ibm.com> On 03/12/2012 02:12 PM, Itamar Heim wrote: > On 03/12/2012 09:01 PM, Anthony Liguori wrote: >> >> It's a trade off. From a RAS perspective, it's helpful to have >> information about the host available in the guest. >> >> If you're already exposing a compatible family, exposing the actual >> processor seems to be worth the extra effort. > > only if the entire cluster is (and will be?) identical cpu. At least in my experience, this isn't unusual. > or if you don't care about live migration i guess, which could be hte case for > clouds, then again, not sure a cloud provider would want to expose the physical > cpu to the tenant. Depends on the type of cloud you're building, I guess. >>> ovirt allows to set "cpu family" per cluster. assume tomorrow it could >>> do it an >>> even more granular way. >>> it could also do it automatically based on subset of flags on all >>> hosts - but >>> would it really make sense to expose a set of capabilities which >>> doesn't exist >>> in the real world (which iiuc, is pretty much aligned with the cpu >>> families?), >>> that users understand? >> >> No, I think the lesson we've learned in QEMU (the hard way) is that >> exposing a CPU that never existed will cause something to break. Often >> times, that something is glibc or GCC which tends to be rather epic in >> terms of failure. > > good to hear - I think this is the important part. > so from that perspective, cpu families sounds the right abstraction for general > use case to me. > for ovirt, could improve on smaller/dynamic subsets of migration domains rather > than current clusters > and sounds like you would want to see "expose host cpu for non migratable > guests, or for identical clusters". Would it be possible to have a "best available" option in oVirt-engine that would assume that all processors are of the same class and fail an attempt to add something that's an older class? I think that most people probably would start with "best available" and then after adding a node fails, revisit the decision and start lowering the minimum CPU family (I'm assuming that it's possible to modify the CPU family over time). From a QEMU perspective, I think that means having per-family CPU options and then Alex's '-cpu best'. But presumably it's also necessary to be able to figure out in virsh capabilities what '-cpu best' would be. Regards, Anthony Liguori > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From iheim at redhat.com Mon Mar 12 20:00:29 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 12 Mar 2012 22:00:29 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E5371.1080300@us.ibm.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <4F5E4615.8020205@redhat.com> <4F5E4805.1060402@codemonkey.ws> <4F5E4AA8.6020200@redhat.com> <4F5E5371.1080300@us.ibm.com> Message-ID: <4F5E55DD.1030605@redhat.com> On 03/12/2012 09:50 PM, Anthony Liguori wrote: > On 03/12/2012 02:12 PM, Itamar Heim wrote: >> On 03/12/2012 09:01 PM, Anthony Liguori wrote: >>> >>> It's a trade off. From a RAS perspective, it's helpful to have >>> information about the host available in the guest. >>> >>> If you're already exposing a compatible family, exposing the actual >>> processor seems to be worth the extra effort. >> >> only if the entire cluster is (and will be?) identical cpu. > > At least in my experience, this isn't unusual. > >> or if you don't care about live migration i guess, which could be hte >> case for >> clouds, then again, not sure a cloud provider would want to expose the >> physical >> cpu to the tenant. > > Depends on the type of cloud you're building, I guess. > >>>> ovirt allows to set "cpu family" per cluster. assume tomorrow it could >>>> do it an >>>> even more granular way. >>>> it could also do it automatically based on subset of flags on all >>>> hosts - but >>>> would it really make sense to expose a set of capabilities which >>>> doesn't exist >>>> in the real world (which iiuc, is pretty much aligned with the cpu >>>> families?), >>>> that users understand? >>> >>> No, I think the lesson we've learned in QEMU (the hard way) is that >>> exposing a CPU that never existed will cause something to break. Often >>> times, that something is glibc or GCC which tends to be rather epic in >>> terms of failure. >> >> good to hear - I think this is the important part. >> so from that perspective, cpu families sounds the right abstraction >> for general >> use case to me. >> for ovirt, could improve on smaller/dynamic subsets of migration >> domains rather >> than current clusters >> and sounds like you would want to see "expose host cpu for non migratable >> guests, or for identical clusters". > > Would it be possible to have a "best available" option in oVirt-engine > that would assume that all processors are of the same class and fail an > attempt to add something that's an older class? > > I think that most people probably would start with "best available" and > then after adding a node fails, revisit the decision and start lowering > the minimum CPU family (I'm assuming that it's possible to modify the > CPU family over time). iirc, the original implementation for cpu family was start with an empty family, and use the best match from the first host added to the cluster. not sure if that's still the behavior though. worth mentioning the cpu families in ovirt have a 'sort' field to allow starting from best available. and you can change the cpu family of a cluster today as well (with some validations hosts in the cluster match up) > > From a QEMU perspective, I think that means having per-family CPU > options and then Alex's '-cpu best'. But presumably it's also necessary > to be able to figure out in virsh capabilities what '-cpu best' would be. if sticking to cpu families, updating the config with name/prioirty of the families twice a year (or by user) seems good enough to me... > > Regards, > > Anthony Liguori > >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> > From abaron at redhat.com Mon Mar 12 20:19:34 2012 From: abaron at redhat.com (Ayal Baron) Date: Mon, 12 Mar 2012 16:19:34 -0400 (EDT) Subject: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5E5371.1080300@us.ibm.com> Message-ID: ----- Original Message ----- > On 03/12/2012 02:12 PM, Itamar Heim wrote: > > On 03/12/2012 09:01 PM, Anthony Liguori wrote: > >> > >> It's a trade off. From a RAS perspective, it's helpful to have > >> information about the host available in the guest. > >> > >> If you're already exposing a compatible family, exposing the > >> actual > >> processor seems to be worth the extra effort. > > > > only if the entire cluster is (and will be?) identical cpu. > > At least in my experience, this isn't unusual. I can definitely see places choosing homogeneous hardware and upgrading every few years. Giving them max capabilities for their cluster sounds logical to me. Esp. cloud providers. > > > or if you don't care about live migration i guess, which could be > > hte case for > > clouds, then again, not sure a cloud provider would want to expose > > the physical > > cpu to the tenant. > > Depends on the type of cloud you're building, I guess. > Wouldn't this affect a simple startup of a VM with a different CPU (if motherboard changed as well cause reactivation issues in windows and fun things like that)? Even if the cloud doesn't support live migration, they don't pin VMs to a host. User could shut it down and start it up again and it might run on a different node. Your ephemeral storage would be lost, but persistent image storage could still contain os info pertinent to cpu type. Btw, I don't see why internally they would not support live migration even for when they need to put a host in maintenance etc. live storage migration could take care of the ephemeral storage if that's the issue (albeit take a million years to finish). > >>> ovirt allows to set "cpu family" per cluster. assume tomorrow it > >>> could > >>> do it an > >>> even more granular way. > >>> it could also do it automatically based on subset of flags on all > >>> hosts - but > >>> would it really make sense to expose a set of capabilities which > >>> doesn't exist > >>> in the real world (which iiuc, is pretty much aligned with the > >>> cpu > >>> families?), > >>> that users understand? > >> > >> No, I think the lesson we've learned in QEMU (the hard way) is > >> that > >> exposing a CPU that never existed will cause something to break. > >> Often > >> times, that something is glibc or GCC which tends to be rather > >> epic in > >> terms of failure. > > > > good to hear - I think this is the important part. > > so from that perspective, cpu families sounds the right abstraction > > for general > > use case to me. > > for ovirt, could improve on smaller/dynamic subsets of migration > > domains rather > > than current clusters > > and sounds like you would want to see "expose host cpu for non > > migratable > > guests, or for identical clusters". > > Would it be possible to have a "best available" option in > oVirt-engine that > would assume that all processors are of the same class and fail an > attempt to > add something that's an older class? > > I think that most people probably would start with "best available" > and then > after adding a node fails, revisit the decision and start lowering > the minimum > CPU family (I'm assuming that it's possible to modify the CPU family > over time). But then they'd already have VMs that were started with the better CPU and now it'd change under their feet? or would we start them up with the best and fail to start these VMs on the newly added hosts which have the lower cpu family/type? > > From a QEMU perspective, I think that means having per-family CPU > options and > then Alex's '-cpu best'. But presumably it's also necessary to be > able to > figure out in virsh capabilities what '-cpu best' would be. > > Regards, > > Anthony Liguori > > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > > -- > libvir-list mailing list > libvir-list at redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > From kwade at redhat.com Mon Mar 12 20:29:21 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 12 Mar 2012 13:29:21 -0700 Subject: Finalizing open workshop schedule Message-ID: <4F5E5CA1.7080001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I'd like to bring together the different discussions we've had, and settle on the final schedule for the 21 March open workshop. This is the latest suggestion that I've seen that addresses the timing and topics. (I added the times myself based on discussions I've seen.) What do you think? Are these the best final topics? Are they being given enough time, or too much time? 09:30 - 10:15 :: oVirt intro & architecture (presented by Red Hat engineers) 10:15 - 11:00 :: Engine core (presented by Red Hat engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: MOM integration (presented by IBM engineers) 12:00 - 12:45 :: API (presented by Red Hat engineers) 12:45 - 13:30 :: LUNCH 13:30 - 14:15 :: oVirt Node Arch and details of oVirt node (presented by Red Hat engineers) 14:15 - 15:00 :: VDSM (presented by Red Hat engineers) 15:00 - 15:45 :: Storage (presented by Red Hat engineers) 15:45 - 16:30 :: AFTERNOON TEA BREAK 16:30 - 17:15 :: Guest agent, history and reports (presented by Red Hat engineers) 17:15 - 17:30 :: Wrap-up and finish Thanks - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPXlyg2ZIOBq0ODEERAlqaAKDbHZXtyvcV7ojTl60OJIJVaoey+QCfbNPd VSZIlgr1ghYDgj7WmxhlwGQ= =D/JX -----END PGP SIGNATURE----- From kwade at redhat.com Mon Mar 12 23:05:18 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 12 Mar 2012 16:05:18 -0700 Subject: freenode vs. oftc In-Reply-To: <4F5E50EF.3060708@redhat.com> References: <4F4E50B2.3060904@redhat.com> <4F5E50EF.3060708@redhat.com> Message-ID: <4F5E812E.3020408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/2012 12:39 PM, Perry Myers wrote: > We'll keep the #ovirt channel on Freenode open however, if for no > other reason than to redirect folks to the OFTC channel How about this: * Keep OFTC as canonical channel. * Ask everyone to also lurk on the Freenode channel. ** By lurking we shorten the time on discussions in this other-major-IRC community. * Allow conversations to flourish on Freenode, but redirect back to OFTC channel. * See what happens over time. We can have ovirtbot on the Freenode channel, so that channel sees the activity and so forth. This also allows people to turn a discussion in to a meeting simply so they can get a log (and #info, #action, etc.) for sharing with the mailing list later. - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPXoEu2ZIOBq0ODEERAmeVAJ4+Qi7xmIu1kfHoolUtbOXKqqxvLwCg1hf+ ynH1JHmJ16ww1IrFR95fkKw= =9to/ -----END PGP SIGNATURE----- From mburns at redhat.com Tue Mar 13 00:37:32 2012 From: mburns at redhat.com (Mike Burns) Date: Mon, 12 Mar 2012 20:37:32 -0400 Subject: freenode vs. oftc In-Reply-To: <4F5E812E.3020408@redhat.com> References: <4F4E50B2.3060904@redhat.com> <4F5E50EF.3060708@redhat.com> <4F5E812E.3020408@redhat.com> Message-ID: <1331599052.14799.57.camel@beelzebub.mburnsfire.net> On Mon, 2012-03-12 at 16:05 -0700, Karsten 'quaid' Wade wrote: > On 03/12/2012 12:39 PM, Perry Myers wrote: > > > We'll keep the #ovirt channel on Freenode open however, if for no > > other reason than to redirect folks to the OFTC channel > > How about this: > > * Keep OFTC as canonical channel. > * Ask everyone to also lurk on the Freenode channel. > ** By lurking we shorten the time on discussions in this > other-major-IRC community. > * Allow conversations to flourish on Freenode, but redirect back to > OFTC channel. > * See what happens over time. > > We can have ovirtbot on the Freenode channel, so that channel sees the > activity and so forth. This also allows people to turn a discussion in > to a meeting simply so they can get a log (and #info, #action, etc.) > for sharing with the mailing list later. I think I'd much rather have a handful of people lurk in the freenode channel and point discussion questions to OFTC. I think that freenode has a much larger usage base, so keeping a channel there where we can point people to the right place is smart, but I don't know about having both channels active for discussions. IMHO, we should keep all discussions/meetings on the OFTC channel and simply redirect people from the freenode channel to OFTC. We could even have a join message on the channel that says something like "Thank you for your interest in the oVirt Project. Our primary IRC channel is #ovirt on OFTC. Please ask your questions there." Mike > > - Karsten > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From iheim at redhat.com Tue Mar 13 08:32:32 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 13 Mar 2012 10:32:32 +0200 Subject: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt In-Reply-To: References: Message-ID: <4F5F0620.6020004@redhat.com> On 03/12/2012 10:19 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> On 03/12/2012 02:12 PM, Itamar Heim wrote: >>> On 03/12/2012 09:01 PM, Anthony Liguori wrote: >>>> >>>> It's a trade off. From a RAS perspective, it's helpful to have >>>> information about the host available in the guest. >>>> >>>> If you're already exposing a compatible family, exposing the >>>> actual >>>> processor seems to be worth the extra effort. >>> >>> only if the entire cluster is (and will be?) identical cpu. >> >> At least in my experience, this isn't unusual. > > I can definitely see places choosing homogeneous hardware and upgrading every few years. > Giving them max capabilities for their cluster sounds logical to me. > Esp. cloud providers. they would get same performance as from the matching "cpu family". only difference would be if the guest known the name of the host cpu. > >> >>> or if you don't care about live migration i guess, which could be >>> hte case for >>> clouds, then again, not sure a cloud provider would want to expose >>> the physical >>> cpu to the tenant. >> >> Depends on the type of cloud you're building, I guess. >> > > Wouldn't this affect a simple startup of a VM with a different CPU (if motherboard changed as well cause reactivation issues in windows and fun things like that)? that's an interesting question, I have to assume this works though, since we didn't see issues with changing the cpu family for guests so far. From iheim at redhat.com Tue Mar 13 10:33:37 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 13 Mar 2012 12:33:37 +0200 Subject: freenode vs. oftc In-Reply-To: <1331599052.14799.57.camel@beelzebub.mburnsfire.net> References: <4F4E50B2.3060904@redhat.com> <4F5E50EF.3060708@redhat.com> <4F5E812E.3020408@redhat.com> <1331599052.14799.57.camel@beelzebub.mburnsfire.net> Message-ID: <4F5F2281.2070006@redhat.com> On 03/13/2012 02:37 AM, Mike Burns wrote: > On Mon, 2012-03-12 at 16:05 -0700, Karsten 'quaid' Wade wrote: >> On 03/12/2012 12:39 PM, Perry Myers wrote: >> >>> We'll keep the #ovirt channel on Freenode open however, if for no >>> other reason than to redirect folks to the OFTC channel >> >> How about this: >> >> * Keep OFTC as canonical channel. >> * Ask everyone to also lurk on the Freenode channel. >> ** By lurking we shorten the time on discussions in this >> other-major-IRC community. >> * Allow conversations to flourish on Freenode, but redirect back to >> OFTC channel. >> * See what happens over time. >> >> We can have ovirtbot on the Freenode channel, so that channel sees the >> activity and so forth. This also allows people to turn a discussion in >> to a meeting simply so they can get a log (and #info, #action, etc.) >> for sharing with the mailing list later. > > I think I'd much rather have a handful of people lurk in the freenode > channel and point discussion questions to OFTC. I think that freenode > has a much larger usage base, so keeping a channel there where we can > point people to the right place is smart, but I don't know about having > both channels active for discussions. > > IMHO, we should keep all discussions/meetings on the OFTC channel and > simply redirect people from the freenode channel to OFTC. We could even > have a join message on the channel that says something like "Thank you > for your interest in the oVirt Project. Our primary IRC channel is > #ovirt on OFTC. Please ask your questions there." +1 From iheim at redhat.com Tue Mar 13 10:40:44 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 13 Mar 2012 12:40:44 +0200 Subject: Finalizing open workshop schedule In-Reply-To: <4F5E5CA1.7080001@redhat.com> References: <4F5E5CA1.7080001@redhat.com> Message-ID: <4F5F242C.90803@redhat.com> On 03/12/2012 10:29 PM, Karsten 'quaid' Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So I'd like to bring together the different discussions we've had, and > settle on the final schedule for the 21 March open workshop. > > This is the latest suggestion that I've seen that addresses the timing > and topics. (I added the times myself based on discussions I've seen.) > > What do you think? > > Are these the best final topics? Are they being given enough time, or > too much time? > > 09:30 - 10:15 :: oVirt intro& architecture (presented by Red Hat > engineers) this is not enough time for this session. it needs 1.5 hours > 10:15 - 11:00 :: Engine core (presented by Red Hat engineers) > 11:00 - 11:15 :: MORNING TEA BREAK > 11:15 - 12:00 :: MOM integration (presented by IBM engineers) this looks strange to me before the VDSM session, as MOM integration is with VDSM? I'd switch the order > 12:00 - 12:45 :: API (presented by Red Hat engineers) 30 minutes would be ok here. > 12:45 - 13:30 :: LUNCH > 13:30 - 14:15 :: oVirt Node Arch and details of oVirt node (presented > by Red Hat engineers) > 14:15 - 15:00 :: VDSM (presented by Red Hat engineers) > 15:00 - 15:45 :: Storage (presented by Red Hat engineers) > 15:45 - 16:30 :: AFTERNOON TEA BREAK > 16:30 - 17:15 :: Guest agent, history and reports (presented by Red > Hat engineers) I'll cover history and reports at high level in the intro session. no need for a special session for it. same for guest agent. I miss a "getting started with" session, but i think it will be mostly relevant only if we have working network for attendees to use? > 17:15 - 17:30 :: Wrap-up and finish > From sgordon at redhat.com Tue Mar 13 16:21:01 2012 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 13 Mar 2012 12:21:01 -0400 (EDT) Subject: freenode vs. oftc In-Reply-To: <1331599052.14799.57.camel@beelzebub.mburnsfire.net> Message-ID: ----- Original Message ----- > From: "Mike Burns" > To: "Karsten 'quaid' Wade" > Cc: arch at ovirt.org > Sent: Monday, March 12, 2012 8:37:32 PM > Subject: Re: freenode vs. oftc > > On Mon, 2012-03-12 at 16:05 -0700, Karsten 'quaid' Wade wrote: > > On 03/12/2012 12:39 PM, Perry Myers wrote: > > > > > We'll keep the #ovirt channel on Freenode open however, if for no > > > other reason than to redirect folks to the OFTC channel > > > > How about this: > > > > * Keep OFTC as canonical channel. > > * Ask everyone to also lurk on the Freenode channel. > > ** By lurking we shorten the time on discussions in this > > other-major-IRC community. > > * Allow conversations to flourish on Freenode, but redirect back to > > OFTC channel. > > * See what happens over time. > > > > We can have ovirtbot on the Freenode channel, so that channel sees > > the > > activity and so forth. This also allows people to turn a discussion > > in > > to a meeting simply so they can get a log (and #info, #action, > > etc.) > > for sharing with the mailing list later. > > I think I'd much rather have a handful of people lurk in the freenode > channel and point discussion questions to OFTC. I think that > freenode > has a much larger usage base, so keeping a channel there where we can > point people to the right place is smart, but I don't know about > having > both channels active for discussions. > > IMHO, we should keep all discussions/meetings on the OFTC channel and > simply redirect people from the freenode channel to OFTC. We could > even > have a join message on the channel that says something like "Thank > you > for your interest in the oVirt Project. Our primary IRC channel is > #ovirt on OFTC. Please ask your questions there." Usually this is done by registering the channel, and setting it up to kick everyone who joins with a kick message indicating where to go/what to do. If you leave any possibility for joining/lurking you end up with two communities for active discussion which in my opinion is far worse that just happening to be on a 'less popular' network. Steve From kwade at redhat.com Tue Mar 13 17:05:56 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 13 Mar 2012 10:05:56 -0700 Subject: freenode vs. oftc In-Reply-To: References: Message-ID: <4F5F7E74.9040100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 09:21 AM, Steve Gordon wrote: > > Usually this is done by registering the channel, and setting it up > to kick everyone who joins with a kick message indicating where to > go/what to do. If you leave any possibility for joining/lurking > you end up with two communities for active discussion which in my > opinion is far worse that just happening to be on a 'less popular' > network. As it happens, this is what was done with #ovirt on Freenode. Despite the clear message, though, people have approached me wondering why they are "banned" from #ovirt. Anyway, in the process of getting permissions so we can actually control that channel, we removed the kickban. The /topic now says to go to OFTC, etc., and there is zero discussion on the Freenode channel. So the consensus of this list seems to be, "Leave things as they are," and in this case it seems to be better that the channel is populated but quiet. Let's go ahead and move discussions that start on Freenode to OFTC wherever possible. - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPX3502ZIOBq0ODEERAmJzAJwM6Vq2C8bC9h3hG9j/2riC1YzZEQCgubre yiUbzBl0FstWeBVPRL4tRe8= =nVd+ -----END PGP SIGNATURE----- From kwade at redhat.com Tue Mar 13 17:33:15 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 13 Mar 2012 10:33:15 -0700 Subject: Finalizing open workshop schedule In-Reply-To: <4F5F242C.90803@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> Message-ID: <4F5F84DB.6020701@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Based on the below feedback I updated the agenda and posted it here: http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop 09:30 - 11:00 :: oVirt intro & architecture (presented by Red Hat engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: Engine core (presented by Red Hat engineers) 12:00 - 12:30 :: API (presented by Red Hat engineers) 12:30 - 13:30 :: LUNCH 13:30 - 14:15 :: oVirt Node Arch and details of oVirt node (presented by Red Hat engineers) 14:15 - 15:00 :: VDSM (presented by Red Hat engineers) 15:00 - 15:45 :: MOM integration (presented by IBM engineers) 15:45 - 16:30 :: AFTERNOON TEA BREAK 16:30 - 17:15 :: Storage (presented by Red Hat engineers) 17:15 - 17:30 :: Wrap-up and finish On 03/13/2012 03:40 AM, Itamar Heim wrote: > On 03/12/2012 10:29 PM, Karsten 'quaid' Wade wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> So I'd like to bring together the different discussions we've >> had, and settle on the final schedule for the 21 March open >> workshop. >> >> This is the latest suggestion that I've seen that addresses the >> timing and topics. (I added the times myself based on discussions >> I've seen.) >> >> What do you think? >> >> Are these the best final topics? Are they being given enough >> time, or too much time? >> >> 09:30 - 10:15 :: oVirt intro& architecture (presented by Red >> Hat engineers) > > this is not enough time for this session. it needs 1.5 hours > >> 10:15 - 11:00 :: Engine core (presented by Red Hat engineers) > >> 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: MOM >> integration (presented by IBM engineers) > > this looks strange to me before the VDSM session, as MOM > integration is with VDSM? I'd switch the order > > >> 12:00 - 12:45 :: API (presented by Red Hat engineers) > > 30 minutes would be ok here. > >> 12:45 - 13:30 :: LUNCH 13:30 - 14:15 :: oVirt Node Arch and >> details of oVirt node (presented by Red Hat engineers) 14:15 - >> 15:00 :: VDSM (presented by Red Hat engineers) 15:00 - 15:45 :: >> Storage (presented by Red Hat engineers) 15:45 - 16:30 :: >> AFTERNOON TEA BREAK 16:30 - 17:15 :: Guest agent, history and >> reports (presented by Red Hat engineers) > > I'll cover history and reports at high level in the intro session. > no need for a special session for it. same for guest agent. > > I miss a "getting started with" session, but i think it will be > mostly relevant only if we have working network for attendees to > use? > >> 17:15 - 17:30 :: Wrap-up and finish >> - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPX4Tb2ZIOBq0ODEERAhJaAKDbVtXtyK9Egg0h4BoDwcsRtpE2SgCg2U0Y 3Z2qR5QopnpZBevH9ubP4fI= =tjk1 -----END PGP SIGNATURE----- From sgordon at redhat.com Tue Mar 13 18:20:44 2012 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 13 Mar 2012 14:20:44 -0400 (EDT) Subject: freenode vs. oftc In-Reply-To: <4F5F7E74.9040100@redhat.com> Message-ID: <6798cc69-2cd7-4142-b038-ba1f714cdf83@zmail15.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Karsten 'quaid' Wade" > To: arch at ovirt.org > Sent: Tuesday, March 13, 2012 1:05:56 PM > Subject: Re: freenode vs. oftc > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/13/2012 09:21 AM, Steve Gordon wrote: > > > > > Usually this is done by registering the channel, and setting it up > > to kick everyone who joins with a kick message indicating where to > > go/what to do. If you leave any possibility for joining/lurking > > you end up with two communities for active discussion which in my > > opinion is far worse that just happening to be on a 'less popular' > > network. > > As it happens, this is what was done with #ovirt on Freenode. > > Despite the clear message, though, people have approached me > wondering > why they are "banned" from #ovirt. Then that is the way it should have remained. Are people who ignore an explicit kick message any more likely to join in the correct place if they are permitted to join the channel and it's in the topic or they asked to? If we absolutely must have it open to allow people to join (and again, I can't see why) then set it to moderated (+m) and put a bot in there to tell people off periodically. > Anyway, in the process of getting permissions so we can actually > control that channel, we removed the kickban. The /topic now says to > go to OFTC, etc., and there is zero discussion on the Freenode > channel. > > So the consensus of this list seems to be, "Leave things as they > are," > and in this case it seems to be better that the channel is populated > but quiet. Well except, "As they are" had already been changed. > Let's go ahead and move discussions that start on Freenode to OFTC > wherever possible. That doesn't really address the concern that people will just end up having splintered discussions in both places. After all your suggestion in the previous mail was for us to join in *both* places to move people on. How is that an improvement? I know this is quickly turning into a bikeshed post, but from my point of view we have taken this from what should have been a fairly simple problem (choose a network) and found the one solution which is even worse (both). Steve From pmyers at redhat.com Tue Mar 13 18:28:26 2012 From: pmyers at redhat.com (Perry Myers) Date: Tue, 13 Mar 2012 14:28:26 -0400 Subject: Finalizing open workshop schedule In-Reply-To: <4F5F84DB.6020701@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> Message-ID: <4F5F91CA.3050303@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 01:33 PM, Karsten 'quaid' Wade wrote: > Based on the below feedback I updated the agenda and posted it > here: > > http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop > > 09:30 - 11:00 :: oVirt intro & architecture (presented by Red Hat > engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: > Engine core (presented by Red Hat engineers) 12:00 - 12:30 :: API > (presented by Red Hat engineers) 12:30 - 13:30 :: LUNCH 13:30 - > 14:15 :: oVirt Node Arch and details of oVirt node (presented by > Red Hat engineers) Right now there are no engineers from the oVirt Node team that will be in Beijing for this workshop. However, we will have a few folks from the Red Hat QE team that are primarily responsible for RHEVH/oVirt Node testing. The QE folks should be able to interface for Q&A on oVirt Node/RHEVH, and we'll see if we can get them to do a brief overview as well, but that is not yet determined. So we should keep this slot open for now and we'll see if we can get someone to give the talk on oVirt Node architecture. Thanks, Perry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9fkcoACgkQxdKLkeZeTz2pWACfR4Fu+lavU9h7dnahSkJLRit1 NMMAoIma1kU/HXOQmg3lO9Guu/BVq7gm =n3/L -----END PGP SIGNATURE----- From dfediuck at redhat.com Tue Mar 13 20:11:37 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 13 Mar 2012 22:11:37 +0200 Subject: Finalizing open workshop schedule In-Reply-To: <4F5F91CA.3050303@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> <4F5F91CA.3050303@redhat.com> Message-ID: <4F5FA9F9.4090400@redhat.com> On 13/03/12 20:28, Perry Myers wrote: > On 03/13/2012 01:33 PM, Karsten 'quaid' Wade wrote: >> Based on the below feedback I updated the agenda and posted it >> here: > >> http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop > >> 09:30 - 11:00 :: oVirt intro & architecture (presented by Red Hat >> engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: >> Engine core (presented by Red Hat engineers) 12:00 - 12:30 :: API >> (presented by Red Hat engineers) 12:30 - 13:30 :: LUNCH 13:30 - >> 14:15 :: oVirt Node Arch and details of oVirt node (presented by >> Red Hat engineers) > > Right now there are no engineers from the oVirt Node team that will be > in Beijing for this workshop. However, we will have a few folks from > the Red Hat QE team that are primarily responsible for RHEVH/oVirt > Node testing. > > The QE folks should be able to interface for Q&A on oVirt Node/RHEVH, > and we'll see if we can get them to do a brief overview as well, but > that is not yet determined. So we should keep this slot open for now > and we'll see if we can get someone to give the talk on oVirt Node > architecture. > > Thanks, > > Perry Considering Perry's mail we can go for: 09:30 - 11:00 :: oVirt intro & architecture (presented by Red Hat engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: Engine core (presented by Red Hat engineers) 12:00 - 12:45 :: VDSM (presented by Red Hat engineers) 12:45 - 13:45 :: LUNCH 13:45 - 14:15 :: API (presented by Red Hat engineers) 14:15 - 15:00 :: Storage (presented by Red Hat engineers) 15:00 - 15:45 :: MOM integration (presented by IBM engineers) 15:45 - 16:30 :: AFTERNOON TEA BREAK 16:30 - 17:15 :: *TBD* based on capabilities[1] 17:15 - 17:30 :: Wrap-up and finish [1] One of: * oVirt Node Arch and details of oVirt node (presented by Red Hat engineers)- depends on availability * Setting up the Engine core (get me started)- depends on local networking availability. Objections? From kwade at redhat.com Tue Mar 13 21:48:24 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 13 Mar 2012 14:48:24 -0700 Subject: freenode vs. oftc In-Reply-To: <6798cc69-2cd7-4142-b038-ba1f714cdf83@zmail15.collab.prod.int.phx2.redhat.com> References: <6798cc69-2cd7-4142-b038-ba1f714cdf83@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4F5FC0A8.3070101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 11:20 AM, Steve Gordon wrote: > > > ----- Original Message ----- >> From: "Karsten 'quaid' Wade" To: >> arch at ovirt.org Sent: Tuesday, March 13, 2012 1:05:56 PM Subject: >> Re: freenode vs. oftc >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 03/13/2012 09:21 AM, Steve Gordon wrote: >> >>> >>> Usually this is done by registering the channel, and setting >>> it up to kick everyone who joins with a kick message >>> indicating where to go/what to do. If you leave any possibility >>> for joining/lurking you end up with two communities for active >>> discussion which in my opinion is far worse that just >>> happening to be on a 'less popular' network. >> >> As it happens, this is what was done with #ovirt on Freenode. >> >> Despite the clear message, though, people have approached me >> wondering why they are "banned" from #ovirt. > > Then that is the way it should have remained. Are people who > ignore an explicit kick message any more likely to join in the > correct place if they are permitted to join the channel and it's in > the topic or they asked to? Here is one of the only Freenode conversations I've seen: 07:53 < Raboo> does ovirt run on centos? 07:53 < Raboo> can i run it on a server? 07:57 <@pmyers> Raboo: I'm not sure of the status of centos packaging. But oVirt does run on RHEL and Fedora, and there are other distributions being worked on. You might want to pop over to #ovirt on OFTC. This channel is just a secondary channel for oVirt, most folks are over on OFTC 08:06 < Raboo> pmyers oftc is a unknown network for me 08:06 < Raboo> first time i hear of it. 08:06 < pmyers> oftc.net 08:06 < pmyers> it's used for a lot of open source projects 08:06 < Raboo> i thought that was what freenode was for 08:06 < Raboo> :) 08:07 < pmyers> freenode isn't the only irc network, just one of many :) I show this example so we are clear that putting up the autokick+message on the Freenode channel (or just not having a Freenode channel) breaks the expectations and experience of many people, and puts up a barrier that some will not climb over. Are we obligated to help those people? If it's not hurting the project to do so, I think yes. > If we absolutely must have it open to allow people to join (and > again, I can't see why) then set it to moderated (+m) and put a bot > in there to tell people off periodically. Let me be clear with an Americanism - I don't have a dog in this fight. I say that so it's clear I'm not advocating for using Freenode, I'm just following through on some requests that arose. Discussions arose (in IRC, I think) about *returning* to Freenode. History AIUI is there was a wave of evil bots spamming channels, #ovirt folks decided enough-is-enough, and decamped to OFTC. In the process of evaluating all of this, I hunted down the former Freenode channel admins and "obtained" (a lead sap may-or-may-not have been used) credentials to manage the channel a bit. I removed the autokick because ... well, I reckon a closed channel can't answer for itself about whether it should survive or not. How do we know if it's needed without opening it for a while to see what happens? So, it's OK for a project to discuss alternatives and migrations around toolsets, as long as it's a healthy process. That's all I see this as. >> Anyway, in the process of getting permissions so we can actually >> control that channel, we removed the kickban. The /topic now >> says to go to OFTC, etc., and there is zero discussion on the >> Freenode channel. >> >> So the consensus of this list seems to be, "Leave things as they >> are," and in this case it seems to be better that the channel >> is populated but quiet. > > Well except, "As they are" had already been changed. Because the kickban etc. was removed? True, and my mistake if I jumped the mark on that, acting ahead of discussion here. I mainly did it because I was getting private messages from people who were trying to get in to the channel, etc. I figured, let them join, and see what happens. >> Let's go ahead and move discussions that start on Freenode to >> OFTC wherever possible. > > That doesn't really address the concern that people will just end > up having splintered discussions in both places. After all your > suggestion in the previous mail was for us to join in *both* > places to move people on. How is that an improvement? Open source projects survive just fine on multiple IRC channels. Usually it's by topic, but not always. So I'm not going to agree that in-and-of-itself having >1 IRC channel or even IRC network is always a bad idea. Discussions will arise on Freenode about oVirt on other channels, and those need to be sent to OFTC. I understand your argument that people would be helped along if they attempted to join #ovirt and got kicked with a message to go to the other IRC network. But all around, "discussions on Freenode should move to OFTC #ovirt, please." But we cannot dictate what people will do, although, yes, we can gently steer. It helps if we're more sure about where we are steering. > I know this is quickly turning into a bikeshed post, but from my > point of view we have taken this from what should have been a > fairly simple problem (choose a network) and found the one solution > which is even worse (both). My last post wasn't intended to say 'both', it was intended to say, 'keep OFTC and move any traffic on Freenode to OFTC'. (Call that my low-energy solution.) There were multiple questions in this discussion since there are some projects on Freenode, some on OFTC. One question was to move the canonical channel, no reason was found, and it appeared more related projects were on OFTC already. Another question is what to do with #ovirt on Freenode. So long way around, the final question above results in your proposal, "Return #ovirt on Freenode's kickban + clear message to go to OFTC", to which I add, "And request other oVirt discussions on Freenode to move to OFTC." That seems workable for the current need. If you agree to that proposal, I reckon we have your +1 and I'll remain +0 for now. - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPX8Co2ZIOBq0ODEERAnA8AKCByz/ug9GQ0L7x2/YsNL+1W42DpACdGs0V Rl1auOJPEj2CLLUs9Ms0Du8= =ztxb -----END PGP SIGNATURE----- From kwade at redhat.com Tue Mar 13 22:47:55 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 13 Mar 2012 15:47:55 -0700 Subject: Finalizing open workshop schedule In-Reply-To: <4F5FA9F9.4090400@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> <4F5F91CA.3050303@redhat.com> <4F5FA9F9.4090400@redhat.com> Message-ID: <4F5FCE9B.6040202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 01:11 PM, Doron Fediuck wrote: > * Setting up the Engine core (get me started)- depends on local > networking availability. My current understanding is to not expect network capability for the attendees. Can we create something for people to do in advance? - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPX86b2ZIOBq0ODEERAn/YAKDboMzFfCSy0b5JQmWZ95clwYSCFgCfS5dz lkxeqrjFPuUIth4V9qBWLtw= =A4Gy -----END PGP SIGNATURE----- From abaron at redhat.com Wed Mar 14 00:11:56 2012 From: abaron at redhat.com (Ayal Baron) Date: Tue, 13 Mar 2012 20:11:56 -0400 (EDT) Subject: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5F0620.6020004@redhat.com> Message-ID: ----- Original Message ----- > On 03/12/2012 10:19 PM, Ayal Baron wrote: > > > > > > ----- Original Message ----- > >> On 03/12/2012 02:12 PM, Itamar Heim wrote: > >>> On 03/12/2012 09:01 PM, Anthony Liguori wrote: > >>>> > >>>> It's a trade off. From a RAS perspective, it's helpful to have > >>>> information about the host available in the guest. > >>>> > >>>> If you're already exposing a compatible family, exposing the > >>>> actual > >>>> processor seems to be worth the extra effort. > >>> > >>> only if the entire cluster is (and will be?) identical cpu. > >> > >> At least in my experience, this isn't unusual. > > > > I can definitely see places choosing homogeneous hardware and > > upgrading every few years. > > Giving them max capabilities for their cluster sounds logical to > > me. > > Esp. cloud providers. > > they would get same performance as from the matching "cpu family". > only difference would be if the guest known the name of the host cpu. > > > > >> > >>> or if you don't care about live migration i guess, which could be > >>> hte case for > >>> clouds, then again, not sure a cloud provider would want to > >>> expose > >>> the physical > >>> cpu to the tenant. > >> > >> Depends on the type of cloud you're building, I guess. > >> > > > > Wouldn't this affect a simple startup of a VM with a different CPU > > (if motherboard changed as well cause reactivation issues in > > windows and fun things like that)? > > that's an interesting question, I have to assume this works though, > since we didn't see issues with changing the cpu family for guests so > far. > assumption... :) I'd try changing twice in a row (run VM, stop, change family, restart VM, stop, change family restart VM). From hkran at linux.vnet.ibm.com Wed Mar 14 06:12:26 2012 From: hkran at linux.vnet.ibm.com (Hui Kai Ran) Date: Wed, 14 Mar 2012 14:12:26 +0800 Subject: Finalizing open workshop schedule In-Reply-To: <4F5E5CA1.7080001@redhat.com> References: <4F5E5CA1.7080001@redhat.com> Message-ID: <4F6036CA.3050702@linux.vnet.ibm.com> On 03/13/2012 04:29 AM, Karsten 'quaid' Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So I'd like to bring together the different discussions we've had, and > settle on the final schedule for the 21 March open workshop. > > This is the latest suggestion that I've seen that addresses the timing > and topics. (I added the times myself based on discussions I've seen.) > > What do you think? > > Are these the best final topics? Are they being given enough time, or > too much time? > Since the organizer have invited some persons to give a opening welcome, Could we add about a half an hour session at the top of the agenda like this? 9:00 - 9:30 :: Opening Welcome and Introductions > 09:30 - 10:15 :: oVirt intro& architecture (presented by Red Hat > engineers) > 10:15 - 11:00 :: Engine core (presented by Red Hat engineers) > 11:00 - 11:15 :: MORNING TEA BREAK > 11:15 - 12:00 :: MOM integration (presented by IBM engineers) > 12:00 - 12:45 :: API (presented by Red Hat engineers) > 12:45 - 13:30 :: LUNCH > 13:30 - 14:15 :: oVirt Node Arch and details of oVirt node (presented > by Red Hat engineers) > 14:15 - 15:00 :: VDSM (presented by Red Hat engineers) > 15:00 - 15:45 :: Storage (presented by Red Hat engineers) > 15:45 - 16:30 :: AFTERNOON TEA BREAK > 16:30 - 17:15 :: Guest agent, history and reports (presented by Red > Hat engineers) > 17:15 - 17:30 :: Wrap-up and finish > > Thanks - Karsten > - -- > name: Karsten 'quaid' Wade, Sr. Community Architect > team: Red Hat Community Architecture& Leadership > uri: http://communityleadershipteam.org > http://TheOpenSourceWay.org > gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFPXlyg2ZIOBq0ODEERAlqaAKDbHZXtyvcV7ojTl60OJIJVaoey+QCfbNPd > VSZIlgr1ghYDgj7WmxhlwGQ= > =D/JX > -----END PGP SIGNATURE----- > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From mshao at redhat.com Wed Mar 14 07:03:07 2012 From: mshao at redhat.com (Maggie Shao) Date: Wed, 14 Mar 2012 15:03:07 +0800 Subject: Finalizing open workshop schedule In-Reply-To: <4F5F91CA.3050303@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> <4F5F91CA.3050303@redhat.com> Message-ID: <4F6042AB.7050800@redhat.com> On 03/14/2012 02:28 AM, Perry Myers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/13/2012 01:33 PM, Karsten 'quaid' Wade wrote: >> Based on the below feedback I updated the agenda and posted it >> here: >> >> http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop >> >> 09:30 - 11:00 :: oVirt intro& architecture (presented by Red Hat >> engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: >> Engine core (presented by Red Hat engineers) 12:00 - 12:30 :: API >> (presented by Red Hat engineers) 12:30 - 13:30 :: LUNCH 13:30 - >> 14:15 :: oVirt Node Arch and details of oVirt node (presented by >> Red Hat engineers) > Right now there are no engineers from the oVirt Node team that will be > in Beijing for this workshop. However, we will have a few folks from > the Red Hat QE team that are primarily responsible for RHEVH/oVirt > Node testing. > > The QE folks should be able to interface for Q&A on oVirt Node/RHEVH, > and we'll see if we can get them to do a brief overview as well, but > that is not yet determined. So we should keep this slot open for now > and we'll see if we can get someone to give the talk on oVirt Node > architecture. Our RHEVH QE - Qixiang Wan (qwan at redhat.com) can help to do the presentation. He is reviewing the slide that sent by Mike today and he will discuss with Perry/Mike for the problems that we have. BTW, which time slot for us giving presentation? From 09:30 AM - 11:00 AM or part of this? Thanks, Maggie > Thanks, > > Perry > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9fkcoACgkQxdKLkeZeTz2pWACfR4Fu+lavU9h7dnahSkJLRit1 > NMMAoIma1kU/HXOQmg3lO9Guu/BVq7gm > =n3/L > -----END PGP SIGNATURE----- From mshao at redhat.com Wed Mar 14 07:10:46 2012 From: mshao at redhat.com (Maggie Shao) Date: Wed, 14 Mar 2012 15:10:46 +0800 Subject: Finalizing open workshop schedule In-Reply-To: <4F6042AB.7050800@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> <4F5F91CA.3050303@redhat.com> <4F6042AB.7050800@redhat.com> Message-ID: <4F604476.4080106@redhat.com> On 03/14/2012 03:03 PM, Maggie Shao wrote: > On 03/14/2012 02:28 AM, Perry Myers wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/13/2012 01:33 PM, Karsten 'quaid' Wade wrote: >>> Based on the below feedback I updated the agenda and posted it >>> here: >>> >>> http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop >>> >>> 09:30 - 11:00 :: oVirt intro& architecture (presented by Red Hat >>> engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: >>> Engine core (presented by Red Hat engineers) 12:00 - 12:30 :: API >>> (presented by Red Hat engineers) 12:30 - 13:30 :: LUNCH 13:30 - >>> 14:15 :: oVirt Node Arch and details of oVirt node (presented by >>> Red Hat engineers) >> Right now there are no engineers from the oVirt Node team that will be >> in Beijing for this workshop. However, we will have a few folks from >> the Red Hat QE team that are primarily responsible for RHEVH/oVirt >> Node testing. >> >> The QE folks should be able to interface for Q&A on oVirt Node/RHEVH, >> and we'll see if we can get them to do a brief overview as well, but >> that is not yet determined. So we should keep this slot open for now >> and we'll see if we can get someone to give the talk on oVirt Node >> architecture. > Our RHEVH QE - Qixiang Wan (qwan at redhat.com) can help to do the > presentation. He is reviewing the slide that sent by Mike today and he > will discuss with Perry/Mike for the problems that we have. > BTW, which time slot for us giving presentation? From 09:30 AM - > 11:00 AM or part of this? Or the time slot from 13:30 - 14:15? > > Thanks, > Maggie >> Thanks, >> >> Perry >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk9fkcoACgkQxdKLkeZeTz2pWACfR4Fu+lavU9h7dnahSkJLRit1 >> NMMAoIma1kU/HXOQmg3lO9Guu/BVq7gm >> =n3/L >> -----END PGP SIGNATURE----- > From mburns at redhat.com Wed Mar 14 13:42:12 2012 From: mburns at redhat.com (Mike Burns) Date: Wed, 14 Mar 2012 09:42:12 -0400 Subject: Finalizing open workshop schedule In-Reply-To: <4F604476.4080106@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> <4F5F91CA.3050303@redhat.com> <4F6042AB.7050800@redhat.com> <4F604476.4080106@redhat.com> Message-ID: <1331732532.14799.107.camel@beelzebub.mburnsfire.net> On Wed, 2012-03-14 at 15:10 +0800, Maggie Shao wrote: > On 03/14/2012 03:03 PM, Maggie Shao wrote: > > On 03/14/2012 02:28 AM, Perry Myers wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 03/13/2012 01:33 PM, Karsten 'quaid' Wade wrote: > >>> Based on the below feedback I updated the agenda and posted it > >>> here: > >>> > >>> http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop > >>> > >>> 09:30 - 11:00 :: oVirt intro& architecture (presented by Red Hat > >>> engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: > >>> Engine core (presented by Red Hat engineers) 12:00 - 12:30 :: API > >>> (presented by Red Hat engineers) 12:30 - 13:30 :: LUNCH 13:30 - > >>> 14:15 :: oVirt Node Arch and details of oVirt node (presented by > >>> Red Hat engineers) > >> Right now there are no engineers from the oVirt Node team that will be > >> in Beijing for this workshop. However, we will have a few folks from > >> the Red Hat QE team that are primarily responsible for RHEVH/oVirt > >> Node testing. > >> > >> The QE folks should be able to interface for Q&A on oVirt Node/RHEVH, > >> and we'll see if we can get them to do a brief overview as well, but > >> that is not yet determined. So we should keep this slot open for now > >> and we'll see if we can get someone to give the talk on oVirt Node > >> architecture. > > Our RHEVH QE - Qixiang Wan (qwan at redhat.com) can help to do the > > presentation. He is reviewing the slide that sent by Mike today and he > > will discuss with Perry/Mike for the problems that we have. > > BTW, which time slot for us giving presentation? From 09:30 AM - > > 11:00 AM or part of this? > Or the time slot from 13:30 - 14:15? Excellent. Thanks Maggie and Qixiang. Let me know how I can help with the presentation itself. As for the time slot, I believe that the schedule is still being finalized. I'll defer to the organizers for that final decision though. Mike > > > > Thanks, > > Maggie > >> Thanks, > >> > >> Perry > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.12 (GNU/Linux) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >> iEYEARECAAYFAk9fkcoACgkQxdKLkeZeTz2pWACfR4Fu+lavU9h7dnahSkJLRit1 > >> NMMAoIma1kU/HXOQmg3lO9Guu/BVq7gm > >> =n3/L > >> -----END PGP SIGNATURE----- > > > From kwade at redhat.com Wed Mar 14 14:02:51 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 14 Mar 2012 07:02:51 -0700 Subject: meeting in #ovirt Message-ID: <4F60A50B.80405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A reminder we are having the weekly oVirt meeting in #ovirt right now. - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPYKUL2ZIOBq0ODEERAnwbAJ4o7BGt+dTWQsJy1gshIUFLxvu6CACg0itI y7Jb0wFJpGXeJUDdtE93fQc= =D7cD -----END PGP SIGNATURE----- From sgordon at redhat.com Wed Mar 14 14:04:41 2012 From: sgordon at redhat.com (Steve Gordon) Date: Wed, 14 Mar 2012 10:04:41 -0400 (EDT) Subject: release blocking features for oVirt 3.1 In-Reply-To: <4F5787E2.4040403@redhat.com> Message-ID: <76bc0731-709b-42a0-8eaa-f8d92ed0c0af@zmail15.collab.prod.int.phx2.redhat.com> Just bumping this thread as a reminder, the list of blockers for the next release is to be finalized in this weeks sync meeting. Not much appears to have changed on the Wiki page in the interim though. Please ensure that all proposed blockers are added to the page prior to the meeting so we can go through them and ensure everybody is on board. Moran I would suggest adding your suggestions directly to the Wiki page so they aren't lost. We can always pull those that people don't agree with during the meeting. http://www.ovirt.org/wiki/Second_Release Thanks, Steve ----- Original Message ----- > From: "Moran Goldboim" > To: arch at ovirt.org > Sent: Wednesday, March 7, 2012 11:08:02 AM > Subject: release blocking features for oVirt 3.1 > > for the upcoming ovirt release we have the following > (http://www.ovirt.org/wiki/Second_Release): > > > MUST > > * *MUST*: Upgrade from previous release > * *MUST*: ovirt-node full cycle (register, approve and running > VM) > * *MUST*: No known data corruptors > * *MUST*: Can define NFS, iSCSI, FC and local based storage > domains > * *MUST*: Can define VLAN based networks, bond interfaces, and > have > VLANs over bonded interfaces > * *MUST*: Can authenticate users against at least one external > LDAP > server > * *MUST*: Can run multiple VMs > * *MUST*: Can connect to VMs using SPICE > > > > i would recommend adding (Musts): > > * no blockers on the lower level components - libvirt, lvm, > device-mapper,qemu-kvm > * all image related operations work - copy, move, import, > export, > snapshot (vm and template) > * ovirt/host installation should work flawlessly (w/o ssl) > * can do all above operations (define DC hierarchy so you can run > vm) with gui/cli/python-api/rest-api > * vm life-cycle is working flawlessly > (start,suspend,resume,stop,migrate) > > additions, objections, thoughts? > Moran. > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From kwade at redhat.com Wed Mar 14 14:08:04 2012 From: kwade at redhat.com (Karsten Wade) Date: Wed, 14 Mar 2012 10:08:04 -0400 (EDT) Subject: meeting in #ovirt In-Reply-To: <4F60A50B.80405@redhat.com> Message-ID: <1dcea106-84df-4a26-bb15-e2d892c79d61@zmail12.collab.prod.int.phx2.redhat.com> Sorry, I forgot about the time change. Let's meet in one hour when the rest of the world thinks it's time to meet. For us daylight savings folks, we'll be off this week. We can talk in the meeting about the preferred change for us to make - follow DST or not. ----- Original Message ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A reminder we are having the weekly oVirt meeting in #ovirt right > now. > > - -- > name: Karsten 'quaid' Wade, Sr. Community Architect > team: Red Hat Community Architecture & Leadership > uri: http://communityleadershipteam.org > http://TheOpenSourceWay.org > gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFPYKUL2ZIOBq0ODEERAnwbAJ4o7BGt+dTWQsJy1gshIUFLxvu6CACg0itI > y7Jb0wFJpGXeJUDdtE93fQc= > =D7cD > -----END PGP SIGNATURE----- > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > -- name: Karsten 'quaid' Wade, Sr. Community Gardener team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 From kwade at redhat.com Wed Mar 14 15:03:53 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 14 Mar 2012 08:03:53 -0700 Subject: Meeting times and DST Message-ID: <4F60B359.2060805@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a regular problem in global open source projects - what to do when people start rolling in to daylight savings time (DST). This last weekend was the rollover here in the US. A DST change means some people in the project are going to have their meeting change relative to their local clock. Some projects choose to keep the meeting at the same local time relative to one area's DST settings. For example, when a project is largely US-based developers, the meeting tends to stay the same time on the local clock and change twice a year for those using UTC. Some projects choose to peg their meeting time to UTC always, so that never changes. The each group in a country need to deal with changing the meeting on their local clock. Honestly, there are problems with any of these methods - people are inconvenienced, usually someone can't make the adjusted meeting time, etc. So we could just pick our preference as a project, post it on our meetings page, and try to remember when DST starts/stops so we remind people of that change: A. Follow UTC and let people deal with local DST changes. B. Follow DST by keeping the time the same within one particular country. C. If yes to B., which country do we peg to? - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPYLNZ2ZIOBq0ODEERAqX/AJsE56MxRLT/UmmXg6fXaSxQ8atscgCgpPFT s5LQBchDs52t87M8SXW29LA= =0NBk -----END PGP SIGNATURE----- From sgordon at redhat.com Wed Mar 14 15:07:20 2012 From: sgordon at redhat.com (Steve Gordon) Date: Wed, 14 Mar 2012 11:07:20 -0400 (EDT) Subject: Meeting times and DST In-Reply-To: <4F60B359.2060805@redhat.com> Message-ID: <711d72ce-604f-4cca-9b68-ee18431b8b03@zmail15.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Karsten 'quaid' Wade" > To: "" > Sent: Wednesday, March 14, 2012 11:03:53 AM > Subject: Meeting times and DST > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This is a regular problem in global open source projects - what to do > when people start rolling in to daylight savings time (DST). This > last > weekend was the rollover here in the US. > > A DST change means some people in the project are going to have their > meeting change relative to their local clock. > > Some projects choose to keep the meeting at the same local time > relative to one area's DST settings. For example, when a project is > largely US-based developers, the meeting tends to stay the same time > on the local clock and change twice a year for those using UTC. > > Some projects choose to peg their meeting time to UTC always, so that > never changes. The each group in a country need to deal with changing > the meeting on their local clock. > > Honestly, there are problems with any of these methods - people are > inconvenienced, usually someone can't make the adjusted meeting time, > etc. > > So we could just pick our preference as a project, post it on our > meetings page, and try to remember when DST starts/stops so we remind > people of that change: > > A. Follow UTC and let people deal with local DST changes. +1 to this. My main reason is we have two major groups of contributors in the US and in Israel, and their DST changes occur at different times, so I think pinning to UTC is the 'least bad' option. Steve > B. Follow DST by keeping the time the same within one particular > country. > C. If yes to B., which country do we peg to? > > - - Karsten > - -- > name: Karsten 'quaid' Wade, Sr. Community Architect > team: Red Hat Community Architecture & Leadership > uri: http://communityleadershipteam.org > http://TheOpenSourceWay.org > gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFPYLNZ2ZIOBq0ODEERAqX/AJsE56MxRLT/UmmXg6fXaSxQ8atscgCgpPFT > s5LQBchDs52t87M8SXW29LA= > =0NBk > -----END PGP SIGNATURE----- > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From iheim at redhat.com Wed Mar 14 15:38:38 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 14 Mar 2012 17:38:38 +0200 Subject: Finalizing open workshop schedule In-Reply-To: <4F604476.4080106@redhat.com> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> <4F5F91CA.3050303@redhat.com> <4F6042AB.7050800@redhat.com> <4F604476.4080106@redhat.com> Message-ID: <4F60BB7E.6080003@redhat.com> On 03/14/2012 09:10 AM, Maggie Shao wrote: > On 03/14/2012 03:03 PM, Maggie Shao wrote: ... >>> The QE folks should be able to interface for Q&A on oVirt Node/RHEVH, >>> and we'll see if we can get them to do a brief overview as well, but >>> that is not yet determined. So we should keep this slot open for now >>> and we'll see if we can get someone to give the talk on oVirt Node >>> architecture. >> Our RHEVH QE - Qixiang Wan (qwan at redhat.com) can help to do the >> presentation. He is reviewing the slide that sent by Mike today and he >> will discuss with Perry/Mike for the problems that we have. >> BTW, which time slot for us giving presentation? From 09:30 AM - 11:00 >> AM or part of this? > Or the time slot from 13:30 - 14:15? yes, 13:30-14:15. From simon at redhat.com Wed Mar 14 15:51:13 2012 From: simon at redhat.com (Simon Grinberg) Date: Wed, 14 Mar 2012 11:51:13 -0400 (EDT) Subject: Meeting times and DST In-Reply-To: <711d72ce-604f-4cca-9b68-ee18431b8b03@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > From: "Steve Gordon" > To: "Karsten 'quaid' Wade" > Cc: "arch" > Sent: Wednesday, March 14, 2012 5:07:20 PM > Subject: Re: Meeting times and DST > > > > ----- Original Message ----- > > From: "Karsten 'quaid' Wade" > > To: "" > > Sent: Wednesday, March 14, 2012 11:03:53 AM > > Subject: Meeting times and DST > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > This is a regular problem in global open source projects - what to > > do > > when people start rolling in to daylight savings time (DST). This > > last > > weekend was the rollover here in the US. > > > > A DST change means some people in the project are going to have > > their > > meeting change relative to their local clock. > > > > Some projects choose to keep the meeting at the same local time > > relative to one area's DST settings. For example, when a project is > > largely US-based developers, the meeting tends to stay the same > > time > > on the local clock and change twice a year for those using UTC. > > > > Some projects choose to peg their meeting time to UTC always, so > > that > > never changes. The each group in a country need to deal with > > changing > > the meeting on their local clock. > > > > Honestly, there are problems with any of these methods - people are > > inconvenienced, usually someone can't make the adjusted meeting > > time, > > etc. > > > > So we could just pick our preference as a project, post it on our > > meetings page, and try to remember when DST starts/stops so we > > remind > > people of that change: > > > > A. Follow UTC and let people deal with local DST changes. > > +1 to this. My main reason is we have two major groups of > contributors in the US and in Israel, and their DST changes occur at > different times, so I think pinning to UTC is the 'least bad' > option. > > Steve > > > B. Follow DST by keeping the time the same within one particular > > country. > > C. If yes to B., which country do we peg to? We are used to be outnumbered in most of the calls thus US wins. We usually pin all multi party meetings to US ET. IF we start pinning to UTC then it will cause conflicts with other meetings scheduled by US people as some will shift and some will not. Pinning to US ET guaranties that at least everything shifts together. > > > > - - Karsten > > - -- > > name: Karsten 'quaid' Wade, Sr. Community Architect > > team: Red Hat Community Architecture & Leadership > > uri: http://communityleadershipteam.org > > http://TheOpenSourceWay.org > > gpg: AD0E0C41 > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.12 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iD8DBQFPYLNZ2ZIOBq0ODEERAqX/AJsE56MxRLT/UmmXg6fXaSxQ8atscgCgpPFT > > s5LQBchDs52t87M8SXW29LA= > > =0NBk > > -----END PGP SIGNATURE----- > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From kwade at redhat.com Wed Mar 14 15:58:55 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 14 Mar 2012 08:58:55 -0700 Subject: Meeting minutes oVirt weekly sync 2012-03-14 Message-ID: <4F60C03F.5050103@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Minutes: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-14-15.02.html Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-14-15.02.txt Log: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-14-15.02.log.html ============== #ovirt Meeting ============== Meeting started by quaid at 15:02:21 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-14-15.02.log.html . Meeting summary - --------------- * roll call take 2 (quaid, 15:02:34) * Agenda review (quaid, 15:07:33) * DST update (quaid, 15:10:24) * Workshop update (quaid, 15:13:17) * Next release update - process, criteria, etc. (quaid, 15:18:23) * LINK: http://www.ovirt.org/governance/voting/ (quaid, 15:35:02) * the project has governance about voting already in place about voting (quaid, 15:35:21) * ACTION: oschreib make sure release process points to release voting governance (quaid, 15:49:40) * ACTION: oschreib make sure arch@ is familiar and comfortable with the release voting process (quaid, 15:50:01) * Anything else? (quaid, 15:55:00) Meeting ended at 15:57:12 UTC. Action Items - ------------ * oschreib make sure release process points to release voting governance * oschreib make sure arch@ is familiar and comfortable with the release voting process Action Items, by person - ----------------------- * oschreib * oschreib make sure release process points to release voting governance * oschreib make sure arch@ is familiar and comfortable with the release voting process * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * quaid (95) * oschreib (54) * sgordon (44) * mgoldboi (15) * ovirtbot (7) * mburns (2) * saggi (2) * flrichar (1) - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPYMA/2ZIOBq0ODEERAut2AJ0fLeAttOL69eOG7hxMp5vmig8eGwCeOZ6M bImofH5fAFUA07qIGVx69BY= =5k4T -----END PGP SIGNATURE----- From kwade at redhat.com Wed Mar 14 16:00:59 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 14 Mar 2012 09:00:59 -0700 Subject: Finalizing open workshop schedule In-Reply-To: <4F6036CA.3050702@linux.vnet.ibm.com> References: <4F5E5CA1.7080001@redhat.com> <4F6036CA.3050702@linux.vnet.ibm.com> Message-ID: <4F60C0BB.7090008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2012 11:12 PM, Hui Kai Ran wrote: > >> Since the organizer have invited some persons to give a opening >> welcome, Could we add about a half an hour session at the top of >> the agenda like this? >> >> 9:00 - 9:30 :: Opening Welcome and Introductions Great, thanks, that is now added. http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop - - Karsten > 09:30 - 10:15 :: oVirt intro& architecture (presented by Red Hat > engineers) 10:15 - 11:00 :: Engine core (presented by Red Hat > engineers) 11:00 - 11:15 :: MORNING TEA BREAK 11:15 - 12:00 :: MOM > integration (presented by IBM engineers) 12:00 - 12:45 :: API > (presented by Red Hat engineers) 12:45 - 13:30 :: LUNCH 13:30 - > 14:15 :: oVirt Node Arch and details of oVirt node (presented by > Red Hat engineers) 14:15 - 15:00 :: VDSM (presented by Red Hat > engineers) 15:00 - 15:45 :: Storage (presented by Red Hat > engineers) 15:45 - 16:30 :: AFTERNOON TEA BREAK 16:30 - 17:15 :: > Guest agent, history and reports (presented by Red Hat engineers) > 17:15 - 17:30 :: Wrap-up and finish > > Thanks - Karsten -- name: Karsten 'quaid' Wade, Sr. Community > Architect team: Red Hat Community Architecture& Leadership uri: > http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: > AD0E0C41 >> _______________________________________________ Arch mailing >> list Arch at ovirt.org http://lists.ovirt.org/mailman/listinfo/arch >> > - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPYMC72ZIOBq0ODEERAkX4AKDdEi296tfM26bVRl28+I2CgUpvhwCgv1qa 0zGCzVeRMXZWfdiZaAh1CQU= =mwqb -----END PGP SIGNATURE----- From kwade at redhat.com Wed Mar 14 16:02:00 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 14 Mar 2012 09:02:00 -0700 Subject: Finalizing open workshop schedule In-Reply-To: <1331732532.14799.107.camel@beelzebub.mburnsfire.net> References: <4F5E5CA1.7080001@redhat.com> <4F5F242C.90803@redhat.com> <4F5F84DB.6020701@redhat.com> <4F5F91CA.3050303@redhat.com> <4F6042AB.7050800@redhat.com> <4F604476.4080106@redhat.com> <1331732532.14799.107.camel@beelzebub.mburnsfire.net> Message-ID: <4F60C0F8.5000305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2012 06:42 AM, Mike Burns wrote: > >> As for the time slot, I believe that the schedule is still being >> finalized. I'll defer to the organizers for that final decision >> though. I think we are very nearly complete. Here is the latest agenda/schedule: http://www.ovirt.org/wiki/Workshop_March_2012#Agenda_for_workshop - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPYMD42ZIOBq0ODEERAhb7AKDaRIIc6IbHXEFJ3xO0oNWjuqT6mwCfe9It aB2FgWpiyAZ4SSkkbfTklR4= =Lhv8 -----END PGP SIGNATURE----- From sgordon at redhat.com Wed Mar 14 18:50:23 2012 From: sgordon at redhat.com (Steve Gordon) Date: Wed, 14 Mar 2012 14:50:23 -0400 (EDT) Subject: freenode vs. oftc In-Reply-To: <4F5FC0A8.3070101@redhat.com> Message-ID: <8cc9f850-8701-4232-a531-07af6a6660e9@zmail15.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Karsten 'quaid' Wade" > To: arch at ovirt.org > Sent: Tuesday, March 13, 2012 5:48:24 PM > Subject: Re: freenode vs. oftc > > > I know this is quickly turning into a bikeshed post, but from my > > point of view we have taken this from what should have been a > > fairly simple problem (choose a network) and found the one solution > > which is even worse (both). > > My last post wasn't intended to say 'both', it was intended to say, > 'keep OFTC and move any traffic on Freenode to OFTC'. (Call that my > low-energy solution.) There were multiple questions in this > discussion > since there are some projects on Freenode, some on OFTC. One question > was to move the canonical channel, no reason was found, and it > appeared more related projects were on OFTC already. Another question > is what to do with #ovirt on Freenode. > > So long way around, the final question above results in your > proposal, > "Return #ovirt on Freenode's kickban + clear message to go to OFTC", > to which I add, "And request other oVirt discussions on Freenode to > move to OFTC." That seems workable for the current need. > > If you agree to that proposal, I reckon we have your +1 and I'll > remain +0 for now. In a nutshell yes, that is what I would propose we should do going forward. Steve From kwade at redhat.com Wed Mar 14 19:26:10 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 14 Mar 2012 12:26:10 -0700 Subject: Meeting times and DST In-Reply-To: <711d72ce-604f-4cca-9b68-ee18431b8b03@zmail15.collab.prod.int.phx2.redhat.com> References: <711d72ce-604f-4cca-9b68-ee18431b8b03@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4F60F0D2.1030207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2012 08:07 AM, Steve Gordon wrote: > > > ----- Original Message ----- >> From: "Karsten 'quaid' Wade" > > A. Follow UTC and let people deal with local DST changes. > >> +1 to this. My main reason is we have two major groups of >> contributors in the US and in Israel, and their DST changes >> occur at different times, so I think pinning to UTC is the 'least >> bad' option. Would we make the same choice if there were a more even spread of contributors around the globe? I think yes, since that could be a 'most good' option. In addition, if the meeting moves compared to UTC, that is really moving a meeting time, which is a good way to stab people for attending on time-but-whoops-not-in-your-timezone. I suppose all solutions have the same overhead of reminding people about the affect if they have follow DST. - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPYPDS2ZIOBq0ODEERAjhvAKDMk4znMb1pmL2BXuOwQW1l25q+5gCeLxR9 +3uXbvDy/XYm+z7CNW66cr4= =TMVO -----END PGP SIGNATURE----- From kwade at redhat.com Wed Mar 14 19:48:18 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 14 Mar 2012 12:48:18 -0700 Subject: Meeting times and DST In-Reply-To: References: Message-ID: <4F60F602.9030008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2012 08:51 AM, Simon Grinberg wrote: >> We are used to be outnumbered in most of the calls thus US wins. >> We usually pin all multi party meetings to US ET. > >> IF we start pinning to UTC then it will cause conflicts with >> other meetings scheduled by US people as some will shift and some >> will not. Pinning to US ET guaranties that at least everything >> shifts together. This is the other half of the problem that we see in e.g. Fedora Project. Many do respond as you describe, based on the need of the majority of the team. That means it's a mix, done ad-hoc - some Fedora teams use UTC because it's best for most members. But that's Fedora, not oVirt ... The challenge is, the "we" who come to the meetings in #ovirt is the superset to the "we" who have conceded that inside Red Hat, US ET *is* the standard (some of us have called it HQZ or RHZ. ;-D ) Currently the set of people who come to the meetings are more largely part of the Red Hat set, but that shouldn't always be so. Not even all the developers working on oVirt for their respective corporations have an HQ based in the US. What's the solution best for the current and future contributors? Especially to make it welcoming to others to participate? - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPYPYC2ZIOBq0ODEERAi/LAKDOFAaONB4HqfuQ0rIhGu2+OVNeAQCePwSk O9aErz6IbPNoPaew7VsRha4= =FHNI -----END PGP SIGNATURE----- From oschreib at redhat.com Thu Mar 15 17:25:48 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Thu, 15 Mar 2012 13:25:48 -0400 (EDT) Subject: Release process proposal - final draft In-Reply-To: <92286c25-3159-41c4-aa1c-8bb31f3442eb@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: All, The final draft of the release process is available at http://www.ovirt.org/wiki/Release_Process As discussed in the last sync meeting, this draft includes a formal release vote procedure, described in http://www.ovirt.org/governance/voting/ Comment now, or forever hold your peace. Thanks, Ofer Schreiber oVirt Release Manager From simon at redhat.com Thu Mar 15 17:46:21 2012 From: simon at redhat.com (Simon Grinberg) Date: Thu, 15 Mar 2012 13:46:21 -0400 (EDT) Subject: Meeting times and DST In-Reply-To: <4F60F602.9030008@redhat.com> Message-ID: ----- Original Message ----- > From: "Karsten 'quaid' Wade" > To: "arch" > Sent: Wednesday, March 14, 2012 9:48:18 PM > Subject: Re: Meeting times and DST > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/14/2012 08:51 AM, Simon Grinberg wrote: > > >> We are used to be outnumbered in most of the calls thus US wins. > >> We usually pin all multi party meetings to US ET. > > > >> IF we start pinning to UTC then it will cause conflicts with > >> other meetings scheduled by US people as some will shift and some > >> will not. Pinning to US ET guaranties that at least everything > >> shifts together. > > This is the other half of the problem that we see in e.g. Fedora > Project. Many do respond as you describe, based on the need of the > majority of the team. That means it's a mix, done ad-hoc - some > Fedora > teams use UTC because it's best for most members. But that's Fedora, > not oVirt ... > > The challenge is, the "we" who come to the meetings in #ovirt is the > superset to the "we" who have conceded that inside Red Hat, US ET > *is* > the standard (some of us have called it HQZ or RHZ. ;-D ) > > Currently the set of people who come to the meetings are more largely > part of the Red Hat set, but that shouldn't always be so. Not even > all > the developers working on oVirt for their respective corporations > have > an HQ based in the US. What's the solution best for the current and > future contributors? Especially to make it welcoming to others to > participate? I don't think this will be the gating item preventing others to join oVirt :) Let's face it, the problem exists in many organizations not just Red Hat, practically any US based company uses this convention. I used to work for Motorola and then Cisco and it was always the same. What will happen is that if oVirt decides on UTC locking (which AFAIK never changes to day light saving time) it guaranties conflicts for everybody at some point as their own clock moved while if you lock to ET for example, you'll have many that will not be effected and many others that are effected but at least no meetings conflict. You will never be able to satisfy all but this does not mean that in order to be "fair and impartial" you'll guarantee that all are hit the same way :). I think that at least you can try to accommodate as many as you can. But this is just my 2c > > - - Karsten > - -- > name: Karsten 'quaid' Wade, Sr. Community Architect > team: Red Hat Community Architecture & Leadership > uri: http://communityleadershipteam.org > http://TheOpenSourceWay.org > gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFPYPYC2ZIOBq0ODEERAi/LAKDOFAaONB4HqfuQ0rIhGu2+OVNeAQCePwSk > O9aErz6IbPNoPaew7VsRha4= > =FHNI > -----END PGP SIGNATURE----- > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From iheim at redhat.com Thu Mar 15 20:16:06 2012 From: iheim at redhat.com (Itamar Heim) Date: Thu, 15 Mar 2012 22:16:06 +0200 Subject: Meeting times and DST In-Reply-To: References: Message-ID: <4F624E06.5030103@redhat.com> On 03/15/2012 07:46 PM, Simon Grinberg wrote: > > > ----- Original Message ----- >> From: "Karsten 'quaid' Wade" >> To: "arch" >> Sent: Wednesday, March 14, 2012 9:48:18 PM >> Subject: Re: Meeting times and DST >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/14/2012 08:51 AM, Simon Grinberg wrote: >> >>>> We are used to be outnumbered in most of the calls thus US wins. >>>> We usually pin all multi party meetings to US ET. >>> >>>> IF we start pinning to UTC then it will cause conflicts with >>>> other meetings scheduled by US people as some will shift and some >>>> will not. Pinning to US ET guaranties that at least everything >>>> shifts together. >> >> This is the other half of the problem that we see in e.g. Fedora >> Project. Many do respond as you describe, based on the need of the >> majority of the team. That means it's a mix, done ad-hoc - some >> Fedora >> teams use UTC because it's best for most members. But that's Fedora, >> not oVirt ... >> >> The challenge is, the "we" who come to the meetings in #ovirt is the >> superset to the "we" who have conceded that inside Red Hat, US ET >> *is* >> the standard (some of us have called it HQZ or RHZ. ;-D ) >> >> Currently the set of people who come to the meetings are more largely >> part of the Red Hat set, but that shouldn't always be so. Not even >> all >> the developers working on oVirt for their respective corporations >> have >> an HQ based in the US. What's the solution best for the current and >> future contributors? Especially to make it welcoming to others to >> participate? > > I don't think this will be the gating item preventing others to join oVirt :) > Let's face it, the problem exists in many organizations not just Red Hat, practically any US based company uses this convention. I used to work for Motorola and then Cisco and it was always the same. > > What will happen is that if oVirt decides on UTC locking (which AFAIK never changes to day light saving time) it guaranties conflicts for everybody at some point as their own clock moved while if you lock to ET for example, you'll have many that will not be effected and many others that are effected but at least no meetings conflict. > > You will never be able to satisfy all but this does not mean that in order to be "fair and impartial" you'll guarantee that all are hit the same way :). I think that at least you can try to accommodate as many as you can. > > But this is just my 2c main reason i think not doing UTC based is that most do have DST, and using UTC means half of the year the meeting will be at a different hour, rather than maybe 2-3 weeks out of the year From mgoldboi at redhat.com Sun Mar 18 09:49:12 2012 From: mgoldboi at redhat.com (Moran Goldboim) Date: Sun, 18 Mar 2012 11:49:12 +0200 Subject: Release process proposal - final draft In-Reply-To: References: Message-ID: <4F65AF98.8070703@redhat.com> On 03/15/2012 07:25 PM, Ofer Schreiber wrote: > All, > > The final draft of the release process is available at http://www.ovirt.org/wiki/Release_Process > As discussed in the last sync meeting, this draft includes a formal release vote procedure, described in http://www.ovirt.org/governance/voting/ > > Comment now, or forever hold your peace. > > Thanks, > Ofer Schreiber > oVirt Release Manager > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch looks good to me, please consider the following,** http://www.ovirt.org/wiki/Release_Process [snip] 6. 30 days before release - release candidate * OPTIONAL: final release requires three +1 from community members i would like to see +1 from each component dev owner- indicating that his component is ready for final release. in addition i think we need to set musts and shoulds for components as well, which will indicate which components are a must for a release, thus indicating if the release should be delayed based on a major problem on a specific component. Moran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ykaul at redhat.com Tue Mar 20 11:29:19 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Tue, 20 Mar 2012 13:29:19 +0200 Subject: Wiki down/slow? Message-ID: <4F686A0F.4090807@redhat.com> The Wiki has been misbehaving most of the morning - slow or unavailable (at least from Red Hat offices in TLV). Any ETA for a fix? (btw, would be nice to have it at wiki.ovirt.org) Y. From oschreib at redhat.com Tue Mar 20 12:48:15 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Tue, 20 Mar 2012 08:48:15 -0400 (EDT) Subject: Wiki down/slow? In-Reply-To: <4F686A0F.4090807@redhat.com> Message-ID: <2743685b-1d77-4d21-89f4-4a91d7535cf7@zmail14.collab.prod.int.phx2.redhat.com> mburns, quaid and myself are working on the ovirt.org outage. more updates soon. ----- Original Message ----- > The Wiki has been misbehaving most of the morning - slow or > unavailable > (at least from Red Hat offices in TLV). > Any ETA for a fix? > > (btw, would be nice to have it at wiki.ovirt.org) > Y. > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From oschreib at redhat.com Tue Mar 20 14:18:57 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Tue, 20 Mar 2012 10:18:57 -0400 (EDT) Subject: Outage Update - www.ovirt.org and gerrit.ovirt.org In-Reply-To: <2aef2b5d-e439-4437-aab1-39abe740c871@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <3f567588-5ee6-4bb2-8be9-15f50b053a61@zmail14.collab.prod.int.phx2.redhat.com> www.ovirt.org and gerrit.ovirt.org are now up and running. We experienced two issues: 1. DB corruption on www.ovirt.org, caused by a full file system. 2. Faulty gerrit service, probably caused by #1. Both issues were handled by oVirt infra team (mburns, quaid and myself) Thank you for your patience. Ofer Schreiber oVirt infra team From eedri at redhat.com Tue Mar 20 15:22:21 2012 From: eedri at redhat.com (Eyal Edri) Date: Tue, 20 Mar 2012 11:22:21 -0400 (EDT) Subject: Outage Update - www.ovirt.org and gerrit.ovirt.org In-Reply-To: <3f567588-5ee6-4bb2-8be9-15f50b053a61@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <0a88236b-c94d-41e4-bf54-945a1279a673@zmail17.collab.prod.int.phx2.redhat.com> If jenkins.ovirt.org will have access to the other servers, we might be able to add system jobs that deleted old files and such, i do it downstream to delete old files from multiple dirs on jenkins slaves. running a cmd like: 'sudo find . -type f -mtime +${days_to_keep} |grep -v ^\.$| sudo xargs rm -rf' where days_to_keep is a param we can change. of course, we'll have to make sure jenkins has write/delete permission to the monitored dirs. ----- Original Message ----- > From: "Ofer Schreiber" > To: "users" , arch at ovirt.org, infra at ovirt.org > Sent: Tuesday, March 20, 2012 4:18:57 PM > Subject: Outage Update - www.ovirt.org and gerrit.ovirt.org > > www.ovirt.org and gerrit.ovirt.org are now up and running. > > We experienced two issues: > 1. DB corruption on www.ovirt.org, caused by a full file system. > 2. Faulty gerrit service, probably caused by #1. > > Both issues were handled by oVirt infra team (mburns, quaid and > myself) > > Thank you for your patience. > > Ofer Schreiber > oVirt infra team > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From mburns at redhat.com Tue Mar 20 16:48:25 2012 From: mburns at redhat.com (Mike Burns) Date: Tue, 20 Mar 2012 12:48:25 -0400 Subject: Outage Update - www.ovirt.org and gerrit.ovirt.org In-Reply-To: <0a88236b-c94d-41e4-bf54-945a1279a673@zmail17.collab.prod.int.phx2.redhat.com> References: <0a88236b-c94d-41e4-bf54-945a1279a673@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <1332262105.2559.53.camel@beelzebub.mburnsfire.net> On Tue, 2012-03-20 at 11:22 -0400, Eyal Edri wrote: > If jenkins.ovirt.org will have access to the other servers, > we might be able to add system jobs that deleted old files and such, > > i do it downstream to delete old files from multiple dirs on jenkins slaves. > > running a cmd like: 'sudo find . -type f -mtime +${days_to_keep} |grep -v ^\.$| sudo xargs rm -rf' I think a command like this works well. I have something similar setup on similar backup area. I don't think we need jenkins to run this though. A simple cron job with output mails going to root (which get sent to infra list admins already) should be sufficient. Mike > > where days_to_keep is a param we can change. > of course, we'll have to make sure jenkins has write/delete permission to the monitored dirs. > > ----- Original Message ----- > > From: "Ofer Schreiber" > > To: "users" , arch at ovirt.org, infra at ovirt.org > > Sent: Tuesday, March 20, 2012 4:18:57 PM > > Subject: Outage Update - www.ovirt.org and gerrit.ovirt.org > > > > www.ovirt.org and gerrit.ovirt.org are now up and running. > > > > We experienced two issues: > > 1. DB corruption on www.ovirt.org, caused by a full file system. > > 2. Faulty gerrit service, probably caused by #1. > > > > Both issues were handled by oVirt infra team (mburns, quaid and > > myself) > > > > Thank you for your patience. > > > > Ofer Schreiber > > oVirt infra team > > _______________________________________________ > > Arch mailing list > > Arch at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/arch > > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From sgordon at redhat.com Tue Mar 20 19:11:49 2012 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 20 Mar 2012 15:11:49 -0400 (EDT) Subject: Repo files In-Reply-To: Message-ID: <6dd43489-5ba0-4e1d-afb8-ec12ea961735@zmail15.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Steve Gordon" > To: "Ofer Schreiber" > Cc: "Perry Myers" , arch at ovirt.org > Sent: Saturday, February 11, 2012 12:07:06 PM > Subject: Re: Repo files > > > On 10 Feb 2012, at 00:33, Perry Myers wrote: > > > > > On 02/09/2012 05:09 PM, Steve Gordon wrote: > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Mike Burns" > > >>> To: arch at ovirt.org > > >>> Sent: Thursday, February 9, 2012 5:00:54 PM > > >>> Subject: Repo files > > >>> > > >>> Currently, we are providing 2 repo files, both named > > >>> ovirt-engine.repo. > > >>> One is located in the nightly area of the repository, and the > > >>> other > > >>> in > > >>> the stable area. > > >>> > > >>> Would it make more sense to: > > >>> > > >>> 1. Have a single repo file containing an entry for both stable > > >>> and > > >>> nightly with just stable enabled by default? > > >>> 2. Provide this in some form of ovirt-release RPM? > > >>> > > >> > > >> This was brought up previously and my belief was (and is) that > > >> yes > > >> we should do this. At the time the repo and spec file I made > > >> with > > >> assistance from Karsten were put here: > > >> > > >> http://www.ovirt.org/wiki/Yum_repo_file > > >> > > >> A few minor changes are required (for instance I don't believe > > >> we > > >> include the arch in the path as originally suggested nor do we > > >> have SRPM directories yet) but I still think for the most part > > >> this holds. In particular I think using a repo file distributed > > >> in an RPM is very useful because: > > >> > > >> - We can update the repo file and bump the NVR of the RPM as > > >> required and have yum pick it up as required, rather than > > >> putting > > >> it on the website and hoping users see the note to grab an > > >> updated one. > > >> - One repo file to rule them all, this configuration supports > > >> both > > >> nightly and stable from one file (ideally) in a consistent > > >> location. > > >> - Will make life much easier when we want to add a GPG key and > > >> start signing packages. > > > > > > +1 to Steve's proposal > > > > +1 here as well. > > > > Feel free to combine the repo files, sounds better than the current > > configuration. > > > > Will make the required changes on Monday and put up an RPM/SRPM. > > Steve Hi all, Bit of a thread necro on my part here, I've built the ovirt-release package to wrap around the repository file and put it here: http://ovirt.org/releases/ovirt-release-1-2.noarch.rpm Currently it caters for both nightly and stable, with the default being stable (nightly will not be used unless --enable-repo=ovirt-nightly is passed to yum). Further information is available here: http://ovirt.org/wiki/Yum_repo_file Note that I took out the bits pertaining to sources as we don't currently have a separate SRPM folder. Steve From pmyers at redhat.com Tue Mar 20 19:16:16 2012 From: pmyers at redhat.com (Perry Myers) Date: Tue, 20 Mar 2012 15:16:16 -0400 Subject: Repo files In-Reply-To: <6dd43489-5ba0-4e1d-afb8-ec12ea961735@zmail15.collab.prod.int.phx2.redhat.com> References: <6dd43489-5ba0-4e1d-afb8-ec12ea961735@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4F68D780.2070309@redhat.com> > Hi all, > > Bit of a thread necro on my part here, I've built the ovirt-release package to wrap around the repository file and put it here: > > http://ovirt.org/releases/ovirt-release-1-2.noarch.rpm > > Currently it caters for both nightly and stable, with the default being stable (nightly will not be used unless --enable-repo=ovirt-nightly is passed to yum). Further information is available here: > > http://ovirt.org/wiki/Yum_repo_file thanks :) > Note that I took out the bits pertaining to sources as we don't currently have a separate SRPM folder. Hm. That's a good point. We _should_ have SRPM repositories as well, no? From sgordon at redhat.com Tue Mar 20 19:20:18 2012 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 20 Mar 2012 15:20:18 -0400 (EDT) Subject: Repo files In-Reply-To: <4F68D780.2070309@redhat.com> Message-ID: <348ba136-8d82-41fe-8397-cc89effe7ec3@zmail15.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Perry Myers" > To: "Steve Gordon" > Cc: "Ofer Schreiber" , arch at ovirt.org > Sent: Tuesday, March 20, 2012 3:16:16 PM > Subject: Re: Repo files > > > Hi all, > > > > Bit of a thread necro on my part here, I've built the ovirt-release > > package to wrap around the repository file and put it here: > > > > http://ovirt.org/releases/ovirt-release-1-2.noarch.rpm > > > > Currently it caters for both nightly and stable, with the default > > being stable (nightly will not be used unless > > --enable-repo=ovirt-nightly is passed to yum). Further information > > is available here: > > > > http://ovirt.org/wiki/Yum_repo_file > > thanks :) > > > Note that I took out the bits pertaining to sources as we don't > > currently have a separate SRPM folder. > > Hm. That's a good point. We _should_ have SRPM repositories as > well, no? > Personally I think the answer is yes, as it currently stands the SRPMs (for the most part) exist in the tree in the same directory as the RPMs themselves currently. Steve From mburns at redhat.com Wed Mar 21 15:38:16 2012 From: mburns at redhat.com (Mike Burns) Date: Wed, 21 Mar 2012 11:38:16 -0400 Subject: Meeting minutes oVirt Weekly Sync 2012-03-21 Message-ID: <1332344296.2559.78.camel@beelzebub.mburnsfire.net> Minutes: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.html Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.txt Log: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by mburns at 15:07:32 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.log.html . Meeting summary --------------- * release criteria (mburns, 15:09:43) * LINK: http://www.ovirt.org/wiki/Second_Release (oschreib, 15:11:24) * LINK: http://www.ovirt.org/wiki/Second_Release (mburns, 15:11:35) * release criteria looks good for this release (mburns, 15:15:19) * we can refine in future releases (mburns, 15:15:34) * site outage wrapup (mburns, 15:16:04) * ovirt.org site was down for a couple hours due to ENOSPACE on the host (mburns, 15:17:41) * problem was backup that kept an infinite number of copies (mburns, 15:18:05) * resolved by cleaning up old copies, restarting mysql, httpd (mburns, 15:18:36) * had to rebuild one table in the mysql database due to corruprtion (mburns, 15:20:19) * steps being taken: (mburns, 15:20:30) * 1. don't keep infinite backups (mburns, 15:20:40) * 2. investigate either adding more space or moving to new host (mburns, 15:20:56) * Other Topics (mburns, 15:22:58) * AGREED: meet next week as usual (mburns, 15:25:36) * should discuss moving to bi-weekly if lack of topics continues (mburns, 15:25:54) Meeting ended at 15:28:00 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mburns (36) * oschreib (12) * sgordon (5) * ovirtbot (3) * fabiand (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From kwade at redhat.com Wed Mar 21 18:14:37 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 21 Mar 2012 11:14:37 -0700 Subject: Meeting minutes oVirt Weekly Sync 2012-03-21 In-Reply-To: <1332344296.2559.78.camel@beelzebub.mburnsfire.net> References: <1332344296.2559.78.camel@beelzebub.mburnsfire.net> Message-ID: <4F6A1A8D.90508@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2012 08:38 AM, Mike Burns wrote: > Minutes: > http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.html > Minutes (text): > http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.txt > Log: > http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.log.html Mike > et al: Thanks for running with the meeting today. I had a conflict and forgot to send out word. (Of course, I *love* sharing meeting running duties around, for anyone else who is interested in practicing the subtle art of running open source IRC meetings ...) - - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPahqN2ZIOBq0ODEERAgj9AKCTcnmg/ktAOO4FMf6DxeqjrJPKHQCgu92z UdkE/oN1jdFl1EA0VuuUawY= =VeyY -----END PGP SIGNATURE----- From mburns at redhat.com Thu Mar 22 14:13:53 2012 From: mburns at redhat.com (Mike Burns) Date: Thu, 22 Mar 2012 10:13:53 -0400 Subject: Meeting minutes oVirt Weekly Sync 2012-03-21 In-Reply-To: <4F6A1A8D.90508@redhat.com> References: <1332344296.2559.78.camel@beelzebub.mburnsfire.net> <4F6A1A8D.90508@redhat.com> Message-ID: <1332425633.2559.124.camel@beelzebub.mburnsfire.net> On Wed, 2012-03-21 at 11:14 -0700, Karsten 'quaid' Wade wrote: > On 03/21/2012 08:38 AM, Mike Burns wrote: > > Minutes: > > http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.html > > Minutes (text): > > http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.txt > > Log: > > http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-21-15.07.log.html > > Mike > > > et al: > > Thanks for running with the meeting today. I had a conflict and forgot > to send out word. (Of course, I *love* sharing meeting running duties > around, for anyone else who is interested in practicing the subtle art > of running open source IRC meetings ...) No prob with running the meeting, though obviously better if I have a little notice first ;-). On a separate note, can you take over the meeting invite from Robyn and resend it to the arch@ and board@ lists? I got a request for the meeting invite, but I don't own it to send the original and I wouldn't want it to send it and have them miss changes. Mike > > - Karsten > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From anthony at codemonkey.ws Sun Mar 25 13:26:08 2012 From: anthony at codemonkey.ws (Anthony Liguori) Date: Sun, 25 Mar 2012 08:26:08 -0500 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F6F1BE2.6040002@redhat.com> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <4F6F1BE2.6040002@redhat.com> Message-ID: <4F6F1CF0.1040003@codemonkey.ws> On 03/25/2012 08:21 AM, Avi Kivity wrote: > On 03/11/2012 04:12 PM, Anthony Liguori wrote: >> This discussion isn't about whether QEMU should have a Westmere >> processor definition. In fact, I think I already applied that patch. >> >> It's a discussion about how we handle this up and down the stack. >> >> The question is who should define and manage CPU compatibility. Right >> now QEMU does to a certain degree, libvirt discards this and does it's >> own thing, and VDSM/ovirt-engine assume that we're providing something >> and has built a UI around it. >> >> What I'm proposing we consider: have VDSM manage CPU definitions in >> order to provide a specific user experience in ovirt-engine. >> >> We would continue to have Westmere/etc in QEMU exposed as part of the >> user configuration. But I don't think it makes a lot of sense to have >> to modify QEMU any time a new CPU comes out. > > We have to. New features often come with new MSRs which need to be live > migrated, and of course the cpu flags as well. We may push all these to > qemu data files, but this is still qemu. We can't let a management tool > decide that cpu feature X is safe to use on qemu version Y. I think QEMU should own CPU definitions. I think a management tool should have the choice of whether they are used though because they are a policy IMHO. It's okay for QEMU to implement some degree of policy as long as a management tool can override it with a different policy. Regards, Anthony Liguori > From xrx-ovirt at xrx.me Sun Mar 25 17:37:25 2012 From: xrx-ovirt at xrx.me (xrx) Date: Sun, 25 Mar 2012 21:37:25 +0400 Subject: Outage Update - www.ovirt.org and gerrit.ovirt.org In-Reply-To: <3f567588-5ee6-4bb2-8be9-15f50b053a61@zmail14.collab.prod.int.phx2.redhat.com> References: <3f567588-5ee6-4bb2-8be9-15f50b053a61@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4F6F57D5.5060701@xrx.me> On 03/20/12 18:18, Ofer Schreiber wrote: > www.ovirt.org and gerrit.ovirt.org are now up and running. > > We experienced two issues: > 1. DB corruption on www.ovirt.org, caused by a full file system. > 2. Faulty gerrit service, probably caused by #1. I highly recommend having Nagios (or it's fork Icinga) for server monitoring; it would have warned you of the FS being full well beforehand. -xrx > > Both issues were handled by oVirt infra team (mburns, quaid and myself) > > Thank you for your patience. > > Ofer Schreiber > oVirt infra team > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From avi at redhat.com Sun Mar 25 13:21:38 2012 From: avi at redhat.com (Avi Kivity) Date: Sun, 25 Mar 2012 15:21:38 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F5CB2EA.10000@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> Message-ID: <4F6F1BE2.6040002@redhat.com> On 03/11/2012 04:12 PM, Anthony Liguori wrote: >> Let me elaborate about the later. Suppose host CPU has kill_guest >> feature and at the time a guest was installed it was not implemented by >> kvm. Since it was not implemented by kvm it was not present in vcpu >> during installation and the guest didn't install "workaround kill_guest" >> module. Now unsuspecting user upgrades the kernel and tries to restart >> the guest and fails. He writes angry letter to qemu-devel and is >> asked to >> reinstall his guest and move along. > > > -cpu best wouldn't solve this. You need a read/write configuration > file where QEMU probes the available CPU and records it to be used for > the lifetime of the VM. This doesn't work with live migration, and makes templating harder. The only persistent storage we can count on are disk images. The current approach is simple. The management tool determines the configuration, qemu applies it. Unidirectional information flow. This also lends itself to the management tool scanning a cluster and determining a GCD. > This discussion isn't about whether QEMU should have a Westmere > processor definition. In fact, I think I already applied that patch. > > It's a discussion about how we handle this up and down the stack. > > The question is who should define and manage CPU compatibility. Right > now QEMU does to a certain degree, libvirt discards this and does it's > own thing, and VDSM/ovirt-engine assume that we're providing something > and has built a UI around it. > > What I'm proposing we consider: have VDSM manage CPU definitions in > order to provide a specific user experience in ovirt-engine. > > We would continue to have Westmere/etc in QEMU exposed as part of the > user configuration. But I don't think it makes a lot of sense to have > to modify QEMU any time a new CPU comes out. We have to. New features often come with new MSRs which need to be live migrated, and of course the cpu flags as well. We may push all these to qemu data files, but this is still qemu. We can't let a management tool decide that cpu feature X is safe to use on qemu version Y. -- error compiling committee.c: too many arguments to function From avi at redhat.com Sun Mar 25 16:06:52 2012 From: avi at redhat.com (Avi Kivity) Date: Sun, 25 Mar 2012 18:06:52 +0200 Subject: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt In-Reply-To: <4F6F1CF0.1040003@codemonkey.ws> References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <4F6F1BE2.6040002@redhat.com> <4F6F1CF0.1040003@codemonkey.ws> Message-ID: <4F6F429C.8060202@redhat.com> On 03/25/2012 03:26 PM, Anthony Liguori wrote: >>> We would continue to have Westmere/etc in QEMU exposed as part of the >>> user configuration. But I don't think it makes a lot of sense to have >>> to modify QEMU any time a new CPU comes out. >> >> We have to. New features often come with new MSRs which need to be live >> migrated, and of course the cpu flags as well. We may push all these to >> qemu data files, but this is still qemu. We can't let a management tool >> decide that cpu feature X is safe to use on qemu version Y. > > > I think QEMU should own CPU definitions. Agree. > I think a management tool should have the choice of whether they are > used though because they are a policy IMHO. > > It's okay for QEMU to implement some degree of policy as long as a > management tool can override it with a different policy. Sure. We can have something like # default machine's westmere qemu -cpu westmere # pc-1.0's westmere qemu -M pc-1.0 -cpu westmere # pc-1.0's westmere, without nx-less qemu -M pc-1.0 -cpu westmere,-nx # specify everything in painful detail qemu -cpu vendor=Foo,family=17,model=19,stepping=3,maxleaf=12,+fpu,+vme,leaf10eax=0x1234567,+etc -- error compiling committee.c: too many arguments to function From kwade at redhat.com Wed Mar 28 14:39:32 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 28 Mar 2012 07:39:32 -0700 Subject: Meeting 28 March Message-ID: <4F7322A4.5070006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So we didn't really settle what to do with DST on this list. Personally, it helps *me* if we switch with the US since that is where I live. It appears, thought, that it did move - it used to be 7 am for me, and now it's 8 am. Here is the agenda I have: * Release status check-in * Fedora 17 support: ** What is F17 feature schedule? ** When do we start build packages for and testing with F17? * Do we want to start automatically moving builds from jenkins to the nighly releases on ovirt.org? * Infrastructure status: ** Current situation ... ** Some plans to improve ... * Anything else? - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPcyKk2ZIOBq0ODEERAvvIAKDKxm3zBEi1rOyaknkBVu1XZqENCgCgyVKk kQNbZOwXc6Ns9CzRTV0M26s= =LWP7 -----END PGP SIGNATURE----- From ryanh at us.ibm.com Fri Mar 30 13:50:58 2012 From: ryanh at us.ibm.com (Ryan Harper) Date: Fri, 30 Mar 2012 08:50:58 -0500 Subject: ovirt bugzilla Message-ID: <20120330135058.GU31507@us.ibm.com> Just going through some of the various bits of code and in the man-page documents, we've got: Report bugs to Is the redhat bugzilla open enough to allow ovirt community folks to file bugs against the ovirt release there? or should we think about hosting a community bugzilla for the ovirt packages? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh at us.ibm.com From acathrow at redhat.com Fri Mar 30 13:59:46 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Fri, 30 Mar 2012 09:59:46 -0400 (EDT) Subject: ovirt bugzilla In-Reply-To: <20120330135058.GU31507@us.ibm.com> Message-ID: <900df1c8-4179-4ee3-bc1e-2ebdd64b28b8@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Ryan Harper" > To: arch at ovirt.org > Sent: Friday, March 30, 2012 9:50:58 AM > Subject: ovirt bugzilla > > Just going through some of the various bits of code and in the > man-page > documents, we've got: > > Report bugs to > > Is the redhat bugzilla open enough to allow ovirt community folks to > file bugs against the ovirt release there? or should we think about > hosting a community bugzilla for the ovirt packages? It's completely open. In bugzilla select "Community" then oVirt. > > > -- > Ryan Harper > Software Engineer; Linux Technology Center > IBM Corp., Austin, Tx > ryanh at us.ibm.com > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From kwade at redhat.com Fri Mar 30 14:41:39 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Fri, 30 Mar 2012 07:41:39 -0700 Subject: Meeting minutes, project sync :: 2012-03-28 Message-ID: <4F75C623.4050107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Logs are linked from and the next week's agenda is kept here: http://www.ovirt.org/wiki/Meetings Minutes: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-28-15.01.html Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-28-15.01.txt Log: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-28-15.01.log.html ============== #ovirt Meeting ============== Meeting started by quaid at 15:01:25 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-03-28-15.01.log.html . Meeting summary - --------------- * Roll call & greetings (quaid, 15:01:50) * Agenda review (quaid, 15:05:11) * LINK: http://ovirt.org/wiki/Meetings#Weekly_project_sync_meeting (quaid, 15:05:20) * LINK: https://fedoraproject.org/wiki/Features/oVirt (sgordon_, 15:07:55) * Release status check-in (quaid, 15:09:43) * Fedora 17 support, or do we mean Fedora 18? (quaid, 15:18:50) * LINK: http://ovirt.org/releases/nightly/fedora/17 (mburns, 15:19:34) * AGREED: make the Makefile and specfile better (quaid, 15:27:49) * ACTION: oschreib and sgordon to review spec and Makefile (oschreib, 15:28:15) * Need to get SRPMs building in mock so we can get in to Fedora (quaid, 15:28:16) * LINK: http://koji.fedoraproject.org/koji/packageinfo?packageID=12944 (sgordon_, 15:29:55) * ACTION: Fedora feature page owner needs to update the feature page to current reality (quaid, 15:30:31) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=807017 (oschreib, 15:31:37) * Infrastructure status (quaid, 15:36:06) * people interested in contributing to ovirt by helping with infra, send email to infra at ovirt.org (mburns, 15:42:50) * people interested in helping run meetings, send email to infra at ovirt.org (mburns, 15:43:11) * automatically update nightly releases from jenkins (mburns, 15:45:28) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=807761 (sgordon_, 15:56:39) * ACTION: oschreib eedri mburns to discuss automatically moving jenkins built rpms to nightly releases directory on ovirt.org (mburns, 15:58:36) * other topics (mburns, 16:01:40) Meeting ended at 16:03:08 UTC. Action Items - ------------ * oschreib and sgordon to review spec and Makefile * Fedora feature page owner needs to update the feature page to current reality * oschreib eedri mburns to discuss automatically moving jenkins built rpms to nightly releases directory on ovirt.org Action Items, by person - ----------------------- * eedri * oschreib eedri mburns to discuss automatically moving jenkins built rpms to nightly releases directory on ovirt.org * mburns * oschreib eedri mburns to discuss automatically moving jenkins built rpms to nightly releases directory on ovirt.org * oschreib * oschreib and sgordon to review spec and Makefile * oschreib eedri mburns to discuss automatically moving jenkins built rpms to nightly releases directory on ovirt.org * **UNASSIGNED** * Fedora feature page owner needs to update the feature page to current reality People Present (lines said) - --------------------------- * mburns (91) * quaid (61) * oschreib (57) * sgordon_ (31) * eedri (13) * ovirtbot (4) * itxx (1) * aglitke (1) * cctrieloff (1) * fabiand (1) * mgoldboi (1) - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPdcYi2ZIOBq0ODEERAgqzAJ0aQ+QUzOe0vG071axHR30WaKwhOACg0X9+ 8zysy0w/INl4hhkOLE66p8g= =yjsc -----END PGP SIGNATURE----- From juan.hernandez at redhat.com Sat Mar 31 19:43:50 2012 From: juan.hernandez at redhat.com (Juan Hernandez) Date: Sat, 31 Mar 2012 21:43:50 +0200 Subject: Updates for the Fedora feature page Message-ID: <4F775E76.20403@redhat.com> Hello, It has been discussed and agreed in the latest sync meeting that the Fedora feature page needs to be updated. I would greatly appreciate your input on what needs to be improved, specially regarding ovirt-engine. Thanks in advance, Juan Hernandez