7 thoughts on - Qemu-kvm Rebuild In CentOS For OVirt In SIG Virt

• Is the plan to get the qemu-kvm build provided by CentOS to include the “rhev-features”? I recently updated to oVirt 4.1 and while my hypervisors were in maintenance I performed an update of all packages, including qemu-kvm and noticed the latest version
  (0.12.1.2-2.415.el6_5.8) in the CentOS repos still does not include live snapshot capability.

  Any suggestion on how to version my internal rebuild of qemu-kvm to prevent CentOS’s RPM being installed? My initial attempt is the following:

  mock -D “dist .el6_5” -D “buildid .local” -r epel-6-x86_64
  –with=rhev-features \
  –rebuild /home/treydock/qemu-kvm/qemu-kvm-0.12.1.2-2.415.el6_5.8.src.rpm \
  –resultdir=/home/treydock/qemu-kvm/rpms/local \
  –cleanup-after

  The resulting RPMs still contain the same version as CentOS’s builds. Do I need to extract the SRPM, modify the spec, then rebuild a SRPM
  built using the modified spec?

  Thanks
  – Trey

• Hello Trey,

  Yes, we have been discussing about provide this rebuild via CentOS Virt SIG. Thanks for joining this thread, this shows how required this rebuild is.

  Correct, sorry about that.

  What do you meant the same version? This command don’t bump the release, so it should generate the same rpm version. However, oVirt team already provides rebuilds from all qemu-kvm packages provided by CentOS enabling this feature, every day we check for new version of qemu-kvm package and rebuild if it exists, please go to:
  http://jenkins.ovirt.org/job/qemu-kvm-rhev_create-rpms_el6/lastSuccessfulBuild/artifact/rpms/

  ===== In case you would like to run a script ==WORKSPACE=”your-workspace-dir”
  for version in ‘6.5’ # ‘6.6’ ‘6.7’ ‘6.8’ ‘6.9’
  do
  QEMU_KVM_LATEST_SRC_RPM=`curl -s http://vault.CentOS.org/${version}/updates/Source/SPackages/ |grep -o -E
  ‘href=”([^”#]+)”‘ | cut -d'”‘ -f2 | sort -r | uniq | grep qemu-kvm`

  for qemu_kvm in ${QEMU_KVM_LATEST_SRC_RPM}
  do
  QEMU_KVM_LATEST_RPM=`basename ${qemu_kvm} .src.rpm`.x86_64.rpm
  if [ ! -f “${WORKSPACE}”/rpms/${qemu_kvm} ]; then
  wget -P “${WORKSPACE}”/rpms http://vault.CentOS.org/${version}/updates/Source/SPackages/${qemu_kvm}
  fi
  dist=’dist .el’
  build_version=${dist}${version//[\.]/_}
  if [ ! -f “${WORKSPACE}”/rpms/${QEMU_KVM_LATEST_RPM} ]; then
  sudo mock -D “${build_version}” -r epel-6-x86_64
  –with=rhev-features –rebuild “${WORKSPACE}”/rpms/${qemu_kvm}
  –resultdir=”${WORKSPACE}”/rpms –cleanup-after
  fi
  done done
  =============
  I would love to see this script or similar one (bumping the release?)
  running on CentOS SIG and after that executing createrepo command.

• Hello,

  I would like to continue this process in the SIG Virt. Any advice/steps which I should follow?

  Thanks!

• Douglas, we are not ignoring you. As it turns out there are quite a few unknown pieces related to the libvirt version for this SIG and there was also a discussion with Dan Kenigsberg at last week’s Hackathon. I don’t have the technical depth to go through your proposal. Added George. Lars

• Thanks for the feedback George and Lars. As we have several users requesting such feature and there is a new oVirt release knocking the door I would like to continue with KB or Johnny.

• KB / Johnny,

  Douglas is trying to get a package for qemu-kvm into the Virt SIG
  which has snapshotting enabled. It looks like he wants an exact rebuild of the RH qemu-kvm package with a single additional config option. Original instructions here:

  http://marc.info/?l

• Excellent — looking forward to it.

  Well I guess we have two options:
  1. Rename xen4CentOS to sigvirt-hv (or something like that — Virt SIG, hypervisor level)
  2. Create a new repo for qemu changes (kvm4CentOS? sigvirt-kvm?)

  On a practical level, this only affects the (I’m guessing) fairly small number of people who install two different hypervisors. For those people, #1 means opting into all the Virt SIG hypervisors when opting into one, and having to do something special to get the upstream version of one and the Virt SIG version of another; while #2
  means opting into each Virt SIG hypervisor separately.

  I suppose #1 would mean automatically getting for updated ancillary packages from xen4CentOS (ocaml?) when you just wanted to install qemu-kvm.

  Choosing #2 may mean a proliferation of repos; but since there will almost certainly never be more than 4 different hypervisors supported, that’s probably not too big of an issue. I’m not sure what else it might mean from a technical perspective.

  Anything I missed?

  I don’t really have strong opinions here. My personal inclination would be to just have one repo; but I could see how it might be weird to accidentally get updated packages related to Xen when you just wanted snapshotting for KVM.

  -George