Re: [ovirt-users] python floppy in RunOnce mode

Il 23/10/2014 20:59, Juan Hernandez ha scritto: > On 10/23/2014 09:40 AM, Giulio Casella wrote: >> Hi, >> I'm trying to boot a vm with non persistent floppy using python ovirt >> sdk (the "RunOnce" way in administrator portal), but guest OS can't see >> floppy drive. The ultimate goal is to deploy floppy with sysprep >> unattend.xml file for windows 7 pools of vm. >> >> Here is a snippet of code I use: >> >> ------------------------------------------------- >> myvm = api.vms.get(name="vmname") >> content="This is file content!" >> f=params.File(name="foobar.txt",content=content) >> fs=params.Files() >> fs.add_file(f) >> payload=params.Payload() >> payload.set_type("floppy") >> payload.set_files(fs) >> payloads=params.Payloads() >> payloads.add_payload(payload) >> thevm=params.VM() >> thevm.set_payloads(payloads) >> action=params.Action(vm=thevm) >> >> myvm.start(action=action) >> >> xml = ParseHelper.toXml(action) >> print xml >> ------------------------------------------------- >> >> As you can see, for debugging purpose, I print my xml action, and I get: >> >> ------------------------------------------------- >> <action> >> <vm> >> <payloads> >> <payload type="floppy"> >> <files> >> <file> >> <name>foobar.txt</name> >> <content>This is file content</content> >> </file> >> </files> >> </payload> >> </payloads> >> </vm> >> </action> >> ------------------------------------------------- >> >> in the admin portal I can see my vm in "RunOnce" state, but no floppy is >> present... >> In fact in the vm process command line >> (ps -ef | grep qemu-kvm | grep vmname) I can't see -drive option >> referring to floppy (I only see 2 "-drive" options, referring to vm >> system disk and to a correctly mounted cdrom ISO) >> >> What I'm doing wrong? >> >> (The engine is RHEV-M version 3.4.1-0.31.el6ev) >> > > The problem is that using non persistent payloads isn't currently > supported, so basically your "payloads" element is silently ignored. You > have currently two alternatives: > > 1. Use persistent payloads: > > vm = vms.get(name="myvm") > vm.set_payloads(paylaods) > vm.update() > vm.start(params.Action()) > > You may also want to remove the payloads once the machine is configured, > but this isn't strictly required, as Windows will not try to locate the > sysprep floppy in subsequent boots. The only minor inconvenient is that > the users of the VMs will see the floopy and its content attached. > Yes, this is exactly the workaround I'm currently using, and I have to hide floppy via AD group policy (sysprep.inf contains administrator password). > 2. Use the builtin sysprep files (they are in > /usr/share/ovirt-engine/conf/sysprep): > > vm = vms.get(name="myvm") > initialization = params.Initialization() > vm.set_initialization(initialization) > vm.update() > vm.start(params.Action()) > > This has the advantage that the sysprep floppy will be attached to the > VM only the first time it is booted. In subsequent boots it won't be > attached. > Great hint, I'll take a look into those syspreps to see if they fit for my setup. > In 3.5 you will also be able to use sysprep support with your custom file: > > vm = vms.get(name="myvm") > initialization = params.Initialization( > custom_script="The text of your sysprep file" > ) > vm.set_initialization(initialization) > vm.update() > vm.start(params.Action()) > Good new, eventually I'll wait for RHEV 3.5 > Note that currently (in 3.4 and in 3.5) there is an issue with the name > of the file generated by the built-in sysprep support: it will always be > named "sysprep.inf", regardless of the operating system assigned to the > VM. If you want to use recent versions of Windows it has to be named > "Unattend.xml", so you will need to change the Windows template before > sealing it, adding the following registry entry: > > HKEY-LOCAL-MACHINE -> SYSTEM -> Setup -> UnattendFile = sysprep.inf > > There is a bug open to avoid this: > > https://bugzilla.redhat.com/1145999 > > Note also that the builtin sysprep support will only trigger if the VM > has been assigned a Windows operating system. > Yes, I knew. Do you know if is there a plan to change this behaviour (e.g. generate filename according to guest O.S. standard)?