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

I can see this behaviour in ovirt 3.5 environment (ovirt-engine-3.5.0.1-1.el6) and in rhev 3.4 environment (rhevm-3.4.3-1.2.el6ev). I'm stuck, what I'm doing wrong? :-(

Il 23/12/2014 10:16, Giulio Casella ha scritto: > Yes, the VM is windows 7: > > print myvm.get_os().get_type() > > shows "windows_7x64" > > Anyway I tried to force it, as you suggested, but with no luck... > > > Il 22/12/2014 17:52, Juan Hernández ha scritto: >> On 12/22/2014 01:21 PM, Giulio Casella wrote: >>> Hi Juan, >>> I tried to use builtin sysprep files, with no luck. >>> Here is my code: >>> >>> myvm = api.vms.get(name="vmname") >>> initialization = params.Initialization() >>> myvm.set_initialization(initialization) >>> myvm.update() >>> myvm.start(params.Action()) >>> >>> Virtual Machine starts, but there is no mounted floppy. >>> VM is a freshly installed Windows 7 x86_64, with ovirt guest agent and >>> no other software. >>> >>> Any ideas? >>> >>> Giulio >>> >> >> Is the operating system of the set to one of the Windows variants? If it >> isn't set to a Windows variant then the Sysprep logic won't trigger. To >> make sure you can update the OS from the script: >> >> myvm = api.vms.get(name="vmname") >> initialization = params.Initialization() >> myvm.set_initialization(initialization) >> myvm.set_os( >> params.OperatingSystem( >> type_="windows_7x64" >> ) >> ) >> myvm.update() >> myvm.start(params.Action()) >> >>> Il 24/10/2014 16:08, Giulio Casella ha scritto: >>>> 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)? >>>> >>>> Many thanks, >>>> Giulio >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>> >> >> >