From tvvcox at redhat.com Thu Aug 20 10:04:18 2015 Content-Type: multipart/mixed; boundary="===============6116867905417197324==" MIME-Version: 1.0 From: Tomas Von Veschler To: rhevm-api at lists.fedorahosted.org Subject: [rhevm-api] VM start action issues Date: Sun, 26 Sep 2010 17:22:47 +0200 Message-ID: <4C9F6547.6010204@redhat.com> --===============6116867905417197324== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I'm unable to start a VM, this is what I get on both milestone 1 and 3: POST = /rhevm-api-powershell/vms/28468e6d-8045-40bb-8c0e-543cec4d90ce/start = HTTP/1.1 Authorization: Basic cmhldmFkbWluOnJlZGhhdDEyMy4=3D Host: rhevm:8443 Accept: application/xml Content-type: application/xml HTTP/1.1 400 Petici=C3=B3n incorrecta Server: Apache-Coyote/1.1 Content-Type: text/html;charset=3Dutf-8 Content-Length: 1338 Date: Sun, 26 Sep 2010 13:18:13 GMT Connection: close ... javax.xml.bind.UnmarshalException - with linked exception: = [org.xml.sax.SAXParseException: Premature end of file.] Any ideas? Thanks, Tomas --===============6116867905417197324==-- From eoghan.glynn at gmail.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============3568999954622497270==" MIME-Version: 1.0 From: Eoghan Glynn To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Mon, 27 Sep 2010 08:27:29 +0100 Message-ID: In-Reply-To: 4C9F6547.6010204@redhat.com --===============3568999954622497270== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Tomas, Have you included an Action representation in the entity body? You'll need at least: even if there are no explicit action parameters required. Cheers, Eoghan On 26 September 2010 16:22, Tomas Von Veschler wrote: > Hi, > > I'm unable to start a VM, this is what I get on both milestone 1 and 3: > > POST > /rhevm-api-powershell/vms/28468e6d-8045-40bb-8c0e-543cec4d90ce/start > HTTP/1.1 > Authorization: Basic cmhldmFkbWluOnJlZGhhdDEyMy4=3D > Host: rhevm:8443 > Accept: application/xml > Content-type: application/xml > > HTTP/1.1 400 Petici=C3=B3n incorrecta > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=3Dutf-8 > Content-Length: 1338 > Date: Sun, 26 Sep 2010 13:18:13 GMT > Connection: close > > ... > javax.xml.bind.UnmarshalException - with linked exception: > [org.xml.sax.SAXParseException: Premature end of file.] > > Any ideas? > > Thanks, > > Tomas > > _______________________________________________ > rhevm-api mailing list > rhevm-api(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/rhevm-api > --===============3568999954622497270== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGJyPkhpIFRvbWFzLDxicj48YnI+CkhhdmUgeW91IGluY2x1ZGVkIGFuIEFjdGlvbiByZXByZXNl bnRhdGlvbiBpbiB0aGUgZW50aXR5IGJvZHk/PGJyPgo8YnI+CllvdSYjMzk7bGwgbmVlZCBhdCBs ZWFzdDo8YnI+Cjxicj4KJmx0Oy9hY3Rpb24mZ3Q7PGJyPgo8YnI+CmV2ZW4gaWYgdGhlcmUgYXJl IG5vIGV4cGxpY2l0IGFjdGlvbiBwYXJhbWV0ZXJzIHJlcXVpcmVkLjxicj4KPGJyPgpDaGVlcnMs PGJyPgpFb2doYW48YnI+PGJyPjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDI2 IFNlcHRlbWJlciAyMDEwIDE2OjIyLCBUb21hcyBWb24gVmVzY2hsZXIgPHNwYW4gZGlyPSJsdHIi PiZsdDs8YSBocmVmPSJtYWlsdG86dHZ2Y294QHJlZGhhdC5jb20iPnR2dmNveEByZWRoYXQuY29t PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBib3JkZXItbGVmdDogMXB4IHNvbGlk IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KSGksPGJyPgo8YnI+Ckkm IzM5O20gdW5hYmxlIHRvIHN0YXJ0IGEgVk0sIHRoaXMgaXMgd2hhdCBJIGdldCBvbiBib3RoIG1p bGVzdG9uZSAxIGFuZCAzOjxicj4KPGJyPgpQT1NUPGJyPgovcmhldm0tYXBpLXBvd2Vyc2hlbGwv dm1zLzI4NDY4ZTZkLTgwNDUtNDBiYi04YzBlLTU0M2NlYzRkOTBjZS9zdGFydDxicj4KSFRUUC8x LjE8YnI+CkF1dGhvcml6YXRpb246IEJhc2ljIGNtaGxkbUZrYldsdU9uSmxaR2hoZERFeU15ND08 YnI+Ckhvc3Q6IHJoZXZtOjg0NDM8YnI+CkFjY2VwdDogYXBwbGljYXRpb24veG1sPGJyPgpDb250 ZW50LXR5cGU6IGFwcGxpY2F0aW9uL3htbDxicj4KPGJyPgpIVFRQLzEuMSA0MDAgUGV0aWNp824g aW5jb3JyZWN0YTxicj4KU2VydmVyOiBBcGFjaGUtQ295b3RlLzEuMTxicj4KQ29udGVudC1UeXBl OiB0ZXh0L2h0bWw7Y2hhcnNldD11dGYtODxicj4KQ29udGVudC1MZW5ndGg6IDEzMzg8YnI+CkRh dGU6IFN1biwgMjYgU2VwIDIwMTAgMTM6MTg6MTMgR01UPGJyPgpDb25uZWN0aW9uOiBjbG9zZTxi cj4KPGJyPgombHQ7aHRtbCZndDsuLi48YnI+CmphdmF4LnhtbC5iaW5kLlVubWFyc2hhbEV4Y2Vw dGlvbiAtIHdpdGggbGlua2VkIGV4Y2VwdGlvbjo8YnI+CltvcmcueG1sLnNheC5TQVhQYXJzZUV4 Y2VwdGlvbjogUHJlbWF0dXJlIGVuZCBvZiBmaWxlLl08YnI+Cjxicj4KQW55IGlkZWFzPzxicj4K PGJyPgpUaGFua3MsPGJyPgo8YnI+ClRvbWFzPGJyPgo8YnI+Cl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpyaGV2bS1hcGkgbWFpbGluZyBsaXN0PGJy Pgo8YSBocmVmPSJtYWlsdG86cmhldm0tYXBpQGxpc3RzLmZlZG9yYWhvc3RlZC5vcmciPnJoZXZt LWFwaUBsaXN0cy5mZWRvcmFob3N0ZWQub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly9mZWRv cmFob3N0ZWQub3JnL21haWxtYW4vbGlzdGluZm8vcmhldm0tYXBpIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9mZWRvcmFob3N0ZWQub3JnL21haWxtYW4vbGlzdGluZm8vcmhldm0tYXBpPC9hPjxi cj4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K --===============3568999954622497270==-- From tvvcox at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============1934774179199835834==" MIME-Version: 1.0 From: Tomas Von Veschler To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Tue, 28 Sep 2010 23:28:38 +0200 Message-ID: <4CA25E06.7070605@redhat.com> In-Reply-To: AANLkTi=xAKZegnPKkDH7Lss15uqGdV+bAhakJJG7KaqN@mail.gmail.com --===============1934774179199835834== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/27/2010 09:27 AM, Eoghan Glynn wrote: > > Hi Tomas, > > Have you included an Action representation in the entity body? > > You'll need at least: > > I'm sure you meant :-) > even if there are no explicit action parameters required. Oh ok works now, maybe the documentation could be more explicit about this? http://markmc.fedorapeople.org/rhevm-api/en-US/html/sect-REST_API_Guide-VMs= -Start.html Now I'm in a new trouble. When installing VMs via PXE if I specify , the VM will never use the disc as boot device. Options = I've seen: 1) Set network as boot device, wait for install, shutdown, change boot = device, start. This is too complex to implement. 2) Specify second boot device. It's not very well documented, but the = Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, = D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not available us= e = Network. 3) Set Add-VM -DefaultBootSequence C and "run once" the VM with Start-VM = -BootDevice N Any idea how could I go for 2) or 3) with the API? Thanks, Tomas > Cheers, > Eoghan > > > > On 26 September 2010 16:22, Tomas Von Veschler > wrote: > > Hi, > > I'm unable to start a VM, this is what I get on both milestone 1 and = 3: > > POST > /rhevm-api-powershell/vms/28468e6d-8045-40bb-8c0e-543cec4d90ce/start > HTTP/1.1 > Authorization: Basic cmhldmFkbWluOnJlZGhhdDEyMy4=3D > Host: rhevm:8443 > Accept: application/xml > Content-type: application/xml > > HTTP/1.1 400 Petici=C3=B3n incorrecta > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=3Dutf-8 > Content-Length: 1338 > Date: Sun, 26 Sep 2010 13:18:13 GMT > Connection: close > > ... > javax.xml.bind.UnmarshalException - with linked exception: > [org.xml.sax.SAXParseException: Premature end of file.] > > Any ideas? > > Thanks, > > Tomas > > _______________________________________________ > rhevm-api mailing list > rhevm-api(a)lists.fedorahosted.org > > https://fedorahosted.org/mailman/listinfo/rhevm-api > > --===============1934774179199835834==-- From markmc at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============6834614270305507521==" MIME-Version: 1.0 From: Mark McLoughlin To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 08:03:22 +0100 Message-ID: <1285743802.3014.7.camel@blaa> In-Reply-To: 4CA25E06.7070605@redhat.com --===============6834614270305507521== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, 2010-09-28 at 23:28 +0200, Tomas Von Veschler wrote: > Oh ok works now, maybe the documentation could be more explicit about thi= s? > = > http://markmc.fedorapeople.org/rhevm-api/en-US/html/sect-REST_API_Guide-V= Ms-Start.html Care to send a patch? :) > Now I'm in a new trouble. When installing VMs via PXE if I specify dev=3D"network"/>, the VM will never use the disc as boot device. Options = > I've seen: > = > 1) Set network as boot device, wait for install, shutdown, change boot = > device, start. This is too complex to implement. How about set network as boot device, start and immediately change boot device to network. The new boot device will only take effect next time the VM is restarted This is the libvirt way of doing it, except it also has the ability to show you both the effective configuration of the running VM and the configuration which will take effect if it restarts > 2) Specify second boot device. It's not very well documented, but the = > Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, = > D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not available = use = > Network. You can do that with the REST API using: > 3) Set Add-VM -DefaultBootSequence C and "run once" the VM with Start-VM = > -BootDevice N We haven't implemented "run once" yet, since we're tying to figure out what the use case for it is above my answer to (1). If/when we understand the use case, we'll add it Cheers, Mark. --===============6834614270305507521==-- From tvvcox at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============6969486398640583754==" MIME-Version: 1.0 From: Tomas Von Veschler To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 15:21:38 +0200 Message-ID: <4CA33D62.9040406@redhat.com> In-Reply-To: 1285743802.3014.7.camel@blaa --===============6969486398640583754== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/29/2010 09:03 AM, Mark McLoughlin wrote: > On Tue, 2010-09-28 at 23:28 +0200, Tomas Von Veschler wrote: > >> Oh ok works now, maybe the documentation could be more explicit about th= is? >> >> http://markmc.fedorapeople.org/rhevm-api/en-US/html/sect-REST_API_Guide-= VMs-Start.html > > Care to send a patch? :) Sure, just one more question below :-) >> Now I'm in a new trouble. When installing VMs via PXE if I specify> dev=3D"network"/>, the VM will never use the disc as boot device. Options >> I've seen: >> >> 1) Set network as boot device, wait for install, shutdown, change boot >> device, start. This is too complex to implement. > > How about set network as boot device, start and immediately change boot > device to network. The new boot device will only take effect next time > the VM is restarted Mmm I've tested this approach but it doesn't work as expected. Seems = that RHEV only takes that change after a VM shutdown. So add vm, start, = change boot device, install, reboot: the VM will keep booting via network. >> 2) Specify second boot device. It's not very well documented, but the >> Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, >> D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not available= use >> Network. > > You can do that with the REST API using: > > > > > This is what I'm doing now: 1) Add vm with: 2) start vm 3) Edit VM to: A little tricky but does the job :-) Want me to document this? >> 3) Set Add-VM -DefaultBootSequence C and "run once" the VM with Start-VM >> -BootDevice N > > We haven't implemented "run once" yet, since we're tying to figure out > what the use case for it is above my answer to (1). If/when we > understand the use case, we'll add it I can think on the cdrom case, run once would automatically detach the = ISO on reboot (shutdown?). Regards, Tomas --===============6969486398640583754==-- From markmc at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============6356030166786214245==" MIME-Version: 1.0 From: Mark McLoughlin To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 17:16:41 +0100 Message-ID: <1285777001.3014.167.camel@blaa> In-Reply-To: 4CA33D62.9040406@redhat.com --===============6356030166786214245== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2010-09-29 at 15:21 +0200, Tomas Von Veschler wrote: > On 09/29/2010 09:03 AM, Mark McLoughlin wrote: > > On Tue, 2010-09-28 at 23:28 +0200, Tomas Von Veschler wrote: > > > >> Oh ok works now, maybe the documentation could be more explicit about = this? > >> > >> http://markmc.fedorapeople.org/rhevm-api/en-US/html/sect-REST_API_Guid= e-VMs-Start.html > > > > Care to send a patch? :) > = > Sure, just one more question below :-) > = > >> Now I'm in a new trouble. When installing VMs via PXE if I specify >> dev=3D"network"/>, the VM will never use the disc as boot device. Opti= ons > >> I've seen: > >> > >> 1) Set network as boot device, wait for install, shutdown, change boot > >> device, start. This is too complex to implement. > > > > How about set network as boot device, start and immediately change boot > > device to network. The new boot device will only take effect next time > > the VM is restarted > = > Mmm I've tested this approach but it doesn't work as expected. Seems = > that RHEV only takes that change after a VM shutdown. So add vm, start, = > change boot device, install, reboot: the VM will keep booting via network. Okay, if that's the case then we definitely need to support RunOnce support > >> 2) Specify second boot device. It's not very well documented, but the > >> Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, > >> D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not availab= le use > >> Network. > > > > You can do that with the REST API using: > > > > > > > > > > > = > This is what I'm doing now: > = > 1) Add vm with: > > > > > = > 2) start vm > = > 3) Edit VM to: > > > > = > A little tricky but does the job :-) Want me to document this? Nah, if we add RunOnce you won't need to do this > >> 3) Set Add-VM -DefaultBootSequence C and "run once" the VM with Start-= VM > >> -BootDevice N > > > > We haven't implemented "run once" yet, since we're tying to figure out > > what the use case for it is above my answer to (1). If/when we > > understand the use case, we'll add it > = > I can think on the cdrom case, run once would automatically detach the = > ISO on reboot (shutdown?). RunOnce basically doesn't affect the VM configuration. So, if the VM is configured to boot from disk and you do RunOnce with dev=3D"cdrom", then the next time you start without RunOnce the VM it goes back to booting from disk. Actually, it probably makes sense to support RunOnce by allowing the start action to take parameters like Cheers, Mark. --===============6356030166786214245==-- From iheim at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============6589931848019263300==" MIME-Version: 1.0 From: iheim at redhat.com To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 12:21:31 -0400 Message-ID: <301001cb5ff2$734b9a50$59e2cef0$@com> In-Reply-To: 1285743802.3014.7.camel@blaa --===============6589931848019263300== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > From: rhevm-api-bounces(a)lists.fedorahosted.org [mailto:rhevm-api- > bounces(a)lists.fedorahosted.org] On Behalf Of Mark McLoughlin ... > > 2) Specify second boot device. It's not very well documented, but the > > Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, > > D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not available use > > Network. > = > You can do that with the REST API using: > = > > > > [IH] do you assume XML is ordered here? I thought you are not supposed to do that with XML? --===============6589931848019263300==-- From markmc at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============3898051459991729331==" MIME-Version: 1.0 From: Mark McLoughlin To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 17:30:01 +0100 Message-ID: <1285777801.3014.174.camel@blaa> In-Reply-To: 301001cb5ff2$734b9a50$59e2cef0$@com --===============3898051459991729331== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2010-09-29 at 12:21 -0400, Itamar Heim wrote: > > From: rhevm-api-bounces(a)lists.fedorahosted.org [mailto:rhevm-api- > > bounces(a)lists.fedorahosted.org] On Behalf Of Mark McLoughlin > ... > > > 2) Specify second boot device. It's not very well documented, but the > > > Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, > > > D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not availa= ble > use > > > Network. > > = > > You can do that with the REST API using: > > = > > > > > > > > > [IH] do you assume XML is ordered here? I thought you are not supposed to > do that with XML? That appears to be a common misconception. I thought to too at first, but google yields e.g. http://www.ibm.com/developerworks/xml/library/x-eleord.html The representation is copied from libvirt, so I'll let DV give us the lowdown on element ordering in XML :-) Cheers, Mark. --===============3898051459991729331==-- From tvvcox at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============4981053292697897959==" MIME-Version: 1.0 From: Tomas Von Veschler To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 18:48:10 +0200 Message-ID: <4CA36DCA.4000904@redhat.com> In-Reply-To: 1285777001.3014.167.camel@blaa --===============4981053292697897959== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/29/2010 06:16 PM, Mark McLoughlin wrote: >>> How about set network as boot device, start and immediately change boot >>> device to network. The new boot device will only take effect next time >>> the VM is restarted >> >> Mmm I've tested this approach but it doesn't work as expected. Seems >> that RHEV only takes that change after a VM shutdown. So add vm, start, >> change boot device, install, reboot: the VM will keep booting via networ= k. > > Okay, if that's the case then we definitely need to support RunOnce > support I'm not sure if it's possible to do much from the API. Even with the Run = Once from the RHEV WUI you hit this issue, it's documented here: https://access.redhat.com/kb/docs/DOC-34641 The workaround would need the API to press F12 :-)) Time to ask the RHEV guys I guess. >>>> 2) Specify second boot device. It's not very well documented, but the >>>> Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, >>>> D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not availab= le use >>>> Network. >>> >>> You can do that with the REST API using: >>> >>> >>> >>> >>> >> >> This is what I'm doing now: >> >> 1) Add vm with: >> >> >> >> >> >> 2) start vm >> >> 3) Edit VM to: >> >> >> >> >> A little tricky but does the job :-) Want me to document this? This trick has an obvious problem, you can't use it for re-provisioning VMs. Regards, Tomas --===============4981053292697897959==-- From markmc at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============7160352665390096944==" MIME-Version: 1.0 From: Mark McLoughlin To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 18:04:47 +0100 Message-ID: <1285779887.3014.183.camel@blaa> In-Reply-To: 4CA36DCA.4000904@redhat.com --===============7160352665390096944== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2010-09-29 at 18:48 +0200, Tomas Von Veschler wrote: > On 09/29/2010 06:16 PM, Mark McLoughlin wrote: > = > >>> How about set network as boot device, start and immediately change bo= ot > >>> device to network. The new boot device will only take effect next time > >>> the VM is restarted > >> > >> Mmm I've tested this approach but it doesn't work as expected. Seems > >> that RHEV only takes that change after a VM shutdown. So add vm, start, > >> change boot device, install, reboot: the VM will keep booting via netw= ork. > > > > Okay, if that's the case then we definitely need to support RunOnce > > support > = > I'm not sure if it's possible to do much from the API. Even with the Run = > Once from the RHEV WUI you hit this issue, it's documented here: > = > https://access.redhat.com/kb/docs/DOC-34641 > = > The workaround would need the API to press F12 :-)) The problem here is that if the guest restarts, the VM isn't shutdown and started from its normal configuration Sounds like what RHEV-M needs is to support the equivalent of libvirt's destroy which starts qemu with the -no-reboot flag That way you'd wait for the install to complete and the guest to attempt to reboot. The VM would then stop and you could change the configuration to boot from hd and then start the guest again Cheers, Mark. --===============7160352665390096944==-- From veillard at redhat.com Thu Aug 20 10:04:19 2015 Content-Type: multipart/mixed; boundary="===============0082493498398333900==" MIME-Version: 1.0 From: Daniel Veillard To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 29 Sep 2010 19:47:25 +0200 Message-ID: <20100929174725.GA12771@redhat.com> In-Reply-To: 1285777801.3014.174.camel@blaa --===============0082493498398333900== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Sep 29, 2010 at 05:30:01PM +0100, Mark McLoughlin wrote: > On Wed, 2010-09-29 at 12:21 -0400, Itamar Heim wrote: > > > From: rhevm-api-bounces(a)lists.fedorahosted.org [mailto:rhevm-api- > > > bounces(a)lists.fedorahosted.org] On Behalf Of Mark McLoughlin > > ... > > > > 2) Specify second boot device. It's not very well documented, but t= he > > > > Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, > > > > D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not avai= lable > > use > > > > Network. > > > = > > > You can do that with the REST API using: > > > = > > > > > > > > > > > > > > [IH] do you assume XML is ordered here? I thought you are not supposed = to > > do that with XML? > = > That appears to be a common misconception. I thought to too at first, > but google yields e.g. > = > http://www.ibm.com/developerworks/xml/library/x-eleord.html > = > The representation is copied from libvirt, so I'll let DV give us the > lowdown on element ordering in XML :-) Element ordering, is a priori significant. I.e. any XML parser will need to respect the element order when providing back information to the application. The order of all components of an XML document are significant except for attributes, the order of attributes on an element doesn't matter, e.g.: and are equivalent, an XML processor doesn't need to keep that ordering when providing to the application. Then there is the application semantic, on a given element the application may expect ordering or not, for example in libvirt there is no expected order for elements under . So if you think order of element under is significant, that's just fine, Daniel -- = Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ --===============0082493498398333900==-- From gjansen at redhat.com Thu Aug 20 10:04:20 2015 Content-Type: multipart/mixed; boundary="===============8043267822363906176==" MIME-Version: 1.0 From: Geert Jansen To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Mon, 04 Oct 2010 14:22:44 +0200 Message-ID: <4CA9C714.1070404@redhat.com> In-Reply-To: 1285777001.3014.167.camel@blaa --===============8043267822363906176== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/29/2010 06:16 PM, Mark McLoughlin wrote: > On Wed, 2010-09-29 at 15:21 +0200, Tomas Von Veschler wrote: >> Mmm I've tested this approach but it doesn't work as expected. Seems >> that RHEV only takes that change after a VM shutdown. So add vm, start, >> change boot device, install, reboot: the VM will keep booting via networ= k. > > Okay, if that's the case then we definitely need to support RunOnce > support It seems that RunOnce is a concept in the web UI but not of the API = itself. I wonder how it's implemented. (Go to RHEV-M system and check). = Oh wait, RunOnce doesn't actually do much. The overridden boot order = continues to be in effect across reboots as well, until the system is = hard powered off. Actually this is quite understandable. The boot order = is determined by some configuration setting in the BIOS. To change it = without having to power down, you'd need to POKE those bytes while the = VM is running... Maybe the right place to solve this is in the boot loader instead. Regards, Geert --===============8043267822363906176==-- From gjansen at redhat.com Thu Aug 20 10:04:20 2015 Content-Type: multipart/mixed; boundary="===============1624837295113233033==" MIME-Version: 1.0 From: Geert Jansen To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Mon, 04 Oct 2010 15:10:18 +0200 Message-ID: <4CA9D23A.6020404@redhat.com> In-Reply-To: 20100929174725.GA12771@redhat.com --===============1624837295113233033== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/29/2010 07:47 PM, Daniel Veillard wrote: > On Wed, Sep 29, 2010 at 05:30:01PM +0100, Mark McLoughlin wrote: >> On Wed, 2010-09-29 at 12:21 -0400, Itamar Heim wrote: >>>> From: rhevm-api-bounces(a)lists.fedorahosted.org [mailto:rhevm-api- >>>> bounces(a)lists.fedorahosted.org] On Behalf Of Mark McLoughlin >>> ... >>>>> 2) Specify second boot device. It's not very well documented, but the >>>>> Add-Vm param -DefaultBootSequence accepts two letters being C=3Dhd, >>>>> D=3Dcdrom, N=3Dnetwork, so "CN" would mean boot from HD if not availa= ble >>> use >>>>> Network. >>>> >>>> You can do that with the REST API using: >>>> >>>> >>>> >>>> >>>> >>> [IH] do you assume XML is ordered here? I thought you are not supposed = to >>> do that with XML? >> >> That appears to be a common misconception. I thought to too at first, >> but google yields e.g. >> >> http://www.ibm.com/developerworks/xml/library/x-eleord.html >> >> The representation is copied from libvirt, so I'll let DV give us the >> lowdown on element ordering in XML :-) > > Element ordering, is a priori significant. I.e. any XML parser will > need to respect the element order when providing back information to > the application. The order of all components of an XML document are > significant except for attributes, the order of attributes on an element > doesn't matter, e.g.: > > > and > > > are equivalent, an XML processor doesn't need to keep that ordering when > providing to the application. > Then there is the application semantic, on a given element the > application may expect ordering or not, for example in libvirt there is > no expected order for elements under. > > So if you think order of element under is significant, that's > just fine, I think it's a bad idea if we depend on the order of elements in XML. = Let me re-phrase that. I think it's a bad idea if the information model = we use internally for representing REST resources inside a REST = collection, requires the representation format to be able to preserve = ordering for the construct that would most naturally represent key/value = pairs for that representation format. We will want to serialize to YAML and to JSON, and neither of them = guarantees the order of keys in a dictionary. But we do want to use = their dictionaries for storing key/value pairs. If we stick to the full XML information model as the internal = information model for our resources, then we can get extremely ugly YAML = like this [1]. If we want natural YAML, JSON and XML, we need an = information model that is simpler than that of XML. When i developed the Python API i found this to be quite a hairy = problem. In the end i ended up with the YAML-like information model, = with mandatory types identifiers for dictionaries, and some server-side = knowledge in a few cases where you can't distinguish a sequence from a = dictionary. It's written up colloquially here [2], but it's probably not = 100% correct. I'll try to update it once i get time, until then if = you're interested you may need to read some code as well :) As an example, i wanted a list of VMs to behave like this, in both XML = and YAML: XML: vm1> 512 network harddisk vm2 .... YAML: - !vm id: xxx name: vm1 memory: 512 bootdevices: - network - harddisk - !vm id: aaa name: vm2 ... Other mappings between XML and YAML exist, but i found none of them to = yield the natural YAML that i was looking for. [1] = http://svn.pyyaml.org/pyyaml-legacy/trunk/experimental/XmlYaml/README_yaml2= xml [2] http://bitbucket.org/geertj/python-rest/wiki/ReferenceGuide Regards, -- = Geert Jansen Product Marketing Manager, Red Hat Enterprise Virtualization Red Hat S.r.L. T: +39 348 1980079 Via Antonio da Recanate 1 E: gjansen(a)redhat.com Milan 20124, Italy --===============1624837295113233033==-- From markmc at redhat.com Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============5711925097935318871==" MIME-Version: 1.0 From: Mark McLoughlin To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Tue, 12 Oct 2010 17:24:00 +0100 Message-ID: <1286900640.22526.301.camel@blaa> In-Reply-To: 4CA9C714.1070404@redhat.com --===============5711925097935318871== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, 2010-10-04 at 14:22 +0200, Geert Jansen wrote: > On 09/29/2010 06:16 PM, Mark McLoughlin wrote: > > On Wed, 2010-09-29 at 15:21 +0200, Tomas Von Veschler wrote: > = > >> Mmm I've tested this approach but it doesn't work as expected. Seems > >> that RHEV only takes that change after a VM shutdown. So add vm, start, > >> change boot device, install, reboot: the VM will keep booting via netw= ork. > > > > Okay, if that's the case then we definitely need to support RunOnce > > support > = > It seems that RunOnce is a concept in the web UI but not of the API = > itself. I wonder how it's implemented. (Go to RHEV-M system and check). = > Oh wait, RunOnce doesn't actually do much. The overridden boot order = > continues to be in effect across reboots as well, until the system is = > hard powered off. Actually this is quite understandable. The boot order = > is determined by some configuration setting in the BIOS. To change it = > without having to power down, you'd need to POKE those bytes while the = > VM is running... > = > Maybe the right place to solve this is in the boot loader instead. There's prior art here - virt-manager, virtinst and libvirt conspire to do this by starting the VM with: destroy so that when the guest reboot's, it actually shuts down completely and virt-manager explicitly re-starts it with the boot loader configuration changed. RHEV-M needs to support something like like libvirt's Cheers, Mark. --===============5711925097935318871==-- From markmc at redhat.com Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============8898913467946012162==" MIME-Version: 1.0 From: Mark McLoughlin To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Tue, 12 Oct 2010 17:34:39 +0100 Message-ID: <1286901279.22526.304.camel@blaa> In-Reply-To: 4CA9D23A.6020404@redhat.com --===============8898913467946012162== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Geert, On Mon, 2010-10-04 at 15:10 +0200, Geert Jansen wrote: > On 09/29/2010 07:47 PM, Daniel Veillard wrote: ... > > So if you think order of element under is significant, that's > > just fine, > = > I think it's a bad idea if we depend on the order of elements in XML. = > Let me re-phrase that. I think it's a bad idea if the information model = > we use internally for representing REST resources inside a REST = > collection, requires the representation format to be able to preserve = > ordering for the construct that would most naturally represent key/value = > pairs for that representation format. Okay, I think I agree with that, but ... ... > YAML: > = > - !vm > id: xxx > name: vm1 > memory: 512 > bootdevices: > - network > - harddisk This would come out as: {'bootdevices': ['network', 'harddisk'], 'id': 'xxx', 'name': 'vm1', 'memor= y': 512} i.e. the order of the keys isn't available, but the order of the list of boot devices *is* maintained. It is a list, not a key/value set ... right? Cheers, Mark. --===============8898913467946012162==-- From berrange at redhat.com Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============3377592387046086455==" MIME-Version: 1.0 From: Daniel P. Berrange To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Tue, 12 Oct 2010 17:41:52 +0100 Message-ID: <20101012164152.GK3922@redhat.com> In-Reply-To: 1286901279.22526.304.camel@blaa --===============3377592387046086455== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Oct 12, 2010 at 05:34:39PM +0100, Mark McLoughlin wrote: > Hi Geert, > = > On Mon, 2010-10-04 at 15:10 +0200, Geert Jansen wrote: > > On 09/29/2010 07:47 PM, Daniel Veillard wrote: > ... > > > So if you think order of element under is significant, that's > > > just fine, > > = > > I think it's a bad idea if we depend on the order of elements in XML. = > > Let me re-phrase that. I think it's a bad idea if the information model = > > we use internally for representing REST resources inside a REST = > > collection, requires the representation format to be able to preserve = > > ordering for the construct that would most naturally represent key/valu= e = > > pairs for that representation format. > = > Okay, I think I agree with that, but ... > = > ... > > YAML: > > = > > - !vm > > id: xxx > > name: vm1 > > memory: 512 > > bootdevices: > > - network > > - harddisk > = > This would come out as: > = > {'bootdevices': ['network', 'harddisk'], 'id': 'xxx', 'name': 'vm1', 'mem= ory': 512} > = > i.e. the order of the keys isn't available, but the order of the list of > boot devices *is* maintained. It is a list, not a key/value set ... > right? Yes, in YAML terminology, you've represented bootdevices as a 'sequence' so ordering is preserved there. Daniel -- = |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/= :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org= :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/= :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505= :| --===============3377592387046086455==-- From markllama at redhat.com Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============5034225259093880681==" MIME-Version: 1.0 From: Mark Lamourine To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Tue, 12 Oct 2010 15:56:58 -0400 Message-ID: <1182924494.351431286913418778.JavaMail.root@zmail03.collab.prod.int.phx2.redhat.com> In-Reply-To: 20101012164152.GK3922@redhat.com --===============5034225259093880681== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- "Daniel P. Berrange" wrote: > On Tue, Oct 12, 2010 at 05:34:39PM +0100, Mark McLoughlin wrote: > > Hi Geert, > > = > > On Mon, 2010-10-04 at 15:10 +0200, Geert Jansen wrote: > > > On 09/29/2010 07:47 PM, Daniel Veillard wrote: > > ... > > > > So if you think order of element under is significant, > that's > > > > just fine, > > > = > > > I think it's a bad idea if we depend on the order of elements in > XML. = > > > Let me re-phrase that. I think it's a bad idea if the information > model = > > > we use internally for representing REST resources inside a REST = > > > collection, requires the representation format to be able to > preserve = > > > ordering for the construct that would most naturally represent > key/value = > > > pairs for that representation format. > > = I don't see the boot order as naturally being represented as a key/value pa= ir. XML, YAML and client side Array like constructs all preserve order. = What I would object to is making one of those elements *special* by virtue = of it's location. Preserve the order of the elements in the boot list, but create a separate = value somewhere indicating "boot from this one" even if it always refers to the 0th one. Magic Values or Magic Locations are not a good idea. > > Okay, I think I agree with that, but ... > > = > > ... > > > YAML: > > > = > > > - !vm > > > id: xxx > > > name: vm1 > > > memory: 512 > > > bootdevices: > > > - network > > > - harddisk > > = > > This would come out as: > > = > > {'bootdevices': ['network', 'harddisk'], 'id': 'xxx', 'name': 'vm1', > 'memory': 512} > > = > > i.e. the order of the keys isn't available, but the order of the > list of > > boot devices *is* maintained. It is a list, not a key/value set ... > > right? > = > Yes, in YAML terminology, you've represented bootdevices as a > 'sequence' > so ordering is preserved there. > = > Daniel > -- = > |: Red Hat, Engineering, London -o- = > http://people.redhat.com/berrange/ :| > |: http://libvirt.org -o- http://virt-manager.org -o- > http://deltacloud.org :| > |: http://autobuild.org -o- = > http://search.cpan.org/~danberr/ :| > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B > 9505 :| > _______________________________________________ > rhevm-api mailing list > rhevm-api(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/rhevm-api -- = Mark Lamourine Sr. Software Developer, Cloud Engineering Red Hat, 314 Littleton Road, Westford MA 01886 Voice: +1 978 392 1093 http://people.redhat.com/~mlamouri markllama @ irc://irc.freenod.org*lopsa --===============5034225259093880681==-- From sander at hoentjen.eu Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============3490702183437277890==" MIME-Version: 1.0 From: Sander Hoentjen To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 13 Oct 2010 11:03:50 +0200 Message-ID: <1286960630.3118.9.camel@peecee.hoentjen.eu> In-Reply-To: 1182924494.351431286913418778.JavaMail.root@zmail03.collab.prod.int.phx2.redhat.com --===============3490702183437277890== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, 2010-10-12 at 15:56 -0400, Mark Lamourine wrote: > ----- "Daniel P. Berrange" wrote: > = > > On Tue, Oct 12, 2010 at 05:34:39PM +0100, Mark McLoughlin wrote: > > > Hi Geert, > > > = > > > On Mon, 2010-10-04 at 15:10 +0200, Geert Jansen wrote: > > > > On 09/29/2010 07:47 PM, Daniel Veillard wrote: > > > ... > > > > > So if you think order of element under is significant, > > that's > > > > > just fine, > > > > = > > > > I think it's a bad idea if we depend on the order of elements in > > XML. = > > > > Let me re-phrase that. I think it's a bad idea if the information > > model = > > > > we use internally for representing REST resources inside a REST = > > > > collection, requires the representation format to be able to > > preserve = > > > > ordering for the construct that would most naturally represent > > key/value = > > > > pairs for that representation format. > > > = > = > I don't see the boot order as naturally being represented as a key/value = pair. > = > XML, YAML and client side Array like constructs all preserve order. = > = > What I would object to is making one of those elements *special* by virtu= e of it's location. > = > Preserve the order of the elements in the boot list, but create a separat= e value somewhere indicating "boot from this one" > even if it always refers to the 0th one. But then you would have to have: "boot from this one first, if that doesn't work, try this one, if that doesn't work, try this one" so you end up with an ordered list. No item in the list is special, but the order is important. > Magic Values or Magic Locations are not a good idea. Agreed, but if you say ordering is important, it is not really magic, is it? --===============3490702183437277890==-- From markllama at redhat.com Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============9026667499968328438==" MIME-Version: 1.0 From: Mark Lamourine To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Thu, 14 Oct 2010 08:33:50 -0400 Message-ID: <1849908258.579461287059630347.JavaMail.root@zmail03.collab.prod.int.phx2.redhat.com> In-Reply-To: 1286960630.3118.9.camel@peecee.hoentjen.eu --===============9026667499968328438== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ... > > I don't see the boot order as naturally being represented as a > key/value pair. > > = > > XML, YAML and client side Array like constructs all preserve order. = > = > > = > > What I would object to is making one of those elements *special* by > virtue of it's location. > > = > > Preserve the order of the elements in the boot list, but create a > separate value somewhere indicating "boot from this one" > > even if it always refers to the 0th one. > But then you would have to have: > "boot from this one first, if that doesn't work, try this one, if > that > doesn't work, try this one" so you end up with an ordered list. No > item > in the list is special, but the order is important. > > Magic Values or Magic Locations are not a good idea. > Agreed, but if you say ordering is important, it is not really magic, > is > it? You know, I could roll with that. I'm not sure if it's in the current RHEVM functionality, but I was confusin= g "on a normal boot, here are the devices in the order they should be tried= " and "this time is special, use device X, where X may not be device 0 in t= he list". - Mark -- = Mark Lamourine Sr. Software Developer, Cloud Engineering Red Hat, 314 Littleton Road, Westford MA 01886 Voice: +1 978 392 1093 http://people.redhat.com/~mlamouri markllama @ irc://irc.freenod.org*lopsa --===============9026667499968328438==-- From sander at hoentjen.eu Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============9036178842451622794==" MIME-Version: 1.0 From: Sander Hoentjen To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Thu, 14 Oct 2010 16:50:43 +0200 Message-ID: <1a1c82c5cef8e023623fe524b7c282a4@192.168.1.34> In-Reply-To: 1849908258.579461287059630347.JavaMail.root@zmail03.collab.prod.int.phx2.redhat.com --===============9036178842451622794== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, 14 Oct 2010 08:33:50 -0400 (EDT), Mark Lamourine wrote: > ... > = >> > I don't see the boot order as naturally being represented as a >> key/value pair. >> > = >> > XML, YAML and client side Array like constructs all preserve order. = >> = >> > = >> > What I would object to is making one of those elements *special* by >> virtue of it's location. >> > = >> > Preserve the order of the elements in the boot list, but create a >> separate value somewhere indicating "boot from this one" >> > even if it always refers to the 0th one. > = >> But then you would have to have: >> "boot from this one first, if that doesn't work, try this one, if >> that >> doesn't work, try this one" so you end up with an ordered list. No >> item >> in the list is special, but the order is important. > = >> > Magic Values or Magic Locations are not a good idea. > = >> Agreed, but if you say ordering is important, it is not really magic, >> is >> it? > = > You know, I could roll with that. > = > I'm not sure if it's in the current RHEVM functionality, but I was > confusing "on a normal boot, here are the devices in the order they should > be tried" and "this time is special, use device X, where X may not be > device 0 in the list". > In RHEV you have both: normally try these devices in this order, and this time, try these devices in this order (where both times the list of devices can be of length 1 of course) --===============9036178842451622794==-- From gjansen at redhat.com Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============1825901424169232810==" MIME-Version: 1.0 From: Geert Jansen To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Tue, 26 Oct 2010 18:43:04 +0200 Message-ID: <4CC70518.4010308@redhat.com> In-Reply-To: 1a1c82c5cef8e023623fe524b7c282a4@192.168.1.34 --===============1825901424169232810== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 10/14/2010 04:50 PM, Sander Hoentjen wrote: >> I'm not sure if it's in the current RHEVM functionality, but I was >> confusing "on a normal boot, here are the devices in the order they > should >> be tried" and "this time is special, use device X, where X may not be >> device 0 in the list". >> > In RHEV you have both: normally try these devices in this order, and this > time, try these devices in this order (where both times the list of devic= es > can be of length 1 of course) What attributes correspond to these two lists (in PowerShell)? I wasn't = aware we had the second list you mention. I can see how it can be useful = when doing kickstarts etc. Regards, -- = Geert Jansen Product Marketing Manager, Red Hat Enterprise Virtualization Red Hat S.r.L. T: +39 348 1980079 Via Antonio da Recanate 1 E: gjansen(a)redhat.com Milan 20124, Italy --===============1825901424169232810==-- From markmc at redhat.com Thu Aug 20 10:04:21 2015 Content-Type: multipart/mixed; boundary="===============6618987498548047026==" MIME-Version: 1.0 From: Mark McLoughlin To: rhevm-api at lists.fedorahosted.org Subject: Re: [rhevm-api] VM start action issues Date: Wed, 27 Oct 2010 08:40:39 +0100 Message-ID: <1288165239.2906.97.camel@blaa> In-Reply-To: 4CC70518.4010308@redhat.com --===============6618987498548047026== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, 2010-10-26 at 18:43 +0200, Geert Jansen wrote: > On 10/14/2010 04:50 PM, Sander Hoentjen wrote: > = > >> I'm not sure if it's in the current RHEVM functionality, but I was > >> confusing "on a normal boot, here are the devices in the order they > > should > >> be tried" and "this time is special, use device X, where X may not be > >> device 0 in the list". > >> > > In RHEV you have both: normally try these devices in this order, and th= is > > time, try these devices in this order (where both times the list of dev= ices > > can be of length 1 of course) > = > What attributes correspond to these two lists (in PowerShell)? I wasn't = > aware we had the second list you mention. I can see how it can be useful = > when doing kickstarts etc. You've got: :> add-vm -defaultbootsequence CDN and then: :> start-vm -bootdevice NC The latter is the same as the "Run Once" concept in the UI Cheers, Mark. --===============6618987498548047026==--