Re: [PATCH v3 2/3] qemu : Add loadparm to qemu command line string

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 05/26/2017 04:03 PM, John Ferlan wrote:


...

Was there ever thought to adding loadparm to the machine XML? What's the
reasoning to not have it there.  If it's only valid for bootindex=1,
then it's far easier to check if the machine XML has it defined rather
than perusing the disk/network lists (which could be lengthy) only to
fine none.  If the concern is some other arch allowing a different
bootindex to have loadparm, then the simple decision there is to have a
"loadparm_bootindex=#" value that would match the disk bootindex=# value.


I am not sure what you mean here? By machine xml do you mean <os> xml?


Sorry I was too lazy to go make the cross reference near the end of the
day/review. Guess I was thinking more <os> related though...

I see in <os> there's a <boot> subelement which has a relationship with
the <boot> subelement for <devices>...[<interface>|<disk>]...


Yes, the <os> has <boot> subelement, but it can be tricky to specify the order of the boot device.

I think I was just trying to make sure that adding <loadparm> to
<devices> would make sense "in the long run" and what other
implementations were considered and not taken because of some drawback.


The per device boot subelement was added to simplify the boot device order. That's why I thought it made more sense to add it to the per device boot element. Also from a user's perspective it's easier to specify the loadparm when specifying the boot order.

Given the description I've read and the implementation that searches
either disk or network lists looking for bootIndex = 1, I wonder if the
<os> <boot dev='xxx' > should be modified instead.  Was that considered
- what were the drawbacks?   Can bootparm conceptually be added/used for
a non boot disk?


I'm not requesting one way or another - I'd just like to be sure the
question is answered before perhaps someone else asks it now or much
later when this isn't so fresh in your mind.

John



--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux