[ovirt-users] python floppy in RunOnce mode

Juan Hernández jhernand at redhat.com
Mon Dec 22 16:52:03 UTC 2014


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 at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.



More information about the Users mailing list