1:15 p.m.
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?
2:55 a.m.
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(a)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
6:18 a.m.
On Dec 3, 2013, at 10:55 , Vinzenz Feenstra <vfeenstr(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:33 p.m.
On 12/3/2013 7:18 AM, Michal Skrivanek wrote:
On Dec 3, 2013, at 10:55 , Vinzenz Feenstra
<vfeenstr(a)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.
4:25 a.m.
On 12/06/2013 05:33 AM, Blaster wrote:
On 12/3/2013 7:18 AM, Michal Skrivanek wrote:
> On Dec 3, 2013, at 10:55 , Vinzenz Feenstra <vfeenstr(a)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.
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.
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(a)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
1:14 p.m.
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
12:39 a.m.
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
7:42 a.m.
--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(a)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--
11:56 a.m.
On 12/09/2013 04:42 PM, Blaster wrote:
On Dec 6, 2013, at 5:25 AM, Vinzenz Feenstra <vfeenstr(a)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?
12:19 p.m.
--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--
7:01 p.m.
--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(a)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
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=
> wrote:</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><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...
=
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--
11:43 p.m.
On Dec 10, 2013, at 04:01 , Blaster <blaster(a)556nato.com> wrote:
On Dec 9, 2013, at 1:19 PM, Michal Skrivanek <michal.skrivanek(a)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
11:54 p.m.
On Dec 10, 2013, at 08:43 , Michal Skrivanek <michal.skrivanek(a)redhat.com> wrote:
On Dec 10, 2013, at 04:01 , Blaster <blaster(a)556nato.com> wrote:
>
> On Dec 9, 2013, at 1:19 PM, Michal Skrivanek <michal.skrivanek(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:01 a.m.
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?
9:44 p.m.
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_Lin...
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_Ent...
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--
1:37 a.m.
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_Lin...
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)
3:19 a.m.
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
3:33 a.m.
On Thu, Dec 19, 2013 at 11:19 AM, Lindsay Mathieson
<lindsay.mathieson(a)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.
4:17 a.m.
----- Original Message -----
From: "Lindsay Mathieson"
<lindsay.mathieson(a)gmail.com>
To: users(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4:21 a.m.
On 12/19/2013 12:17 PM, Antoni Segura Puimedon wrote:
----- Original Message -----
> From: "Lindsay Mathieson" <lindsay.mathieson(a)gmail.com>
> To: users(a)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(a)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
5:31 a.m.
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
7:22 a.m.
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(a)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/...
</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://...
</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--
12:35 p.m.
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
2:40 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
2:45 p.m.
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
2:48 p.m.
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.
5:11 p.m.
--_5e0ff589-f531-4834-a5da-05df1aad3ab4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
=20
Date: Thu=2C 19 Dec 2013 16:48:43 -0500
From: iheim(a)redhat.com
To: bob(a)doolittle.us.com=3B lindsay.mathieson(a)gmail.com=3B users(a)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 =
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
=
--_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(a)redhat.com<br>&gt=
=3B To: bob(a)doolittle.us.com=3B lindsay.mathieson(a)gmail.com=3B users(a)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=
>=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=
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(a)ovirt.org<br>&gt=3B http://l=
ists.ovirt.org/mailman/listinfo/users<br></div>
</div></body>
</html>=
--_5e0ff589-f531-4834-a5da-05df1aad3ab4_--
5:57 p.m.
On 20 December 2013 07:48, Itamar Heim <iheim(a)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
7:36 a.m.
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.
5:54 p.m.
On 20 December 2013 07:40, Itamar Heim <iheim(a)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
10:13 a.m.
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.
12:10 p.m.
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(a)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://...
</pre>
</blockquote>
<br>
</body>
</html>
--------------030003010801060600030709--
12:48 p.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
1:07 p.m.
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
6:54 p.m.
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob(a)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.
3:54 a.m.
On 12/10/2013 03:54 AM, Blaster wrote:
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob(a)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?
9:47 a.m.
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 :)
6:58 a.m.
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?
8:03 a.m.
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(a)556nato.com> wrote:
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:57 a.m.
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(a)556nato.com
<mailto:blaster@556nato.com>> wrote:
On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob(a)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(a)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(a)556nato.com</a>&gt;
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(a)doolittle.us.com</a>&gt;
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(a)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/user...
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>
--------------020806020106020502020403--
2:23 a.m.
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(a)556nato.com
> <mailto:blaster@556nato.com>> wrote:
>
>
> On Dec 9, 2013, at 1:10 PM, Bob Doolittle <bob(a)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(a)ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users(a)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
12:19 a.m.
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
3790
days inactive
3808
days old
44 comments
12 participants
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