libvirt 0.7.7 and Lucid

[Dustin Kirkland]

Sorry for my delayed response.  I have had IRC conversations with
Jamie, Thierry, and others about this, but I felt that I should roll
that up and respond inline below for the sake of posterity and
accuracy of the Wayback Machine years from now ;-)

On Thu, Mar 25, 2010 at 1:09 PM, Jamie Strandboge <jamie at canonical.com> wrote:
> Hi,
>
> For some work[1] I am doing, I did a merge of 0.7.7-4 from Debian
> unstable for Lucid and made it available in my PPA[2] (though it hasn't
> built yet-- people can grab the source and build it locally if desired).
> This package may be worth considering for Lucid, since there are many
> bug fixes and few new features in 0.7.6 and 0.7.7[3] (Lucid currently
> has 0.7.5).

Thanks, Jamie, for your sustained work on libvirt.  Your help is much
appreciated by the Ubuntu Server Team ;-)

> My testing with QRT[4], manually and the internal test suite (enabled by
> default in the build) shows that 0.7.7 is quite solid, though it does a
> couple of things differently:

Gotta love knowing that there's an upstream test suite ;-)

> 1. the setmem, setmaxmem and setvcpus virsh commands are for hotplugging
> memory and vcpus only. This was always the intent of these commands, but
> libvirt did not enforce it. Now it does and qemu-kvm doesn't seem to
> support hotplugging of memory and vcpus (at least with how libvirt
> interfaces with it). In practice, this probably won't affect many users
> as the recommended method has always been to use 'virsh define' and
> restart the guest. virt-manager appears to use 'virsh define' for
> setmaxmem, I don't know how eucalyptus deals with this.

I'm pretty sure that Eucalyptus does not use memory or CPU hotplug.  I
have CC'd Dan Nurmi on this note to definitely confirm.  Dan- every
Eucalyptus instance is started anew from a fresh libvirt xml file,
with mem/cpu/disk specified by the user's selection of machine-type,
correct?  And there's no hotplug of memory or cpu to running
Eucalyptus instances, right?

> 2. upstream decided to make setmaxmem go away entirely, and 0.7.7's
> implementation of setmaxmem is in the middle of this transition and
> doesn't seem to work at all. 'virsh define' still does though. I'm also
> not sure if this is a bug or new design, but while you can define a VM
> with different <memory> and <currentMemory>, when you start the VM,
> <memory> is always allocated for the VM and <currentMemory> is ignored.

Interesting.  I can't exactly say what this will affect.  Does the new
Virt-Manager handle this by disabling the prompt for both memory and
currentMemory?  This has been a source of confusion for Virt-Manager
users for some time now, so I think it would be good to simplify this,
if that's what they've done in Libvirt upstream.

> 3. libvirt seems to try to guard against hypervisor issues regarding
> detach-device and detach-disk. Specifically, these can be hot-plugged,
> but not hot-unplugged (libvirt claims the qemu-kvm hypervisor doesn't
> support detach of these):
>    <disk type='block' device='disk'>
>      <driver name='phy'/>
>      <source dev='...path.../device_disk.img'/>
>      <target dev='sdb' bus='scsi'/>
>      <alias name='scsi0-0-1'/>
>      <address type='drive' controller='0' bus='0' unit='1'/>
>    </disk>
>
>    <disk type='file' device='disk'>
>      <driver name='file'/>
>      <source file='...path.../device_disk.img'/>
>      <target dev='sdc' bus='scsi'/>
>      <alias name='scsi0-0-2'/>
>      <address type='drive' controller='0' bus='0' unit='2'/>
>    </disk>
>
> In 0.7.5, libvirt would try to detach these devices via the hypervisor,
> but in 0.7.7 it gives only a clear error message to the user. These QRT
> tests were built around upstream eucalyptus functionality, so this needs
> careful testing. Attaching and detaching virtio disks works fine in my
> testing.

Uh, oh...  Okay, this might be the big-nasty.  Eucalyptus does use
scsi hotplug for attaching EBS volumes.  Not sure about detach...
Dan, again can you advise us here?  Does Eucalyptus need to hot unplug
scsi disks from instances?

As for virtio, we're planning to file a blueprint for Lucid+1 and try
to get UEC using virtio for networking and disks.

> 4. libvirt chown's the disk files to root:root for people using
> qemu:///system. I don't know why it is doing this, but it is likely
> related to upstream changes (and assumptions) made for the DAC security
> driver. This seems like someone will need to at least investigate if not
> patch.

Hmm, okay, I think this is okay.  Looking at
/var/lib/eucalyptus/instances/admin/*/disk, these are owned by
root:root right now with libvirt 0.7.5-5ubuntu15 and eucalyptus
1.6.2-0ubuntu26, which is working.

> Beyond the above, preliminary testing indicates that 0.7.7 is quite
> solid. I would like to see this go into Lucid, since my apparmor work
> will be based on this and I'd rather not have to backport my work to
> 0.7.5. That said, I don't have the time to perform all the testing
> required, so if a commitment to testing resources can't be made for
> 0.7.7 by the server team and QA, then I recommend sticking with 0.7.5.

Right, so Jamie and I are going to spend most of Thursday this week,
dedicating time to testing libvirt 0.7.7, and specifically with UEC.

If we can quickly fix any regressions that we find, then I think it's
fine to upload libvirt 0.7.7 to Lucid.

However, if we encounter regressions with UEC and libvirt 0.7.7 which
are not quickly stomped, then I would probably recommend against the
new version for Lucid, as we've come so far with UEC and I'm quite
happy with its stability for 10.04 LTS at this point.

Is that reasonable?

:-Dustin