<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi all,<br>sorry for the late reply.<br><br>I noticed that I missed the deviceId property on my additional-nic line below, but I can confirm that the engine vm (installed with my previously modified template in /usr/share/ovirt-hosted-engine-setup/templates/vm.conf.in as outlined below) is still up and running (apparently) ok without it (I verified that the deviceId property has not been added automatically in /etc/ovirt-hosted-engine/vm.conf).<br><br>I admit that modifying a package file not marked as configuration (under /usr/share... may the FHS forgive me... :) is not best practice, but modifying the configuration one (under /etc...) afterwards seemed more error prone (needs propagation to further nodes).<br><br>In order to have a clear picture of the matter (and write/add-to a wiki page on engine vm customization) I'd like to read more on the syntax of these vm.conf files (they are neither libvirt XML files nor OTOPI files) and which properties are default/needed/etc.<br><br>From simple analogy, as an example, I thought that an unique index property would be needed (as in ide/virtio disk devices) for adding a nic, but Andrew example does not add it...<br><br>Any pointers to doc/code for further enlightenment?<br><br>Many thanks in advance,<br>Giuseppe<br><br><div>> Date: Thu, 10 Apr 2014 08:40:25 +0200<br>> From: sbonazzo@redhat.com<br>> To: andrew@andrewklau.com<br>> CC: giuseppe.ragusa@hotmail.com; josh@wrale.com; users@ovirt.org<br>> Subject: Re: [Users] Post-Install Engine VM Changes Feasible?<br>> <br>> <br>> <br>> Hi,<br>> <br>> <br>> Il 10/04/2014 02:40, Andrew Lau ha scritto:<br>> > On Tue, Apr 8, 2014 at 8:52 PM, Andrew Lau <andrew@andrewklau.com> wrote:<br>> >> On Mon, Mar 17, 2014 at 8:01 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:<br>> >>> Il 15/03/2014 12:44, Giuseppe Ragusa ha scritto:<br>> >>>> Hi Joshua,<br>> >>>><br>> >>>> ------------------------------------------------------------------------------------------------------------------------------------------------------<br>> >>>> Date: Sat, 15 Mar 2014 02:32:59 -0400<br>> >>>> From: josh@wrale.com<br>> >>>> To: users@ovirt.org<br>> >>>> Subject: [Users] Post-Install Engine VM Changes Feasible?<br>> >>>><br>> >>>> Hi,<br>> >>>><br>> >>>> I'm in the process of installing 3.4 RC(2?) on Fedora 19. I'm using hosted engine, introspective GlusterFS+keepalived+NFS ala [1], across six nodes.<br>> >>>><br>> >>>> I have a layered networking topology ((V)LANs for public, internal, storage, compute and ipmi). I am comfortable doing the bridging for each<br>> >>>> interface myself via /etc/sysconfig/network-scripts/ifcfg-*.<br>> >>>><br>> >>>> Here's my desired topology: http://www.asciiflow.com/#Draw6325992559863447154<br>> >>>><br>> >>>> Here's my keepalived setup: https://gist.github.com/josh-at-knoesis/98618a16418101225726<br>> >>>><br>> >>>> I'm writing a lot of documentation of the many steps I'm taking. I hope to eventually release a distributed introspective all-in-one (including<br>> >>>> distributed storage) guide.<br>> <br>> I hope you'll publish it also on ovirt.org wiki :-)<br>> <br>> >>>><br>> >>>> Looking at vm.conf.in <http://vm.conf.in>, it looks like I'd by default end up with one interface on my engine, probably on my internal VLAN, as<br>> >>>> that's where I'd like the control traffic to flow. I definitely could do NAT, but I'd be most happy to see the engine have a presence on all of the<br>> >>>> LANs, if for no other reason than because I want to send backups directly over the storage VLAN.<br>> >>>><br>> >>>> I'll cut to it: I believe I could successfully alter the vdsm template (vm.conf.in <http://vm.conf.in>) to give me the extra interfaces I require.<br>> >>>> It hit me, however, that I could just take the defaults for the initial install. Later, I think I'll be able to come back with virsh and make my<br>> >>>> changes to the gracefully disabled VM. Is this true?<br>> >>>><br>> >>>> [1] http://www.andrewklau.com/ovirt-hosted-engine-with-3-4-0-nightly/<br>> >>>><br>> >>>> Thanks,<br>> >>>> Joshua<br>> >>>><br>> >>>><br>> >>>> I started from the same reference[1] and ended up "statically" modifying vm.conf.in before launching setup, like this:<br>> >>>><br>> >>>> cp -a /usr/share/ovirt-hosted-engine-setup/templates/vm.conf.in /usr/share/ovirt-hosted-engine-setup/templates/vm.conf.in.orig<br>> >>>> cat << EOM > /usr/share/ovirt-hosted-engine-setup/templates/vm.conf.in<br>> >>>> vmId=@VM_UUID@<br>> >>>> memSize=@MEM_SIZE@<br>> >>>> display=@CONSOLE_TYPE@<br>> >>>> devices={index:2,iface:ide,address:{ controller:0, target:0,unit:0, bus:1,<br>> >>>> type:drive},specParams:{},readonly:true,deviceId:@CDROM_UUID@,path:@CDROM@,device:cdrom,shared:false,type:disk@BOOT_CDROM@}<br>> >>>> devices={index:0,iface:virtio,format:raw,poolID:@SP_UUID@,volumeID:@VOL_UUID@,imageID:@IMG_UUID@,specParams:{},readonly:false,domainID:@SD_UUID@,optional:false,deviceId:@IMG_UUID@,address:{bus:0x00,<br>> >>>> slot:0x06, domain:0x0000, type:pci, function:0x0},device:disk,shared:exclusive,propagateErrors:off,type:disk@BOOT_DISK@}<br>> >>>> devices={device:scsi,model:virtio-scsi,type:controller}<br>> >>>> devices={index:4,nicModel:pv,macAddr:@MAC_ADDR@,linkActive:true,network:@BRIDGE@,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:@NIC_UUID@,address:{bus:0x00,<br>> >>>> slot:0x03, domain:0x0000, type:pci, function:0x0},device:bridge,type:interface@BOOT_PXE@}<br>> >>>> devices={index:8,nicModel:pv,macAddr:02:16:3e:4f:c4:b0,linkActive:true,network:lan,filter:vdsm-no-mac-spoofing,specParams:{},address:{bus:0x00,<br>> >>>> slot:0x09, domain:0x0000, type:pci, function:0x0},device:bridge,type:interface@BOOT_PXE@}<br>> >>>> devices={device:console,specParams:{},type:console,deviceId:@CONSOLE_UUID@,alias:console0}<br>> >>>> vmName=@NAME@<br>> >>>> spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,srecord,ssmartcard,susbredir<br>> >>>> smp=@VCPUS@<br>> >>>> cpuType=@CPU_TYPE@<br>> >>>> emulatedMachine=@EMULATED_MACHINE@<br>> >>>> EOM<br>> >>><br>> >>><br>> >>> Note that you should also be able to edit /etc/ovirt-hosted-engine/vm.conf after setup:<br>> >>> - put the system in global maintenance<br>> >>> - edit the vm.conf file on all the hosts running the hosted engine<br>> >>> - shutdown the vm: hosted-engine --vm-shutdown<br>> >>> - start again the vm: hosted-engine --vm-start<br>> >>> - exit global maintenance<br>> >>><br>> >>> Giuseppe, Joshua: can you share your changes in a guide for Hosted engine users on ovirt.org wiki?<br>> >>><br>> >>><br>> >><br>> >> So would you simply just add a new line under the original devices line? ie.<br>> >> devices={nicModel:pv,macAddr:00:16:3e:6d:34:78,linkActive:true,network:ovirtmgmt,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:0c8a1710-casd-407a-94e8-5b09e55fa141,address:{bus:0x00,<br>> >> slot:0x03, domain:0x0000, type:pci,<br>> >> function:0x0},device:bridge,type:interface}<br>> >><br>> >> Are there any good practices for getting the mac addr so it won't be<br>> >> possible to clash with ones vdsm would generate? I assume the same<br>> >> applies for deviceid?<br>> >> Did you also change the slot?<br>> >><br>> > <br>> > This worked successfully:<br>> > <br>> > yum -y install python-virtinst<br>> > <br>> > # generate uuid and mac address<br>> > echo 'import virtinst.util ; print<br>> > virtinst.util.uuidToString(virtinst.util.randomUUID())' | python<br>> > echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python<br>> > <br>> > hosted-engine --set-maintenance --mode=global<br>> > nano /etc/ovirt-hosted-engine/vm.conf<br>> > # insert under earlier nicModel<br>> > # replace macaddress and uuid from above<br>> > # increment slot (so it's not the same as above nicModel)<br>> > # modify ovirtmgmt to desired bridge interface<br>> > <br>> > devices={nicModel:pv,macAddr:00:16:3e:35:87:7d,linkActive:true,network:storage_network,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:4c32c036-0e5a-e0b3-9ba7-bg3dfzbs40ae,address:{bus:0x00,slot:0x04,<br>> > domain:0x0000, type:pci,function:0x0},device:bridge,type:interface}<br>> > <br>> > hosted-engine --vm-shutdown<br>> > hosted-engine --vm-start<br>> > <br>> > hosted-engine --set-maintenance --mode=none<br>> > <br>> > However, this won't get propagated to any additional hosts that are<br>> > installed. I'm guessing it may be this file<br>> > /usr/share/ovirt-hosted-engine-setup/templates/vm.conf.in that gets<br>> > copied for new installs, but I don't have any new hosts to test with<br>> > right now.<br>> <br>> A few comments on above discussion:<br>> <br>> MAC address for Hosted Engine VM is already generated randomly by hosted-engine --deploy command and proposed as default in the question:<br>> <br>> 'You may specify a MAC address for the VM or accept a randomly generated default [@DEFAULT@]: '<br>> <br>> So it shouldn't be necessary to generate another one.<br>> However, you can set the MAC address at interactive setup or by creating an answer.conf file with the following content:<br>> <br>> [environment:default]<br>> OVEHOSTED_VM/vmMACAddr=str:00:16:3e:72:85:3f<br>> <br>> changing above mac address with whatever you want and running<br>> hosted-engine --deploy --config-append=answer.conf<br>> <br>> Note that if you change /etc/ovirt-hosted-engine/vm.conf after deployment you must also update /etc/ovirt-hosted-engine/answers.conf<br>> in order to have additional host to get the same configuration when you run hosted-engine --deploy.<br>> Additional host already deployed need to be updated manually.<br>> <br>> Remember also that if there's interest in adding configuration steps while deploying you can open an RFE on bugzilla.<br>> <br>> I created an etherpad to allow you to list post install changes to vm.conf, so I can get a clue on what we're missing there.<br>> http://etherpad.ovirt.org/p/hosted-engine-post-install-changes<br>> <br>> <br>> > <br>> >>><br>> >>>><br>> >>>> I simply added a second nic (with a fixed MAC address from the locally-administered pool, since I didn't know how to auto-generate one) and added an<br>> >>>> index for nics too (mimicking the the storage devices setup already present).<br>> >>>><br>> >>>> My network setup is much simpler than yours: ovirtmgmt bridge is on an isolated oVirt-management-only network without gateway, my actual LAN with<br>> >>>> gateway and Internet access (for package updates/installation) is connected to lan bridge and the SAN/migration LAN is a further (not bridged) 10<br>> >>>> Gib/s isolated network for which I do not expect to need Engine/VMs reachability (so no third interface for Engine) since all actions should be<br>> >>>> performed from Engine but only through vdsm hosts (I use a "split-DNS" setup by means of carefully crafted hosts files on Engine and vdsm hosts)<br>> >>>><br>> >>>> I can confirm that the engine vm gets created as expected and that network connectivity works.<br>> >>>><br>> >>>> Unfortunately I cannot validate the whole design yet, since I'm still debugging HA-agent problems that prevent a reliable Engine/SD startup.<br>> >>>><br>> >>>> Hope it helps.<br>> >>>><br>> >>>> Greetings,<br>> >>>> Giuseppe<br>> >>>><br>> >>>><br>> >>>><br>> >>>> _______________________________________________<br>> >>>> Users mailing list<br>> >>>> Users@ovirt.org<br>> >>>> http://lists.ovirt.org/mailman/listinfo/users<br>> >>>><br>> >>><br>> >>><br>> >>> --<br>> >>> Sandro Bonazzola<br>> >>> Better technology. Faster innovation. Powered by community collaboration.<br>> >>> See how it works at redhat.com<br>> >>> _______________________________________________<br>> >>> Users mailing list<br>> >>> Users@ovirt.org<br>> >>> http://lists.ovirt.org/mailman/listinfo/users<br>> <br>> <br>> -- <br>> Sandro Bonazzola<br>> Better technology. Faster innovation. Powered by community collaboration.<br>> See how it works at redhat.com<br></div> </div></body>
</html>