[Users] Agents for Windows
I've been able to find prebuilt virt-io drivers and spice agents for Windows. Are there any repositories for prebuilt qemu-agent and ovirt agents for Windows?
On 12/02/2013 09:15 PM, Blaster wrote:
I've been able to find prebuilt virt-io drivers and spice agents for Windows. Are there any repositories for prebuilt qemu-agent and ovirt agents for Windows?
Unfortunately no.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On Dec 3, 2013, at 10:55 , Vinzenz Feenstra <vfeenstr@redhat.com> wrote:
On 12/02/2013 09:15 PM, Blaster wrote:
I've been able to find prebuilt virt-io drivers and spice agents for Windows. Are there any repositories for prebuilt qemu-agent and ovirt agents for Windows?
Unfortunately no.
we're just lacking the capacity. If someone can put it together there's no problem to host it at ovirt.org Thanks, michal
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Regards,
Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 12/3/2013 7:18 AM, Michal Skrivanek wrote:
On Dec 3, 2013, at 10:55 , Vinzenz Feenstra <vfeenstr@redhat.com> wrote:
On 12/02/2013 09:15 PM, Blaster wrote:
I've been able to find prebuilt virt-io drivers and spice agents for Windows. Are there any repositories for prebuilt qemu-agent and ovirt agents for Windows? Unfortunately no. we're just lacking the capacity. If someone can put it together there's no problem to host it at ovirt.org
Thanks, michal
I guess I'm confused as to how Red Hat can be making statements that Ovirt is a viable alternative to ESXi when many simple things that ESXi users take for granted simply don't work or are non-existent under Ovirt. I'm hardly a power user of ESXi, and I've only begun my Ovirt journey, but I've already come across the following: 1) No easy way to use an NFS share of ISOs to boot VMs with. Have to create a data domain and custom build a symlink tree. 2) No way to take an existing VM disk image and "add to inventory". You have to go through a process of importing it into a data domain. This makes it very complex to pop a disk out of chassis and move the VMs to a new hypervisor and go. Also makes DR more complex. 3) No way to make a backup of a guest using snapshots because you apparently can't delete the snap shots after you create them. (Must have been the same engineers who wrote ZFS and never imagined anyone would want to shrink a ZFS filesystem...) 4) There appears to be little or no documention on what you need to do to prep an Ovirt guest.. I still am not sure, and I've spent hours on Google trying to put it together... Looks like you need a) virt-IO drivers b) Spice drivers c) qemu-agent drivers which you must create your own build environment and build yourself d) ovirt-agent drivers which you must create your own build environment and build yourself e) have I missed anything? Under ESXi it's right click, install. done.
On 12/3/2013 7:18 AM, Michal Skrivanek wrote:
On Dec 3, 2013, at 10:55 , Vinzenz Feenstra <vfeenstr@redhat.com> wrote:
I've been able to find prebuilt virt-io drivers and spice agents for Windows. Are there any repositories for prebuilt qemu-agent and ovirt agents for Windows? Unfortunately no. we're just lacking the capacity. If someone can put it together
On 12/02/2013 09:15 PM, Blaster wrote: there's no problem to host it at ovirt.org
Thanks, michal
I guess I'm confused as to how Red Hat can be making statements that Ovirt is a viable alternative to ESXi when many simple things that ESXi users take for granted simply don't work or are non-existent under Ovirt. I'm hardly a power user of ESXi, and I've only begun my Ovirt journey, but I've already come across the following:
1) No easy way to use an NFS share of ISOs to boot VMs with. Have to create a data domain and custom build a symlink tree. 2) No way to take an existing VM disk image and "add to inventory". You have to go through a process of importing it into a data domain. This makes it very complex to pop a disk out of chassis and move the VMs to a new hypervisor and go. Also makes DR more complex. 3) No way to make a backup of a guest using snapshots because you apparently can't delete the snap shots after you create them. (Must have been the same engineers who wrote ZFS and never imagined anyone would want to shrink a ZFS filesystem...) 4) There appears to be little or no documention on what you need to do to prep an Ovirt guest.. I still am not sure, and I've spent hours on Google trying to put it together... Looks like you need a) virt-IO drivers b) Spice drivers c) qemu-agent drivers which you must create your own build environment and build yourself d) ovirt-agent drivers which you must create your own build environment and build yourself e) have I missed anything? Under ESXi it's right click, install. done. I understand that you're disappointed and we're trying to make our best to make the user experience better. You should be considering the age of
On 12/06/2013 05:33 AM, Blaster wrote: the project and what we're actually already providing. Yes not everything is perfect, but we're working hard on improving it. We're working in a collaborative way together with the community, if you're missing something, there's always the possibility to help out. Even if you're not a programmer you can help improving the experience. For example in your case to document point 4 in the wiki so that it's easier to find this information. For points 1-3 I would simply suggest that you can make a feature requests and describe how you would imagine this could work. We're pretty open to suggestions. Another thing having to say about your point 4 is that you're basing your experience solely on Windows guests, which are a bit more troublesome to support the same way we do for example Linux guests. First of all the oVirt project would need licenses for Windows to build those binaries at the moment. However there are plans providing pre-built guest agents for oVirt, however this is currently slowly moving on and any help in that regard, of setting up a viable, preferably cross-platform build environment, is of course welcome. Once we have builds for windows, we might be able to publish an ISO which can be attached to windows VMs and run autostart for the installation. However I wouldn't expect this to be happening too soon, though.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 12/06/2013 06:25 AM, Vinzenz Feenstra wrote:
On 12/06/2013 05:33 AM, Blaster wrote:
I guess I'm confused as to how Red Hat can be making statements that Ovirt is a viable alternative to ESXi when many simple things that ESXi users take for granted simply don't work or are non-existent under Ovirt. I'm hardly a power user of ESXi, and I've only begun my Ovirt journey, but I've already come across the following: ... I understand that you're disappointed and we're trying to make our best to make the user experience better. You should be considering the age of the project and what we're actually already providing. Yes not everything is perfect, but we're working hard on improving it.
True but you'll note that Blaster's overall comments were about Red Hat's marketing of this project as a solution, given it's status. I agree that it's a bit premature. oVirt is maturing quickly, but it still has a ways to go. It will get there, as you point out, and of course driving demand by a little over-enthusiastic marketing may actually accelerate that process, which may be a goal (Machiavelli would approve :). It will also frustrate some users, unfortunately.
Another thing having to say about your point 4 is that you're basing your experience solely on Windows guests, which are a bit more troublesome to support the same way we do for example Linux guests.
Here I disagree. My experience is the opposite. You can get almost everything (that I care about anyway) for Windows by installing spice-guest-tools (once you find it - there are few clues on the oVirt Wiki). This includes drivers, better mouse/display handling, and copy/paste. It does not seem however to include communication of the IP address (nor, I suspect, clean shutdown handling). It's on Linux where you have to piece together more things, and in fact have to build some things (e.g. vdagent) from source. Once https://bugzilla.redhat.com/show_bug.cgi?id=1026933 is fixed (currently slated for 3.3.3 :( ), and assuming that a VFD will be included and not just an ISO, the experience will be much simpler for Windows than for Linux for those pieces. If we were to build vdagent for Linux and make the RPMs for it and the Linux Guest Agent available in an easy way (incorporate them into an ISO and pre-populate ISO_DOMAIN with it?) that would be a big step forward for Linux guests. It's possible that you'd have to build vdagent from source, using some kind of automated build/install script on the ISO, to make it work for a variety of Linux distros. That's effectively what VMware has done. When building from source I find resolving the dependencies to be a big headache, particularly on Fedora. -Bob
On 12/06/2013 09:14 PM, Bob Doolittle wrote:
On 12/06/2013 06:25 AM, Vinzenz Feenstra wrote:
On 12/06/2013 05:33 AM, Blaster wrote:
I guess I'm confused as to how Red Hat can be making statements that Ovirt is a viable alternative to ESXi when many simple things that ESXi users take for granted simply don't work or are non-existent under Ovirt. I'm hardly a power user of ESXi, and I've only begun my Ovirt journey, but I've already come across the following: ... I understand that you're disappointed and we're trying to make our best to make the user experience better. You should be considering the age of the project and what we're actually already providing. Yes not everything is perfect, but we're working hard on improving it.
True but you'll note that Blaster's overall comments were about Red Hat's marketing of this project as a solution, given it's status. I agree that it's a bit premature. oVirt is maturing quickly, but it still has a ways to go. It will get there, as you point out, and of course driving demand by a little over-enthusiastic marketing may actually accelerate that process, which may be a goal (Machiavelli would approve :). It will also frustrate some users, unfortunately.
Another thing having to say about your point 4 is that you're basing your experience solely on Windows guests, which are a bit more troublesome to support the same way we do for example Linux guests.
Here I disagree. My experience is the opposite. You can get almost everything (that I care about anyway) for Windows by installing spice-guest-tools (once you find it - there are few clues on the oVirt Wiki). This includes drivers, better mouse/display handling, and copy/paste. It does not seem however to include communication of the IP address (nor, I suspect, clean shutdown handling).
My point was about providing our own binaries for the oVirt guest agent. We have not yet solved targeting Windows for the guest agent binaries for oVirt. My bad that it wasn't explicit enough.
It's on Linux where you have to piece together more things, and in fact have to build some things (e.g. vdagent) from source.
Once https://bugzilla.redhat.com/show_bug.cgi?id=1026933 is fixed (currently slated for 3.3.3 :( ), and assuming that a VFD will be included and not just an ISO, the experience will be much simpler for Windows than for Linux for those pieces.
If we were to build vdagent for Linux and make the RPMs for it and the Linux Guest Agent available in an easy way (incorporate them into an ISO and pre-populate ISO_DOMAIN with it?) that would be a big step forward for Linux guests. It's possible that you'd have to build vdagent from source, using some kind of automated build/install script on the ISO, to make it work for a variety of Linux distros. That's effectively what VMware has done. When building from source I find resolving the dependencies to be a big headache, particularly on Fedora.
Well on fedora it would be as easy as yum install spice-vdagent, no headaches here from my point of view. However requiring all the devel packages just to install the agent on the target platform from sources is a bit overkill in my opinion. On linux we rather should go with the default packaging ways. That's what we're working on at the moment as well. We have already built packages for Fedora, distributions using EPEL (e.g. CentOS), OpenSUSE and Ubuntu. Upcoming targets are SLES and Debian. So for those it would be doable without having to build from sources. However besides Fedora and EPEL we don't have yet reached inclusion into the repositories for those packages, for Ubuntu it's on launchpad and for OpenSuSE on their open build infrastructure. As I said eventually we'll get there that we'll provide binaries for that.
-Bob
-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
--Apple-Mail=_226A0167-F20F-4CB7-A36B-CB780B00784B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 6, 2013, at 5:25 AM, Vinzenz Feenstra <vfeenstr@redhat.com> = wrote:
I understand that you're disappointed and we're trying to make our = best to make the user experience better. You should be considering the = age of the project and what we're actually already providing. Yes not = everything is perfect, but we're working hard on improving it. We're working in a collaborative way together with the community, if = you're missing something, there's always the possibility to help out. = Even if you're not a programmer you can help improving the experience.
Bob pretty much said it all for me already=85I=92m not so much as = disappointed in ovirt development as I am the marketing of it. ovirt is = being marketed as an ESXi replacement when it surely isn=92t. Probably = 90%+ of what ESXi is used for is virtualizing Windows. Give ovirt in = it=92s current form to a typical Windows user and they=92ll self = destruct. The first issue with the agents as I can=92t even find any documentation = on what agents really need installing, and what features I=92m getting = with that agent! Another thing is, I would think that Fedora would be integrated enough = with ovirt that it would be able to automatically detect it=92s running = on ovirt and install all the required agents automatically. I forgot my number 5) BIOS needs to work like a standard PC BIOS (as = does ESXi) in allowing you to press F8 to get a boot menu or F12 for = network boot. This run once stuff is silly. It works fine the first = time I create a VM as there=92s no bootable OS on the datastore, but if = I need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when = the PXE completes it reboots, back into network boot, then I have to = kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I just = hit F12, network boot, OS re-installs, then reboots normally. Much = better user experience. I gave our Red Hat sales people feedback on = this issue and was told it=92s not going to change.=20= --Apple-Mail=_226A0167-F20F-4CB7-A36B-CB780B00784B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;"><br><div><div>On Dec 6, 2013, at 5:25 AM, Vinzenz = Feenstra <<a = href=3D"mailto:vfeenstr@redhat.com">vfeenstr@redhat.com</a>> = wrote:</div><br><blockquote type=3D"cite"><div style=3D"font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I = understand that you're disappointed and we're trying to make our best to = make the user experience better. You should be considering the age of = the project and what we're actually already providing. Yes not = everything is perfect, but we're working hard on improving it.<br>We're = working in a collaborative way together with the community, if you're = missing something, there's always the possibility to help out. Even if = you're not a programmer you can help improving the = experience.<br></div></blockquote><div><br></div><div>Bob pretty much = said it all for me already=85I=92m not so much as disappointed in ovirt = development as I am the marketing of it. ovirt is being marketed = as an ESXi replacement when it surely isn=92t. Probably 90%+ of = what ESXi is used for is virtualizing Windows. Give ovirt in it=92s = current form to a typical Windows user and they=92ll self = destruct.</div><div><br></div><div>The first issue with the agents as I = can=92t even find any documentation on what agents really need = installing, and what features I=92m getting with that = agent!</div><div><br></div><div>Another thing is, I would think that = Fedora would be integrated enough with ovirt that it would be able to = automatically detect it=92s running on ovirt and install all the = required agents automatically.</div><div><br></div><div>I forgot my = number 5) BIOS needs to work like a standard PC BIOS (as does = ESXi) in allowing you to press F8 to get a boot menu or F12 for network = boot. This run once stuff is silly. It works fine the first = time I create a VM as there=92s no bootable OS on the datastore, but if = I need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when = the PXE completes it reboots, back into network boot, then I have to = kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I = just hit F12, network boot, OS re-installs, then reboots normally. = Much better user experience. I gave our Red Hat sales = people feedback on this issue and was told it=92s not going to = change. </div></div></body></html>= --Apple-Mail=_226A0167-F20F-4CB7-A36B-CB780B00784B--
On 12/09/2013 04:42 PM, Blaster wrote:
On Dec 6, 2013, at 5:25 AM, Vinzenz Feenstra <vfeenstr@redhat.com <mailto:vfeenstr@redhat.com>> wrote:
I understand that you're disappointed and we're trying to make our best to make the user experience better. You should be considering the age of the project and what we're actually already providing. Yes not everything is perfect, but we're working hard on improving it. We're working in a collaborative way together with the community, if you're missing something, there's always the possibility to help out. Even if you're not a programmer you can help improving the experience.
Bob pretty much said it all for me already…I’m not so much as disappointed in ovirt development as I am the marketing of it. ovirt is being marketed as an ESXi replacement when it surely isn’t. Probably 90%+ of what ESXi is used for is virtualizing Windows. Give ovirt in it’s current form to a typical Windows user and they’ll self destruct.
The first issue with the agents as I can’t even find any documentation on what agents really need installing, and what features I’m getting with that agent!
Another thing is, I would think that Fedora would be integrated enough with ovirt that it would be able to automatically detect it’s running on ovirt and install all the required agents automatically.
I forgot my number 5) BIOS needs to work like a standard PC BIOS (as does ESXi) in allowing you to press F8 to get a boot menu or F12 for network boot. This run once stuff is silly. It works fine the first time I create a VM as there’s no bootable OS on the datastore, but if I need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when the PXE completes it reboots, back into network boot, then I have to kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I just hit F12, network boot, OS re-installs, then reboots normally. Much better user experience. I gave our Red Hat sales people feedback on this issue and was told it’s not going to change.
if you open a support ticket for this request, it will be associated with an RFE, helping its priority (which is via support, not sales, but we can take that offline i guess). iirc, the problem on this one is not supported by qemu or libvirt, so we'd need vdsm manage the restart as a shutdown (which libvirt supports), then start the VM again without the ISO. I'm trying to remember if this was supposed to be resolved by qemu supporting this or the vdsm logic. michal?
--Apple-Mail-8E43816A-1FFE-497E-A97C-57A274873F50 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQoNCj4+IE9uIDA5IERlYyAyMDEzLCBhdCAyMDo1NiwgSXRhbWFyIEhlaW0gPGloZWltQHJlZGhh dC5jb20+IHdyb3RlOg0KPj4gDQo+PiBPbiAxMi8wOS8yMDEzIDA0OjQyIFBNLCBCbGFzdGVyIHdy b3RlOg0KPj4gDQo+PiBPbiBEZWMgNiwgMjAxMywgYXQgNToyNSBBTSwgVmluemVueiBGZWVuc3Ry YSA8dmZlZW5zdHJAcmVkaGF0LmNvbQ0KPj4gPG1haWx0bzp2ZmVlbnN0ckByZWRoYXQuY29tPj4g d3JvdGU6DQo+PiANCj4+PiBJIHVuZGVyc3RhbmQgdGhhdCB5b3UncmUgZGlzYXBwb2ludGVkIGFu ZCB3ZSdyZSB0cnlpbmcgdG8gbWFrZSBvdXINCj4+PiBiZXN0IHRvIG1ha2UgdGhlIHVzZXIgZXhw ZXJpZW5jZSBiZXR0ZXIuIFlvdSBzaG91bGQgYmUgY29uc2lkZXJpbmcgdGhlDQo+Pj4gYWdlIG9m IHRoZSBwcm9qZWN0IGFuZCB3aGF0IHdlJ3JlIGFjdHVhbGx5IGFscmVhZHkgcHJvdmlkaW5nLiBZ ZXMgbm90DQo+Pj4gZXZlcnl0aGluZyBpcyBwZXJmZWN0LCBidXQgd2UncmUgd29ya2luZyBoYXJk IG9uIGltcHJvdmluZyBpdC4NCj4+PiBXZSdyZSB3b3JraW5nIGluIGEgY29sbGFib3JhdGl2ZSB3 YXkgdG9nZXRoZXIgd2l0aCB0aGUgY29tbXVuaXR5LCBpZg0KPj4+IHlvdSdyZSBtaXNzaW5nIHNv bWV0aGluZywgdGhlcmUncyBhbHdheXMgdGhlIHBvc3NpYmlsaXR5IHRvIGhlbHAgb3V0Lg0KPj4+ IEV2ZW4gaWYgeW91J3JlIG5vdCBhIHByb2dyYW1tZXIgeW91IGNhbiBoZWxwIGltcHJvdmluZyB0 aGUgZXhwZXJpZW5jZS4NCj4+IA0KPj4gQm9iIHByZXR0eSBtdWNoIHNhaWQgaXQgYWxsIGZvciBt ZSBhbHJlYWR54oCmSeKAmW0gbm90IHNvIG11Y2ggYXMNCj4+IGRpc2FwcG9pbnRlZCBpbiBvdmly dCBkZXZlbG9wbWVudCBhcyBJIGFtIHRoZSBtYXJrZXRpbmcgb2YgaXQuICBvdmlydCBpcw0KPj4g YmVpbmcgbWFya2V0ZWQgYXMgYW4gRVNYaSByZXBsYWNlbWVudCB3aGVuIGl0IHN1cmVseSBpc27i gJl0LiAgUHJvYmFibHkNCj4+IDkwJSsgb2Ygd2hhdCBFU1hpIGlzIHVzZWQgZm9yIGlzIHZpcnR1 YWxpemluZyBXaW5kb3dzLiAgR2l2ZSBvdmlydCBpbg0KPj4gaXTigJlzIGN1cnJlbnQgZm9ybSB0 byBhIHR5cGljYWwgV2luZG93cyB1c2VyIGFuZCB0aGV54oCZbGwgc2VsZiBkZXN0cnVjdC4NCj4+ IA0KPj4gVGhlIGZpcnN0IGlzc3VlIHdpdGggdGhlIGFnZW50cyBhcyBJIGNhbuKAmXQgZXZlbiBm aW5kIGFueSBkb2N1bWVudGF0aW9uDQo+PiBvbiB3aGF0IGFnZW50cyByZWFsbHkgbmVlZCBpbnN0 YWxsaW5nLCBhbmQgd2hhdCBmZWF0dXJlcyBJ4oCZbSBnZXR0aW5nDQo+PiB3aXRoIHRoYXQgYWdl bnQhDQoNCkNoZWNrIG91dCB0aGUgbmV3IHBhZ2UgYnkgTmljaG9sYXMgS2VzaWNrIFsxXQ0KDQo+ PiANCj4+IEFub3RoZXIgdGhpbmcgaXMsIEkgd291bGQgdGhpbmsgdGhhdCBGZWRvcmEgd291bGQg YmUgaW50ZWdyYXRlZCBlbm91Z2gNCj4+IHdpdGggb3ZpcnQgdGhhdCBpdCB3b3VsZCBiZSBhYmxl IHRvIGF1dG9tYXRpY2FsbHkgZGV0ZWN0IGl04oCZcyBydW5uaW5nIG9uDQo+PiBvdmlydCBhbmQg aW5zdGFsbCBhbGwgdGhlIHJlcXVpcmVkIGFnZW50cyBhdXRvbWF0aWNhbGx5Lg0KPj4gDQo+PiBJ IGZvcmdvdCBteSBudW1iZXIgNSkgIEJJT1MgbmVlZHMgdG8gd29yayBsaWtlIGEgc3RhbmRhcmQg UEMgQklPUyAoYXMNCj4+IGRvZXMgRVNYaSkgaW4gYWxsb3dpbmcgeW91IHRvIHByZXNzIEY4IHRv IGdldCBhIGJvb3QgbWVudSBvciBGMTIgZm9yDQo+PiBuZXR3b3JrIGJvb3QuICANCg0KU2VhYmlv cyBoYXMgYm9vdCBtZW51IHN1cHBvcnQgb24gRjEyLiBJIGRvbid0IHJlY2FsbCBpZiB3ZSBzcGVj aWZpY2FsbHkgZGlzYWJsZSBpdCwgSSB0aGluayBub3QNCg0KPj4gVGhpcyBydW4gb25jZSBzdHVm ZiBpcyBzaWxseS4gIEl0IHdvcmtzIGZpbmUgdGhlIGZpcnN0DQo+PiB0aW1lIEkgY3JlYXRlIGEg Vk0gYXMgdGhlcmXigJlzIG5vIGJvb3RhYmxlIE9TIG9uIHRoZSBkYXRhc3RvcmUsIGJ1dCBpZiBJ DQo+PiBuZWVkIHRvIHJlLVBYRSBib290IGEgVk0sIHRoZW4gSSBoYXZlIHRvIFJ1biBPbmNlLi5P SywgZmluZSwgYnV0IHdoZW4NCj4+IHRoZSBQWEUgY29tcGxldGVzIGl0IHJlYm9vdHMsIGJhY2sg aW50byBuZXR3b3JrIGJvb3QsIHRoZW4gSSBoYXZlIHRvDQo+PiBraWxsIHRoZSBWTSBhbmQgcmVz dGFydCBpdCBub3JtYWxseS4gIFVuZGVyIGEgUEMgKG9yIEVTWGkpIEJJT1MsIEkganVzdA0KPj4g aGl0IEYxMiwgbmV0d29yayBib290LCBPUyByZS1pbnN0YWxscywgdGhlbiAgcmVib290cyBub3Jt YWxseS4gIE11Y2gNCj4+IGJldHRlciB1c2VyIGV4cGVyaWVuY2UuICAgSSBnYXZlIG91ciBSZWQg SGF0IHNhbGVzIHBlb3BsZSBmZWVkYmFjayBvbg0KPj4gdGhpcyBpc3N1ZSBhbmQgd2FzIHRvbGQg aXTigJlzIG5vdCBnb2luZyB0byBjaGFuZ2UuDQo+IA0KPiBpZiB5b3Ugb3BlbiBhIHN1cHBvcnQg dGlja2V0IGZvciB0aGlzIHJlcXVlc3QsIGl0IHdpbGwgYmUgYXNzb2NpYXRlZCB3aXRoIGFuIFJG RSwgaGVscGluZyBpdHMgcHJpb3JpdHkgKHdoaWNoIGlzIHZpYSBzdXBwb3J0LCBub3Qgc2FsZXMs IGJ1dCB3ZSBjYW4gdGFrZSB0aGF0IG9mZmxpbmUgaSBndWVzcykuDQo+IA0KPiBpaXJjLCB0aGUg cHJvYmxlbSBvbiB0aGlzIG9uZSBpcyBub3Qgc3VwcG9ydGVkIGJ5IHFlbXUgb3IgbGlidmlydCwg c28gd2UnZCBuZWVkIHZkc20gbWFuYWdlIHRoZSByZXN0YXJ0IGFzIGEgc2h1dGRvd24gKHdoaWNo IGxpYnZpcnQgc3VwcG9ydHMpLCB0aGVuIHN0YXJ0IHRoZSBWTSBhZ2FpbiB3aXRob3V0IHRoZSBJ U08uDQo+IA0KPiBJJ20gdHJ5aW5nIHRvIHJlbWVtYmVyIGlmIHRoaXMgd2FzIHN1cHBvc2VkIHRv IGJlIHJlc29sdmVkIGJ5IHFlbXUgc3VwcG9ydGluZyB0aGlzIG9yIHRoZSB2ZHNtIGxvZ2ljLg0K PiBtaWNoYWw/DQoNCkJ5IGVuZ2luZSt2ZHNtIGxvZ2ljLiBQYXRjaGVzIGJ5IE1hcnRpbiBCZXRh ayBhcmUgc3RpbGwgc3R1Y2sgb24gdmRzbS4gSXQgd29uJ3QgaGVscCB3aXRoIHRoZSBhYm92ZSBp ZiB0aGUgcmVib290IGlzIHRyaWdnZXJlZCBmcm9tIHdpdGhpbiB0aGUgZ3Vlc3Qgd2UgZG9uJ3Qg cGxhbiB0byByZWNyZWF0ZSB0aGUgVk0gb24gZW5naW5lLiBUaGUgVUkgcmVib290IGJ1dHRvbiB3 b3VsZCwgYnV0IElJVUMgdGhhdCdzIG5vdCB0aGUgc2FtZSBjYXNlDQoNClsxXSBodHRwOi8vd3d3 Lm92aXJ0Lm9yZy9VbmRlcnN0YW5kaW5nX0d1ZXN0X0FnZW50c19hbmRfT3RoZXJfVG9vbHM= --Apple-Mail-8E43816A-1FFE-497E-A97C-57A274873F50 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PHNwYW4+ PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9uIDA5IERl YyAyMDEzLCBhdCAyMDo1NiwgSXRhbWFyIEhlaW0gJmx0OzxhIGhyZWY9Im1haWx0bzppaGVpbUBy ZWRoYXQuY29tIj5paGVpbUByZWRoYXQuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5PbiAx Mi8wOS8yMDEzIDA0OjQyIFBNLCBCbGFzdGVyIHdyb3RlOjwvc3Bhbj48YnI+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+T24gRGVjIDYsIDIw MTMsIGF0IDU6MjUgQU0sIFZpbnplbnogRmVlbnN0cmEgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZmVl bnN0ckByZWRoYXQuY29tIj52ZmVlbnN0ckByZWRoYXQuY29tPC9hPjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48c3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnZmZWVuc3RyQHJlZGhhdC5jb20i Pm1haWx0bzp2ZmVlbnN0ckByZWRoYXQuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SSB1bmRlcnN0YW5kIHRoYXQgeW91J3JlIGRpc2FwcG9p bnRlZCBhbmQgd2UncmUgdHJ5aW5nIHRvIG1ha2Ugb3VyPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5iZXN0IHRvIG1h a2UgdGhlIHVzZXIgZXhwZXJpZW5jZSBiZXR0ZXIuIFlvdSBzaG91bGQgYmUgY29uc2lkZXJpbmcg dGhlPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48c3Bhbj5hZ2Ugb2YgdGhlIHByb2plY3QgYW5kIHdoYXQgd2UncmUgYWN0dWFs bHkgYWxyZWFkeSBwcm92aWRpbmcuIFllcyBub3Q8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmV2ZXJ5dGhpbmcgaXMg cGVyZmVjdCwgYnV0IHdlJ3JlIHdvcmtpbmcgaGFyZCBvbiBpbXByb3ZpbmcgaXQuPC9zcGFuPjxi cj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj5XZSdyZSB3b3JraW5nIGluIGEgY29sbGFib3JhdGl2ZSB3YXkgdG9nZXRoZXIgd2l0aCB0 aGUgY29tbXVuaXR5LCBpZjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+eW91J3JlIG1pc3Npbmcgc29tZXRoaW5nLCB0 aGVyZSdzIGFsd2F5cyB0aGUgcG9zc2liaWxpdHkgdG8gaGVscCBvdXQuPC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5F dmVuIGlmIHlvdSdyZSBub3QgYSBwcm9ncmFtbWVyIHlvdSBjYW4gaGVscCBpbXByb3ZpbmcgdGhl IGV4cGVyaWVuY2UuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh bj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Qm9iIHByZXR0eSBtdWNoIHNhaWQg aXQgYWxsIGZvciBtZSBhbHJlYWR54oCmSeKAmW0gbm90IHNvIG11Y2ggYXM8L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+ZGlzYXBwb2ludGVkIGluIG92aXJ0IGRldmVsb3BtZW50IGFz IEkgYW0gdGhlIG1hcmtldGluZyBvZiBpdC4gJm5ic3A7b3ZpcnQgaXM8L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+YmVpbmcgbWFya2V0ZWQgYXMgYW4gRVNYaSByZXBsYWNlbWVudCB3 aGVuIGl0IHN1cmVseSBpc27igJl0LiAmbmJzcDtQcm9iYWJseTwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj45MCUrIG9mIHdoYXQgRVNYaSBpcyB1c2VkIGZvciBpcyB2aXJ0dWFsaXpp bmcgV2luZG93cy4gJm5ic3A7R2l2ZSBvdmlydCBpbjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj5pdOKAmXMgY3VycmVudCBmb3JtIHRvIGEgdHlwaWNhbCBXaW5kb3dzIHVzZXIgYW5k IHRoZXnigJlsbCBzZWxmIGRlc3RydWN0Ljwvc3Bhbj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwv c3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGUgZmlyc3QgaXNzdWUgd2l0aCB0aGUg YWdlbnRzIGFzIEkgY2Fu4oCZdCBldmVuIGZpbmQgYW55IGRvY3VtZW50YXRpb248L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+b24gd2hhdCBhZ2VudHMgcmVhbGx5IG5lZWQgaW5zdGFs bGluZywgYW5kIHdoYXQgZmVhdHVyZXMgSeKAmW0gZ2V0dGluZzwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj53aXRoIHRoYXQgYWdlbnQhPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9i bG9ja3F1b3RlPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+Q2hlY2sgb3V0IHRoZSBuZXcgcGFnZSBi eSBOaWNob2xhcyBLZXNpY2sgWzFdPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48c3Bhbj5Bbm90aGVyIHRoaW5nIGlzLCBJIHdvdWxkIHRoaW5rIHRoYXQgRmVk b3JhIHdvdWxkIGJlIGludGVncmF0ZWQgZW5vdWdoPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPndpdGggb3ZpcnQgdGhhdCBpdCB3b3VsZCBiZSBhYmxlIHRvIGF1dG9tYXRpY2FsbHkg ZGV0ZWN0IGl04oCZcyBydW5uaW5nIG9uPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1 b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFu Pm92aXJ0IGFuZCBpbnN0YWxsIGFsbCB0aGUgcmVxdWlyZWQgYWdlbnRzIGF1dG9tYXRpY2FsbHku PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48c3Bhbj5JIGZvcmdvdCBteSBudW1iZXIgNSkgJm5ic3A7QklPUyBuZWVkcyB0byB3b3Jr IGxpa2UgYSBzdGFuZGFyZCBQQyBCSU9TIChhczwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj5kb2VzIEVTWGkpIGluIGFsbG93aW5nIHlvdSB0byBwcmVzcyBGOCB0byBnZXQgYSBib290 IG1lbnUgb3IgRjEyIGZvcjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5uZXR3b3Jr IGJvb3QuICZuYnNwOzwvc3Bhbj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv ZGl2PlNlYWJpb3MgaGFzIGJvb3QgbWVudSBzdXBwb3J0IG9uIEYxMi4gSSBkb24ndCByZWNhbGwg aWYgd2Ugc3BlY2lmaWNhbGx5IGRpc2FibGUgaXQsIEkgdGhpbmsgbm90PC9kaXY+PGRpdj48YnI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+VGhp cyBydW4gb25jZSBzdHVmZiBpcyBzaWxseS4gJm5ic3A7SXQgd29ya3MgZmluZSB0aGUgZmlyc3Q8 L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+dGltZSBJIGNyZWF0ZSBhIFZNIGFzIHRo ZXJl4oCZcyBubyBib290YWJsZSBPUyBvbiB0aGUgZGF0YXN0b3JlLCBidXQgaWYgSTwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5uZWVkIHRvIHJlLVBYRSBib290IGEgVk0sIHRoZW4g SSBoYXZlIHRvIFJ1biBPbmNlLi5PSywgZmluZSwgYnV0IHdoZW48L3NwYW4+PGJyPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+dGhlIFBYRSBjb21wbGV0ZXMgaXQgcmVib290cywgYmFjayBpbnRvIG5l dHdvcmsgYm9vdCwgdGhlbiBJIGhhdmUgdG88L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+a2lsbCB0aGUgVk0gYW5kIHJlc3RhcnQgaXQgbm9ybWFsbHkuICZuYnNwO1VuZGVyIGEgUEMg KG9yIEVTWGkpIEJJT1MsIEkganVzdDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5o aXQgRjEyLCBuZXR3b3JrIGJvb3QsIE9TIHJlLWluc3RhbGxzLCB0aGVuICZuYnNwO3JlYm9vdHMg bm9ybWFsbHkuICZuYnNwO011Y2g8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+YmV0 dGVyIHVzZXIgZXhwZXJpZW5jZS4gJm5ic3A7Jm5ic3A7SSBnYXZlIG91ciBSZWQgSGF0IHNhbGVz IHBlb3BsZSBmZWVkYmFjayBvbjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj50aGlz IGlzc3VlIGFuZCB3YXMgdG9sZCBpdOKAmXMgbm90IGdvaW5nIHRvIGNoYW5nZS48L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+aWYg eW91IG9wZW4gYSBzdXBwb3J0IHRpY2tldCBmb3IgdGhpcyByZXF1ZXN0LCBpdCB3aWxsIGJlIGFz c29jaWF0ZWQgd2l0aCBhbiBSRkUsIGhlbHBpbmcgaXRzIHByaW9yaXR5ICh3aGljaCBpcyB2aWEg c3VwcG9ydCwgbm90IHNhbGVzLCBidXQgd2UgY2FuIHRha2UgdGhhdCBvZmZsaW5lIGkgZ3Vlc3Mp Ljwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwv c3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmlpcmMs IHRoZSBwcm9ibGVtIG9uIHRoaXMgb25lIGlzIG5vdCBzdXBwb3J0ZWQgYnkgcWVtdSBvciBsaWJ2 aXJ0LCBzbyB3ZSdkIG5lZWQgdmRzbSBtYW5hZ2UgdGhlIHJlc3RhcnQgYXMgYSBzaHV0ZG93biAo d2hpY2ggbGlidmlydCBzdXBwb3J0cyksIHRoZW4gc3RhcnQgdGhlIFZNIGFnYWluIHdpdGhvdXQg dGhlIElTTy48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh bj5JJ20gdHJ5aW5nIHRvIHJlbWVtYmVyIGlmIHRoaXMgd2FzIHN1cHBvc2VkIHRvIGJlIHJlc29s dmVkIGJ5IHFlbXUgc3VwcG9ydGluZyB0aGlzIG9yIHRoZSB2ZHNtIGxvZ2ljLjwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPm1pY2hhbD88L3NwYW4+ PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5CeSBlbmdpbmUrdmRzbSBsb2dpYy4gUGF0 Y2hlcyBieSBNYXJ0aW4gQmV0YWsgYXJlIHN0aWxsIHN0dWNrIG9uIHZkc20uIEl0IHdvbid0IGhl bHAgd2l0aCB0aGUgYWJvdmUgaWYgdGhlIHJlYm9vdCBpcyB0cmlnZ2VyZWQgZnJvbSB3aXRoaW4g dGhlIGd1ZXN0IHdlIGRvbid0IHBsYW4gdG8gcmVjcmVhdGUgdGhlIFZNIG9uIGVuZ2luZS4gVGhl IFVJIHJlYm9vdCBidXR0b24gd291bGQsIGJ1dCBJSVVDIHRoYXQncyBub3QgdGhlIHNhbWUgY2Fz ZTxicj48YnI+PC9kaXY+PGRpdj5bMV0mbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3Lm92aXJ0Lm9y Zy9VbmRlcnN0YW5kaW5nX0d1ZXN0X0FnZW50c19hbmRfT3RoZXJfVG9vbHMiPmh0dHA6Ly93d3cu b3ZpcnQub3JnL1VuZGVyc3RhbmRpbmdfR3Vlc3RfQWdlbnRzX2FuZF9PdGhlcl9Ub29sczwvYT48 L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-8E43816A-1FFE-497E-A97C-57A274873F50--
--Apple-Mail=_780023A3-C4E5-417C-B4D5-EA26F668C116 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 9, 2013, at 1:19 PM, Michal Skrivanek = <michal.skrivanek@redhat.com> wrote:
=20 Check out the new page by Nicholas Kesick [1]
Cool, thanks Nicholas! After reading the description, now I really want = to get ovirt agent for Windows built. Is there an index for all the documents on www.ovirt.org/cool_stuff? = Maybe I need new glasses, but the only way I come across those is in = Google searches if I get the keywords right. =20
=20 Seabios has boot menu support on F12. I don't recall if we = specifically disable it, I think not
> wrote:</div><blockquote type=3D"cite"><div dir=3D"auto" =
I will try to hit an F12 next time I boot to see if I get a menu, I = don=92t recall seeing any text on the screen that it=92s there. --Apple-Mail=_780023A3-C4E5-417C-B4D5-EA26F668C116 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;"><br><div><div>On Dec 9, 2013, at 1:19 PM, Michal = Skrivanek <<a = href=3D"mailto:michal.skrivanek@redhat.com">michal.skrivanek@redhat.com</a= style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: auto; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: auto; word-spacing: = 0px; -webkit-text-stroke-width: = 0px;"><div><span></span></div><div><span></span><span></span><br><span>Che= ck out the new page by Nicholas Kesick = [1]</span></div></div></blockquote><div><br></div><div>Cool, thanks = Nicholas! After reading the description, now I really want to get = ovirt agent for Windows built.</div><div><br></div><div>Is there an = index for all the documents on <a = href=3D"http://www.ovirt.org/cool_stuff?">www.ovirt.org/cool_stuff?</a> = Maybe I need new glasses, but the only way I come across those is = in Google searches if I get the keywords = right.</div><div> </div><blockquote type=3D"cite"><div = dir=3D"auto" style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: = 0px;"><div><div><br></div>Seabios has boot menu support on F12. I don't = recall if we specifically disable it, I think = not</div></div></blockquote><div><br></div><div>I will try to hit an F12 = next time I boot to see if I get a menu, I don=92t recall seeing any = text on the screen that it=92s = there.</div><div><br></div></div><br></body></html>= --Apple-Mail=_780023A3-C4E5-417C-B4D5-EA26F668C116--
On Dec 10, 2013, at 04:01 , Blaster <blaster@556nato.com> wrote:
On Dec 9, 2013, at 1:19 PM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Check out the new page by Nicholas Kesick [1]
Cool, thanks Nicholas! After reading the description, now I really want to get ovirt agent for Windows built.
Is there an index for all the documents on www.ovirt.org/cool_stuff? Maybe I need new glasses, but the only way I come across those is in Google searches if I get the keywords right.
As you may have noticed, it's a work in progress. It will likely be linked from the oVirt landing page, once everyone is fine with the content.
Seabios has boot menu support on F12. I don't recall if we specifically disable it, I think not
I will try to hit an F12 next time I boot to see if I get a menu, I don’t recall seeing any text on the screen that it’s there.
It may be too fast to actually give you the chance to open the console. There's "start in paused mode" option, but that's not really the same use case, not applicable to reboot. Oh, and it seems the QEMU default is that the menu is not available unless explicitly enabled. Don't have that option today, but should be relatively easy to add Thanks, michal
On Dec 10, 2013, at 08:43 , Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On Dec 10, 2013, at 04:01 , Blaster <blaster@556nato.com> wrote:
On Dec 9, 2013, at 1:19 PM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Check out the new page by Nicholas Kesick [1]
Cool, thanks Nicholas! After reading the description, now I really want to get ovirt agent for Windows built.
Is there an index for all the documents on www.ovirt.org/cool_stuff? Maybe I need new glasses, but the only way I come across those is in Google searches if I get the keywords right.
As you may have noticed, it's a work in progress. It will likely be linked from the oVirt landing page, once everyone is fine with the content.
Seabios has boot menu support on F12. I don't recall if we specifically disable it, I think not
I will try to hit an F12 next time I boot to see if I get a menu, I don’t recall seeing any text on the screen that it’s there.
It may be too fast to actually give you the chance to open the console. There's "start in paused mode" option, but that's not really the same use case, not applicable to reboot. Oh, and it seems the QEMU default is that the menu is not available unless explicitly enabled. Don't have that option today, but should be relatively easy to add
Or actually you can do that, just not in UI. Use qemucmdline vdsm hook on each host
Thanks, michal _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Tue, Dec 10, 2013 at 7:54 AM, Michal Skrivanek wrote:
Seabios has boot menu support on F12. I don't recall if we specifically disable it, I think not
I will try to hit an F12 next time I boot to see if I get a menu, I don’t recall seeing any text on the screen that it’s there.
It may be too fast to actually give you the chance to open the console. There's "start in paused mode" option, but that's not really the same use case, not applicable to reboot. Oh, and it seems the QEMU default is that the menu is not available unless explicitly enabled. Don't have that option today, but should be relatively easy to add
Or actually you can do that, just not in UI. Use qemucmdline vdsm hook on each host
Hello, I see that in Fedora 19 and virt-manager shipped with it there is indeed an option to enable boot menu. The generated qemu command line gives these options -boot order=d,menu=on is this the option to give? "order=d" should stand for cd-rom first... correct? Also I see that actually the delay between the moment you see the screen (in local environment) Press F12 for boot menu and the moment it starts the VM if you don't press anything, is about only 2 seconds.... so it could be not sufficient in some cases Can we use splash-time=xxx option, or would it give an error without a splash image? Also I see in man page for fedora 19 qemu (qemu-system-x86-1.4.2-14.fc19.x86_64) there is rb_timeout: A timeout could be passed to bios, guest will pause for rb_timeout ms when boot failed, then reboot. If rb_timeout is '-1', guest will not reboot, qemu passes '-1' to bios by default. Currently Seabios for X86 system support it. SO I presume this timeout is only applied after a first error to boot ... correct?
This is a multi-part message in MIME format. --------------060800050208070800010102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit From RHEL 6.5 release notes... Windows Guest Agent Fully Supported The Windows guest agent is now fully supported and delivered with its own installer in the Supplementary channel together with virtio-win drivers. [...] Application-Aware|freeze|and|thaw|on Microsoft Windows with VSS Support on*qemu-ga-win* VSS (Volume Shadow Copy Service) is a Microsoft Windows API that allows, among other things, the notification of applications for proper, consistent freeze and thaw operations. With this feature, snapshots taken while the virtual machine is running are consistent through the whole stack (from the block layer to the guest applications) and can be used for backup purposes. For more information, see theVirtualization Administration Guide <https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sub-sect-qemu-ga-freeze-thaw.html> Is there any issue with using these drivers with OVIRT? (since ovirt is upstream of RHEV, it should work, right?) I know, the answer will be no... --------------060800050208070800010102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">From RHEL 6.5 release notes...<br> <br> <h3 style="background-color: rgb(255, 255, 255); font-size: 1.17em; border: 0px; margin: 1em 0px 0.4em; padding: 0px; vertical-align: baseline; color: rgb(167, 0, 0); font-family: 'liberation sans', 'Myriad ', 'Bitstream Vera Sans', 'Lucida Grande', 'Luxi Sans', 'Trebuchet MS', helvetica, verdana, arial, sans-serif; font-weight: bold; line-height: 18px; widows: 4; orphans: 4; font-style: normal; font-variant: normal; letter-spacing: normal; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-position: initial initial; background-repeat: initial initial;">Windows Guest Agent Fully Supported</h3> <div class="para" style="background-color: rgb(255, 255, 255); font-size: 16px; border: 0px; margin: 0.3em 0px 1em; padding: 0px; vertical-align: baseline; widows: 4; orphans: 4; color: rgb(51, 51, 51); font-family: 'liberation sans', 'Myriad ', 'Bitstream Vera Sans', 'Lucida Grande', 'Luxi Sans', 'Trebuchet MS', helvetica, verdana, arial, sans-serif; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 18px; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-position: initial initial; background-repeat: initial initial;">The Windows guest agent is now fully supported and delivered with its own installer in the Supplementary channel together with virtio-win drivers.</div> [...]<br> <h3 style="background-color: rgb(255, 255, 255); font-size: 1.17em; border: 0px; margin: 1em 0px 0.4em; padding: 0px; vertical-align: baseline; color: rgb(167, 0, 0); font-family: 'liberation sans', 'Myriad ', 'Bitstream Vera Sans', 'Lucida Grande', 'Luxi Sans', 'Trebuchet MS', helvetica, verdana, arial, sans-serif; font-weight: bold; line-height: 18px; widows: 4; orphans: 4; font-style: normal; font-variant: normal; letter-spacing: normal; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-position: initial initial; background-repeat: initial initial;">Application-Aware<span class="Apple-converted-space"> </span><code class="command" style="background-color: transparent; font-size: 18px; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline; widows: 4 !important; orphans: 4 !important; font-family: 'liberation mono', 'bitstream vera mono', 'dejavu mono', monospace; font-weight: bold; white-space: pre-wrap; word-wrap: break-word; background-position: initial initial; background-repeat: initial initial;">freeze</code><span class="Apple-converted-space"> </span>and<span class="Apple-converted-space"> </span><code class="command" style="background-color: transparent; font-size: 18px; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline; widows: 4 !important; orphans: 4 !important; font-family: 'liberation mono', 'bitstream vera mono', 'dejavu mono', monospace; font-weight: bold; white-space: pre-wrap; word-wrap: break-word; background-position: initial initial; background-repeat: initial initial;">thaw</code><span class="Apple-converted-space"> </span>on Microsoft Windows with VSS Support on<span class="application" style="background-color: transparent; font-size: 18px; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline; widows: 4 !important; orphans: 4 !important; background-position: initial initial; background-repeat: initial initial;"><strong style="background-color: transparent; font-size: 18px; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline; widows: 4 !important; orphans: 4 !important; background-position: initial initial; background-repeat: initial initial;">qemu-ga-win</strong></span></h3> <div class="para" style="background-color: rgb(255, 255, 255); font-size: 16px; border: 0px; margin: 0.3em 0px 1em; padding: 0px; vertical-align: baseline; widows: 4; orphans: 4; color: rgb(51, 51, 51); font-family: 'liberation sans', 'Myriad ', 'Bitstream Vera Sans', 'Lucida Grande', 'Luxi Sans', 'Trebuchet MS', helvetica, verdana, arial, sans-serif; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 18px; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-position: initial initial; background-repeat: initial initial;">VSS (Volume Shadow Copy Service) is a Microsoft Windows API that allows, among other things, the notification of applications for proper, consistent freeze and thaw operations. With this feature, snapshots taken while the virtual machine is running are consistent through the whole stack (from the block layer to the guest applications) and can be used for backup purposes. For more information, see the<span class="Apple-converted-space"> </span><a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/..." style="background-color: transparent; font-size: 16px; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline; text-decoration: none; color: rgb(0, 102, 204); widows: 4 !important; orphans: 4 !important; background-position: initial initial; background-repeat: initial initial;">Virtualization Administration Guide</a></div> <div class="para" style="background-color: rgb(255, 255, 255); font-size: 16px; border: 0px; margin: 0.3em 0px 1em; padding: 0px; vertical-align: baseline; widows: 4; orphans: 4; color: rgb(51, 51, 51); font-family: 'liberation sans', 'Myriad ', 'Bitstream Vera Sans', 'Lucida Grande', 'Luxi Sans', 'Trebuchet MS', helvetica, verdana, arial, sans-serif; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 18px; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-position: initial initial; background-repeat: initial initial;"><br> Is there any issue with using these drivers with OVIRT? (since ovirt is upstream of RHEV, it should work, right?)<br> I know, the answer will be no...<br> </div> <br class="Apple-interchange-newline"> <br> </div> </body> </html> --------------060800050208070800010102--
On 12/18/2013 11:44 PM, Blaster wrote:
From RHEL 6.5 release notes...
Windows Guest Agent Fully Supported
The Windows guest agent is now fully supported and delivered with its own installer in the Supplementary channel together with virtio-win drivers. [...]
Application-Aware|freeze|and|thaw|on Microsoft Windows with VSS Support on*qemu-ga-win*
VSS (Volume Shadow Copy Service) is a Microsoft Windows API that allows, among other things, the notification of applications for proper, consistent freeze and thaw operations. With this feature, snapshots taken while the virtual machine is running are consistent through the whole stack (from the block layer to the guest applications) and can be used for backup purposes. For more information, see theVirtualization Administration Guide <https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sub-sect-qemu-ga-freeze-thaw.html>
Is there any issue with using these drivers with OVIRT? (since ovirt is upstream of RHEV, it should work, right?) I know, the answer will be no...
shouldn't be any issue using these (other than potential bugs of course)
On Thu, 19 Dec 2013 03:37:20 AM Itamar Heim wrote:
Windows Guest Agent Fully Supported
The Windows guest agent is now fully supported and delivered with its own installer in the Supplementary channel together with virtio-win drivers.
Is there somewhere I can download this windows gest agent installer from? -- Lindsay
On Thu, Dec 19, 2013 at 11:19 AM, Lindsay Mathieson <lindsay.mathieson@gmail.com> wrote:
On Thu, 19 Dec 2013 03:37:20 AM Itamar Heim wrote:
Windows Guest Agent Fully Supported
The Windows guest agent is now fully supported and delivered with its own installer in the Supplementary channel together with virtio-win drivers.
Is there somewhere I can download this windows gest agent installer from?
If you've got a red-hat subscription it's in the virtio-win package in the supplementary channel. It looks like there's no srpm available for that one.
----- Original Message -----
From: "Lindsay Mathieson" <lindsay.mathieson@gmail.com> To: users@ovirt.org Sent: Thursday, December 19, 2013 12:07:50 PM Subject: Re: [Users] Agents for Windows
On Thu, 19 Dec 2013 11:33:43 AM Sander Grendelman wrote:
If you've got a red-hat subscription it's in the virtio-win package in the supplementary channel. It looks like there's no srpm available for that one.
So its proprietary/closed src?
AFAIK there's the source, but there is no package, maybe vinzenz can point you where it is so you can compile it.
-- Lindsay _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 12/19/2013 12:17 PM, Antoni Segura Puimedon wrote:
----- Original Message -----
From: "Lindsay Mathieson" <lindsay.mathieson@gmail.com> To: users@ovirt.org Sent: Thursday, December 19, 2013 12:07:50 PM Subject: Re: [Users] Agents for Windows
On Thu, 19 Dec 2013 11:33:43 AM Sander Grendelman wrote:
If you've got a red-hat subscription it's in the virtio-win package in the supplementary channel. It looks like there's no srpm available for that one.
So its proprietary/closed src? AFAIK there's the source, but there is no package, maybe vinzenz can point you where it is so you can compile it.
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/
-- Lindsay _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On Thu, 19 Dec 2013 12:21:27 PM Vinzenz Feenstra wrote:
Subject: Re: [Users] Agents for Windows
On Thu, 19 Dec 2013 11:33:43 AM Sander Grendelman wrote:
If you've got a red-hat subscription it's in the virtio-win package in the supplementary channel. It looks like there's no srpm available for that one.
So its proprietary/closed src?
AFAIK there's the source, but there is no package, maybe vinzenz can point you where it is so you can compile it.
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/
That doesn't include the Guest Agent though (vdagent?), which is what makes the VSS calls. Unless I'm mistaken - always a possibility. -- Lindsay
This is a multi-part message in MIME format. --------------030000020405050302040105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/19/2013 01:31 PM, Lindsay Mathieson wrote:
On Thu, 19 Dec 2013 12:21:27 PM Vinzenz Feenstra wrote:
Subject: Re: [Users] Agents for Windows
On Thu, 19 Dec 2013 11:33:43 AM Sander Grendelman wrote:
If you've got a red-hat subscription it's in the virtio-win package in the supplementary channel. It looks like there's no srpm available for that one. So its proprietary/closed src? AFAIK there's the source, but there is no package, maybe vinzenz can point you where it is so you can compile it. http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/
That doesn't include the Guest Agent though (vdagent?), which is what makes the VSS calls. This are the virtio-drivers, the qemu guest agent makes VSS calls. We currently don't distribute any windows binaries. And all of that is open source. The qemu guest agent is in the qga folder of the qemu source tree. The vdagent is the spice agent
Unless I'm mistaken - always a possibility.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com --------------030000020405050302040105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 12/19/2013 01:31 PM, Lindsay Mathieson wrote:<br> </div> <blockquote cite="mid:1960325.Gpp2oBdms5@lindsay-office" type="cite"> <pre wrap="">On Thu, 19 Dec 2013 12:21:27 PM Vinzenz Feenstra wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Subject: Re: [Users] Agents for Windows On Thu, 19 Dec 2013 11:33:43 AM Sander Grendelman wrote: </pre> <blockquote type="cite"> <pre wrap="">If you've got a red-hat subscription it's in the virtio-win package in the supplementary channel. It looks like there's no srpm available for that one. </pre> </blockquote> <pre wrap=""> So its proprietary/closed src? </pre> </blockquote> <pre wrap=""> AFAIK there's the source, but there is no package, maybe vinzenz can point you where it is so you can compile it. </pre> </blockquote> <pre wrap=""> <a class="moz-txt-link-freetext" href="http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/">http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/</a> </pre> </blockquote> <pre wrap=""> That doesn't include the Guest Agent though (vdagent?), which is what makes the VSS calls.</pre> </blockquote> This are the virtio-drivers, the qemu guest agent makes VSS calls. We currently don't distribute any windows binaries.<br> And all of that is open source. The qemu guest agent is in the qga folder of the qemu source tree.<br> The vdagent is the spice agent<br> <blockquote cite="mid:1960325.Gpp2oBdms5@lindsay-office" type="cite"> <pre wrap=""> Unless I'm mistaken - always a possibility. </pre> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> <br> <pre class="moz-signature" cols="72">-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com</pre> </body> </html> --------------030000020405050302040105--
On Thu, 19 Dec 2013 03:22:22 PM Vinzenz Feenstra wrote:
This are the virtio-drivers, the qemu guest agent makes VSS calls. We currently don't distribute any windows binaries. And all of that is open source. The qemu guest agent is in the qga folder of the qemu source tree.
Thanks, that was what I was looking for.
The vdagent is the spice agent
I must admit to being confused as to the relationship between redhat, kvm and spice. There are separate agents for spice (vdagent) and qemu (qemu-ga)? Whats the host (qemu) program for sending commands to qemu-ga? If I wanted, could I build my own qemu-ga and make it available? or would it be undesirable from your perspective to have foreign builds of it floating about. Would it be better for me to write my own agent? What I want to achieve is integrate VSS support into another kvm manager (proxmox). I prefer to stick to the platform tools for this sort of thing rather than roll my own. thanks, -- Lindsay
On 12/19/2013 02:35 PM, Lindsay Mathieson wrote:
On Thu, 19 Dec 2013 03:22:22 PM Vinzenz Feenstra wrote:
This are the virtio-drivers, the qemu guest agent makes VSS calls. We currently don't distribute any windows binaries. And all of that is open source. The qemu guest agent is in the qga folder of the qemu source tree.
Thanks, that was what I was looking for.
The vdagent is the spice agent
I must admit to being confused as to the relationship between redhat, kvm and spice. There are separate agents for spice (vdagent) and qemu (qemu-ga)?
red hat is a company... it has developer working on multiple open source projects including qemu, kvm, spice, libvirt, ovirt and many others...
Whats the host (qemu) program for sending commands to qemu-ga?
qemu supports sending commands to qemu-ga. libvirt abstracts the qemu api for these commands. vdsm uses the libvirt api when qemu-ga operations are relevant. ovirt-engine asks vdsm for the operation (say, thaw/freeze during live snaphost would be done by libvirt on qemu, send to qemu-ga).
If I wanted, could I build my own qemu-ga and make it available? or would it be undesirable from your perspective to have foreign builds of it floating about. Would it be better for me to write my own agent?
the main problems with delivering windows binaries are build machines, licensing of tools, etc. so there is no problem with you providing those builds if they don't happen to be available already.
What I want to achieve is integrate VSS support into another kvm manager (proxmox). I prefer to stick to the platform tools for this sort of thing rather than roll my own.
that's the entire concept of open source...
thanks,
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 12/19/2013 04:40 PM, Itamar Heim wrote:
the main problems with delivering windows binaries are build machines, licensing of tools, etc. so there is no problem with you providing those builds if they don't happen to be available already.
From the peanut gallery: Since you're already building the Windows drivers on some (set of) Windows build servers and putting it onto the ISO(s), that would seem to be a good time to build the Windows Guest agent as well, and deliver it in the same manner, thus killing multiple birds with one stone. Is that possible? Thanks, Bob
On 12/19/2013 04:45 PM, Bob Doolittle wrote:
On 12/19/2013 04:40 PM, Itamar Heim wrote:
the main problems with delivering windows binaries are build machines, licensing of tools, etc. so there is no problem with you providing those builds if they don't happen to be available already.
From the peanut gallery:
Since you're already building the Windows drivers on some (set of) Windows build servers and putting it onto the ISO(s), that would seem to be a good time to build the Windows Guest agent as well, and deliver it in the same manner, thus killing multiple birds with one stone.
Is that possible?
we'd need to build this on ovirt or fedora or any other publicly available infra (iirc, it can't be done via mingw, but i could be wrong). I'd be really happy if anyone can try and help with this task, and investigate if mingw can solve it for the guest agent, etc.
Date: Thu=2C 19 Dec 2013 16:48:43 -0500 From: iheim@redhat.com To: bob@doolittle.us.com=3B lindsay.mathieson@gmail.com=3B users@ovirt.or= g Subject: Re: [Users] Agents for Windows =20 On 12/19/2013 04:45 PM=2C Bob Doolittle wrote:
On 12/19/2013 04:40 PM=2C Itamar Heim wrote:
the main problems with delivering windows binaries are build machines=
=2C
licensing of tools=2C etc. so there is no problem with you providing those builds if they don't happen to be available already.
From the peanut gallery:
Since you're already building the Windows drivers on some (set of) Windows build servers and putting it onto the ISO(s)=2C that would seem= to be a good time to build the Windows Guest agent as well=2C and deliver = it in the same manner=2C thus killing multiple birds with one stone.
Is that possible? Hey=2C we're on a topic that I've been wanting to email=2C but wasn't su= re which devel list to send it to. I have a few contributions that I would =
--_5e0ff589-f531-4834-a5da-05df1aad3ab4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 like to make in this area=2C but I'm not sure how to get started or what I = can do (licensing). 1) I have created a .bat installer which properly copie= s the files to the right places=2C starts the service=2C and sets it to sta= rt at boot. Tested XP through 2012 R2=2C 32 & 64-bit (well=2C not XP 64-bit= ). 2) I have a .exe installer (2 technically) which includes the ovirt-gues= t-agent built files=2C the .bat installer=2C and can display a license. It = extracts the files=2C and then the .bat runs to copy the files and start th= e service.3) I'm in the process of making a uninstall script to help with t= he removal. What I'd like to know/do1) Is it possible to distribute the bin= ary files with an installer? If so then someone like me could build them on= a windows system and share them back to oVirt in a .exe installer=2C a .is= o with installer (.bat or .exe)=2C or a .zip with an installer (.bat likely= ). More or less like we are doing for Ubuntu ovirt-guest-agent. 2) Can I co= ntribute the .bat installer to the ovirt-guest-tools repo so those who get-= clone and build the binaries only need to click the "install.bat" to get a = working install? Less desirable=2C but in a somewhat right direction. 3) I= f I contribute the .bat installer=2C could we build a .zip and .iso which i= nclude the built files and .bat installer? The .zip wouldn't be any differe= nt than the .exe - extract the files=2C click install.bat and vola. Probabl= y depends on #4 4) The problem is we don't readily have the windows binarie= s. We want to build the binaries on a common platform (Linux) - which I thi= nk we can do with pyinstaller (since py2exe isn't available on Linux). Can = I assist with that=2C which would help lead to a .zip or .iso without needi= ng a Windows system? I can't say we can generate a installer from python=2C= but we might be able to. I want to help with everything in the above. At t= he worst I'm getting ready to revamp the "How to build ovirt-guest-tools fo= r Windows" and could include a copy/paste-able version of the install.bat s= o someone could generate their own installer (install python=2C git-gui=2C = clone repo=2C compile=2C click install.bat=2C done) or even one a guide whi= ch does builds the same but creates a distributable .zip that someone could= use on their installs=2C but no distribution outside of their oVirt. All i= deas and I want to help! But I'll need a hand - I don't know how to use git= . I want to learn though.- Nick
=20 we'd need to build this on ovirt or fedora or any other publicly=20 available infra (iirc=2C it can't be done via mingw=2C but i could be wro= ng). I'd be really happy if anyone can try and help with this task=2C and=20 investigate if mingw can solve it for the guest agent=2C etc. =20 =20 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users =
>=3B >=3B be a good time to build the Windows Guest agent as well=2C a= nd deliver it<br>>=3B >=3B in the same manner=2C thus killing multiple = birds with one stone.<br>>=3B >=3B<br>>=3B >=3B Is that possible?<b= r>>=3B >=3B</div><div>Hey=2C we're on a topic that I've been wanting to= email=2C but wasn't sure which devel list to send it to. I have a few cont= ributions that I would like to make in this area=2C but I'm not sure how to= get started or what I can do (licensing).</div><div> =3B</div><div>1) = I have created a .bat installer which properly copies the files to the righ= t places=2C starts the service=2C and sets it to start at boot. Tested = =3BXP =3Bthrough 2012 R2=2C 32 &=3B 64-bit (well=2C not XP 64-bit). = </div><div>2) I have a .exe installer (2 technically) =3Bwhich includes=
--_5e0ff589-f531-4834-a5da-05df1aad3ab4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style><!-- .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 12pt=3B font-family:Calibri } --></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'><br> =3B<BR><div>>=3B Date= : Thu=2C 19 Dec 2013 16:48:43 -0500<br>>=3B From: iheim@redhat.com<br>>= =3B To: bob@doolittle.us.com=3B lindsay.mathieson@gmail.com=3B users@ovirt.= org<br>>=3B Subject: Re: [Users] Agents for Windows<br>>=3B <br>>=3B = On 12/19/2013 04:45 PM=2C Bob Doolittle wrote:<br>>=3B >=3B<br>>=3B &= gt=3B On 12/19/2013 04:40 PM=2C Itamar Heim wrote:<br>>=3B >=3B>=3B t= he main problems with delivering windows binaries are build machines=2C<br>= >=3B >=3B>=3B licensing of tools=2C etc.<br>>=3B >=3B>=3B so th= ere is no problem with you providing those builds if they don't<br>>=3B &= gt=3B>=3B happen to be available already.<br>>=3B >=3B<br>>=3B >= =3B From the peanut gallery:<br>>=3B >=3B<br>>=3B >=3B Since you'r= e already building the Windows drivers on some (set of)<br>>=3B >=3B Wi= ndows build servers and putting it onto the ISO(s)=2C that would seem to<br= the ovirt-guest-agent built files=2C the .bat installer=2C and can display= a license. It extracts the files=2C and then the .bat runs to copy the fil= es and start the service.</div><div>3) I'm in the process of making a unins= tall script to help with the removal.</div><div> =3B</div><div>What I'd= like to know/do</div><div>1) Is it possible to distribute the binary files= with an installer? If so then someone like me could build them on a window= s system =3Band share them back to oVirt in a .exe installer=2C a .iso = with installer (.bat or .exe)=2C or a .zip with an installer (.bat likely).= More or less like we are doing for Ubuntu ovirt-guest-agent.</div><div>&nb= sp=3B</div><div>2) Can I contribute the .bat installer to the ovirt-guest-t= ools repo so those who get-clone and build the binaries only need to click = the "install.bat" to get a working install? Less desirable=2C but in a some= what right direction. </div><div> =3B</div><div>3) If I contribute the = .bat installer=2C could we build a .zip and .iso which include the built fi= les and .bat installer? The .zip wouldn't be any different than the .exe - = extract the files=2C click install.bat and vola. Probably depends on #4</di= v><div> =3B</div><div>4) The problem is we don't readily have the windo= ws binaries. We want to build the binaries on a common platform (Linux) - w= hich I think we can do with pyinstaller (since py2exe isn't available on Li= nux). Can I assist with that=2C which would help lead to a .zip or .iso wit= hout needing a Windows system? I can't say we can generate a installer from= python=2C but we might be able to.</div><div> =3B</div><div>I want to = help with everything in the above. At the worst I'm getting ready to revamp= the "How to build ovirt-guest-tools for Windows" and could include a copy/= paste-able version of the install.bat so someone could generate their own i= nstaller (install python=2C git-gui=2C clone repo=2C compile=2C click insta= ll.bat=2C done) or even one a guide which does builds the same but <em>crea= tes a distributable</em> .zip that someone could use on their installs=2C b= ut no distribution outside of their oVirt.</div><div> =3B</div><div>All= ideas and I want to help! But I'll need a hand - I don't know how to use g= it. I want to learn though.</div><div>- Nick<br>>=3B <br>>=3B we'd need= to build this on ovirt or fedora or any other publicly <br>>=3B availabl= e infra (iirc=2C it can't be done via mingw=2C but i could be wrong).<br>&g= t=3B I'd be really happy if anyone can try and help with this task=2C and <= br>>=3B investigate if mingw can solve it for the guest agent=2C etc.<br>= >=3B <br>>=3B <br>>=3B ______________________________________________= _<br>>=3B Users mailing list<br>>=3B Users@ovirt.org<br>>=3B http://l= ists.ovirt.org/mailman/listinfo/users<br></div> </div></body> </html>= --_5e0ff589-f531-4834-a5da-05df1aad3ab4_--
On 20 December 2013 07:48, Itamar Heim <iheim@redhat.com> wrote:
On 12/19/2013 04:45 PM, Bob Doolittle wrote:
we'd need to build this on ovirt or fedora or any other publicly available infra (iirc, it can't be done via mingw, but i could be wrong). I'd be really happy if anyone can try and help with this task, and investigate if mingw can solve it for the guest agent, etc.
I believe the windows spice agent & installer is build via mingw on Fedora. -- Lindsay
On 12/19/2013 3:45 PM, Bob Doolittle wrote:
On 12/19/2013 04:40 PM, Itamar Heim wrote:
the main problems with delivering windows binaries are build machines, licensing of tools, etc. so there is no problem with you providing those builds if they don't happen to be available already.
From the peanut gallery:
Since you're already building the Windows drivers on some (set of) Windows build servers and putting it onto the ISO(s), that would seem to be a good time to build the Windows Guest agent as well, and deliver it in the same manner, thus killing multiple birds with one stone.
Is that possible?
IMHO, not having the Windows (and Linux) agents stuff worked out by this stage of your development, seems really odd to me. It's kinda like buying a car with no Upholstery. Yeah, it works'n all but it's kinda uncomfortable to use.
On 20 December 2013 07:40, Itamar Heim <iheim@redhat.com> wrote:
On 12/19/2013 02:35 PM, Lindsay Mathieson wrote:
Whats the host (qemu) program for sending commands to qemu-ga?
qemu supports sending commands to qemu-ga. libvirt abstracts the qemu api for these commands. vdsm uses the libvirt api when qemu-ga operations are relevant. ovirt-engine asks vdsm for the operation (say, thaw/freeze during live snaphost would be done by libvirt on qemu, send to qemu-ga).
Can the qemu-ga cmds be sent from the cmd line? are there any docs for this? Fee free to just send me a link :)
If I wanted, could I build my own qemu-ga and make it available? or would it be undesirable from your perspective to have foreign builds of it floating about. Would it be better for me to write my own agent?
the main problems with delivering windows binaries are build machines, licensing of tools, etc. so there is no problem with you providing those builds if they don't happen to be available already.
I thought you wouldn't like people distributing custom builds of qemu-ga when you have your own official ones, that it might confuse people. Cheers, -- Lindsay
On 12/19/2013 2:37 AM, Itamar Heim wrote:
shouldn't be any issue using these (other than potential bugs of course)
What is the name of the ISO? I tried installing the RHEV-toolsSetup_3.2_12.iso from RHEL 6.4 on ovirt 3.3.1 and it complained that I was not running RHEV so it refused to install. So I thought I would be smart and by-passed the gatekeep (setup.exe I think it was) and going right into the drivers directory and installing from there. It seemed to install OK, but it hosed up the VM and had to restore.
This is a multi-part message in MIME format. --------------030003010801060600030709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/09/2013 09:42 AM, Blaster wrote:
I forgot my number 5) BIOS needs to work like a standard PC BIOS (as does ESXi) in allowing you to press F8 to get a boot menu or F12 for network boot.
I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that. VMware provides a (relatively hidden) option to mitigate this - there's a radiobox in a menu somewhere that effectively says "issue an F2 immediately when the VM starts to boot up". This sends it straight into the BIOS menu. That radiobox has saved what little remains of my hair. I kind of like "Run Once" for most of my needs, but I do understand Blaster's point for his scenario. If we evolve away from Run Once, it will be super important to provide the feature similar to VMware to force the machine into BIOS after power up. Thanks, Bob
This run once stuff is silly. It works fine the first time I create a VM as there's no bootable OS on the datastore, but if I need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when the PXE completes it reboots, back into network boot, then I have to kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I just hit F12, network boot, OS re-installs, then reboots normally. Much better user experience. I gave our Red Hat sales people feedback on this issue and was told it's not going to change.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--------------030003010801060600030709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <br> <div class="moz-cite-prefix">On 12/09/2013 09:42 AM, Blaster wrote:<br> </div> <blockquote cite="mid:90DEB47A-B52D-44CA-A9F0-D24527FAB6C6@556nato.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <div> <div>I forgot my number 5) BIOS needs to work like a standard PC BIOS (as does ESXi) in allowing you to press F8 to get a boot menu or F12 for network boot. </div> </div> </blockquote> <br> I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.<br> <br> VMware provides a (relatively hidden) option to mitigate this - there's a radiobox in a menu somewhere that effectively says "issue an F2 immediately when the VM starts to boot up". This sends it straight into the BIOS menu. That radiobox has saved what little remains of my hair.<br> <br> I kind of like "Run Once" for most of my needs, but I do understand Blaster's point for his scenario. If we evolve away from Run Once, it will be super important to provide the feature similar to VMware to force the machine into BIOS after power up.<br> <br> Thanks,<br> Bob<br> <br> <blockquote cite="mid:90DEB47A-B52D-44CA-A9F0-D24527FAB6C6@556nato.com" type="cite"> <div> <div>This run once stuff is silly. It works fine the first time I create a VM as there’s no bootable OS on the datastore, but if I need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when the PXE completes it reboots, back into network boot, then I have to kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I just hit F12, network boot, OS re-installs, then reboots normally. Much better user experience. I gave our Red Hat sales people feedback on this issue and was told it’s not going to change. </div> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> </body> </html> --------------030003010801060600030709--
On 12/09/2013 09:10 PM, Bob Doolittle wrote:
On 12/09/2013 09:42 AM, Blaster wrote:
I forgot my number 5) BIOS needs to work like a standard PC BIOS (as does ESXi) in allowing you to press F8 to get a boot menu or F12 for network boot.
I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.
VMware provides a (relatively hidden) option to mitigate this - there's a radiobox in a menu somewhere that effectively says "issue an F2 immediately when the VM starts to boot up". This sends it straight into the BIOS menu. That radiobox has saved what little remains of my hair.
I kind of like "Run Once" for most of my needs, but I do understand Blaster's point for his scenario. If we evolve away from Run Once, it will be super important to provide the feature similar to VMware to force the machine into BIOS after power up.
you can also start the VM in paused mode, then resume when console is open. another option is to add an option to have the menu alive for a few more seconds or indeed, to allow scripting a set of keystrokes
Thanks, Bob
This run once stuff is silly. It works fine the first time I create a VM as there’s no bootable OS on the datastore, but if I need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when the PXE completes it reboots, back into network boot, then I have to kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I just hit F12, network boot, OS re-installs, then reboots normally. Much better user experience. I gave our Red Hat sales people feedback on this issue and was told it’s not going to change.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 12/09/2013 02:48 PM, Itamar Heim wrote:
On 12/09/2013 09:10 PM, Bob Doolittle wrote:
On 12/09/2013 09:42 AM, Blaster wrote:
I forgot my number 5) BIOS needs to work like a standard PC BIOS (as does ESXi) in allowing you to press F8 to get a boot menu or F12 for network boot.
I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.
VMware provides a (relatively hidden) option to mitigate this - there's a radiobox in a menu somewhere that effectively says "issue an F2 immediately when the VM starts to boot up". This sends it straight into the BIOS menu. That radiobox has saved what little remains of my hair.
I kind of like "Run Once" for most of my needs, but I do understand Blaster's point for his scenario. If we evolve away from Run Once, it will be super important to provide the feature similar to VMware to force the machine into BIOS after power up.
you can also start the VM in paused mode, then resume when console is open.
Thanks. That sounds adequate to me, although I've not tried it. Of course this doesn't meet Blaster's needs for pausing a VM when it reboots. I wasn't clear as to how VMware solves that problem either. -Bob
another option is to add an option to have the menu alive for a few more seconds or indeed, to allow scripting a set of keystrokes
Thanks, Bob
This run once stuff is silly. It works fine the first time I create a VM as there’s no bootable OS on the datastore, but if I need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when the PXE completes it reboots, back into network boot, then I have to kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I just hit F12, network boot, OS re-installs, then reboots normally. Much better user experience. I gave our Red Hat sales people feedback on this issue and was told it’s not going to change.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob@doolittle.us.com> wrote:
I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.
On ESXi Guest menu -> edit settings -> Options -> boot options -> boot delay. I set all mine to 10,000ms. Delays guest startup by 10 seconds each time you boot, but it’s plenty of time to get the console up (if you need to) and get press F? to get where you want to be.
On 12/10/2013 03:54 AM, Blaster wrote:
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob@doolittle.us.com> wrote:
I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.
On ESXi Guest menu -> edit settings -> Options -> boot options -> boot delay. I set all mine to 10,000ms. Delays guest startup by 10 seconds each time you boot, but it’s plenty of time to get the console up (if you need to) and get press F? to get where you want to be.
btw, what happens if you boot from [disk, pxe] - if the disk doesn't have anything on it, its supposed to pass to 2nd boot device, then on restart it will be ok?
On 12/10/2013 4:54 AM, Itamar Heim wrote:
btw, what happens if you boot from [disk, pxe] - if the disk doesn't have anything on it, its supposed to pass to 2nd boot device, then on restart it will be ok?
Yes, that's the behavior on both ovirt and ESXi when creating a new VM. The problem is when you need to reinstall that VM. On ESXi I can hit F12 on boot to PXE boot, OS re-installs, then boots normally to disk. On ovirt, I have to select Run Once, move PXE to the top, re-install, when the installer auto reboots, it goes back into PXE mode and starts reinstalling again. I have to watch the console and power off at the right time, then power back on in normal mode. A better behavior for Run Once would be just that...Run once...If the guest reboots Run Once should power off, or go back to normal boot behavior. But I suppose that depends upon what your definition of Run Once is. The ESXi BIOS is a Pheonix BIOS and in this case, functions just like a bare metal BIOS, like the ovirt Sea BIOS should :)
On 12/10/2013 06:47 PM, Blaster wrote:
On 12/10/2013 4:54 AM, Itamar Heim wrote:
btw, what happens if you boot from [disk, pxe] - if the disk doesn't have anything on it, its supposed to pass to 2nd boot device, then on restart it will be ok?
Yes, that's the behavior on both ovirt and ESXi when creating a new VM. The problem is when you need to reinstall that VM. On ESXi I can hit F12 on boot to PXE boot, OS re-installs, then boots normally to disk. On ovirt, I have to select Run Once, move PXE to the top, re-install, when the installer auto reboots, it goes back into PXE mode and starts reinstalling again. I have to watch the console and power off at the right time, then power back on in normal mode.
A better behavior for Run Once would be just that...Run once...If the guest reboots Run Once should power off, or go back to normal boot behavior. But I suppose that depends upon what your definition of Run Once is.
The ESXi BIOS is a Pheonix BIOS and in this case, functions just like a bare metal BIOS, like the ovirt Sea BIOS should :)
have you tried using a custom hook to pass to libvirt the parameter to wait for 10 seconds during boot menu?
Just wanted to share my view. Have been working with vmware vsphere for a number of years and when dealing with a few hundreds of vm's, setting a boot delay on each is not a good way to handle this issue IMHO. Besides, this setting affects all sysadminsand might not be what everyone wishes. I think the runonce function is great and do not want that removed. Regards, Anders On Dec 10, 2013 2:54 AM, "Blaster" <blaster@556nato.com> wrote:
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob@doolittle.us.com> wrote:
I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.
On ESXi Guest menu -> edit settings -> Options -> boot options -> boot delay. I set all mine to 10,000ms. Delays guest startup by 10 seconds each time you boot, but it’s plenty of time to get the console up (if you need to) and get press F? to get where you want to be.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
This is a multi-part message in MIME format. --------------020806020106020502020403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit This setting is a PER GUEST setting, not system wide. On guests you reboot frequently, don't set anything. On guests you need to change boot options frequently, change it to what you want. We have about 6000 guests on ESXi, have not had any issues working this way. On production VMs that get built once and never touched for years, don't change anything. On dev VMs that get rebuilt frequently, we add a delay. On 12/10/2013 9:03 AM, Anders Hellquist wrote:
Just wanted to share my view.
Have been working with vmware vsphere for a number of years and when dealing with a few hundreds of vm's, setting a boot delay on each is not a good way to handle this issue IMHO. Besides, this setting affects all sysadminsand might not be what everyone wishes. I think the runonce function is great and do not want that removed.
Regards, Anders
On Dec 10, 2013 2:54 AM, "Blaster" <blaster@556nato.com <mailto:blaster@556nato.com>> wrote:
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob@doolittle.us.com <mailto:bob@doolittle.us.com>> wrote:
> I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.
On ESXi Guest menu -> edit settings -> Options -> boot options -> boot delay. I set all mine to 10,000ms. Delays guest startup by 10 seconds each time you boot, but its plenty of time to get the console up (if you need to) and get press F? to get where you want to be.
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
--------------020806020106020502020403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">This setting is a PER GUEST setting, not system wide. On guests you reboot frequently, don't set anything. On guests you need to change boot options frequently, change it to what you want.<br> <br> We have about 6000 guests on ESXi, have not had any issues working this way. On production VMs that get built once and never touched for years, don't change anything. On dev VMs that get rebuilt frequently, we add a delay.<br> <br> <br> On 12/10/2013 9:03 AM, Anders Hellquist wrote:<br> </div> <blockquote cite="mid:CAEs_EOJV-XKBEZpkZzuGSH9EEHa7TLD=wEjfQYp70g=pUBKT3g@mail.gmail.com" type="cite"> <div dir="ltr"> <p dir="ltr">Just wanted to share my view.</p> <p dir="ltr">Have been working with vmware vsphere for a number of years and when dealing with a few hundreds of vm's, setting a boot delay on each is not a good way to handle this issue IMHO. Besides, this setting affects all sysadminsand might not be what everyone wishes. I think the runonce function is great and do not want that removed.</p> <p dir="ltr"><br> </p> <p>Regards, Anders<br> </p> <div class="gmail_quote">On Dec 10, 2013 2:54 AM, "Blaster" <<a moz-do-not-send="true" href="mailto:blaster@556nato.com" target="_blank">blaster@556nato.com</a>> wrote:<br type="attribution"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> On Dec 9, 2013, at 1:10 PM, Bob Doolittle <<a moz-do-not-send="true" href="mailto:bob@doolittle.us.com" target="_blank">bob@doolittle.us.com</a>> wrote:<br> <br> > I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.<br> <br> On ESXi<br> Guest menu -> edit settings -> Options -> boot options -> boot delay. I set all mine to 10,000ms. Delays guest startup by 10 seconds each time you boot, but its plenty of time to get the console up (if you need to) and get press F? to get where you want to be.<br> <br> <br> <br> _______________________________________________<br> Users mailing list<br> <a moz-do-not-send="true" href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br> <a moz-do-not-send="true" href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br> </blockquote> </div> </div> </blockquote> <br> </body> </html> --------------020806020106020502020403--
On 12/10/2013 11:57 AM, Blaster wrote:
This setting is a PER GUEST setting, not system wide. On guests you reboot frequently, don't set anything. On guests you need to change boot options frequently, change it to what you want.
We have about 6000 guests on ESXi, have not had any issues working this way. On production VMs that get built once and never touched for years, don't change anything. On dev VMs that get rebuilt frequently, we add a delay.
On 12/10/2013 9:03 AM, Anders Hellquist wrote:
Just wanted to share my view.
Have been working with vmware vsphere for a number of years and when dealing with a few hundreds of vm's, setting a boot delay on each is not a good way to handle this issue IMHO. Besides, this setting affects all sysadminsand might not be what everyone wishes. I think the runonce function is great and do not want that removed.
Regards, Anders
On Dec 10, 2013 2:54 AM, "Blaster" <blaster@556nato.com <mailto:blaster@556nato.com>> wrote:
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob@doolittle.us.com <mailto:bob@doolittle.us.com>> wrote:
> I'll disagree a tiny bit here. One *really annoying* quality of needing to use F2/F8/F12 during Windows bootup in a VM (including ESX/vSphere) is that sometimes it can be impossible to be quick enough on the keyboard to get attention before the OS bootup has begun. By the time you can get a console focus it's too late. That can be enormously frustrating, and Run Once does help with that.
On ESXi Guest menu -> edit settings -> Options -> boot options -> boot delay. I set all mine to 10,000ms. Delays guest startup by 10 seconds each time you boot, but it’s plenty of time to get the console up (if you need to) and get press F? to get where you want to be.
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
were RFEs opened for: - allowing to enable boot menu - orchestrating a disk reboot post a pxe boot via detection of reboot
On 12/18/2013 11:46 PM, Blaster wrote:
On 12/18/2013 3:23 AM, Itamar Heim wrote:
were RFEs opened for: - allowing to enable boot menu - orchestrating a disk reboot post a pxe boot via detection of reboot
Is this something I can do?
yes, just open a bug and flag it with keyword FutureFeature https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt
participants (12)
-
Anders Hellquist -
Antoni Segura Puimedon -
Blaster -
Blaster
-
Bob Doolittle -
Gianluca Cecchi -
Itamar Heim -
Lindsay Mathieson -
Michal Skrivanek -
Nicholas Kesick -
Sander Grendelman -
Vinzenz Feenstra