Darryl, ovirt-identify-node sends the hardware UUID to the ovirt-server as part of the startup process. On F10 it looks like the fake nodes that run in kvm have an empty UUID that causes the server to fail because it's expecting a parameter there.> [root at node3 ~]# lshal | grep uuid > system.hardware.uuid = '' (string)Do we rely on UUID for anything or is it just purely an informational parameter? If we don't rely on it for anything we should accept a blank string as valid input. If we are relying on it, we should reconsider perhaps. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|
Perry Myers <pmyers at redhat.com> wrote:> Darryl, > > ovirt-identify-node sends the hardware UUID to the ovirt-server as > part of the startup process. On F10 it looks like the fake nodes that > run in kvm have an empty UUID that causes the server to fail because > it's expecting a parameter there. > >> [root at node3 ~]# lshal | grep uuid >> system.hardware.uuid = '' (string) > > Do we rely on UUID for anything or is it just purely an informational > parameter? If we don't rely on it for anything we should accept a > blank string as valid input. If we are relying on it, we should > reconsider perhaps.Hi Perry, That means we need a newer qemu in F10. libvirt sets the guest's UUID via -uuid if it sees that qemu's --help output mentions that option. But F10's qemu-0.9.1-10.fc10.x86_64 does *not* support the -uuid option that's been in upstream qemu since mid September.
Perry Myers wrote:> Darryl, > > ovirt-identify-node sends the hardware UUID to the ovirt-server as part > of the startup process. On F10 it looks like the fake nodes that run in > kvm have an empty UUID that causes the server to fail because it's > expecting a parameter there. > >> [root at node3 ~]# lshal | grep uuid >> system.hardware.uuid = '' (string) > > Do we rely on UUID for anything or is it just purely an informational > parameter? If we don't rely on it for anything we should accept a blank > string as valid input. If we are relying on it, we should reconsider > perhaps.It must be optional, it's not guaranteed to be present even on real HW machines, so ovirt-host-brower should be fixed. That said, as JimM found out, libvirt's check for --uuid parameter seems wrong: qemu-kvm has it but check is performed against plain qemu binary - that needs to be BZed against libvirt.