Bug 698676

As an aside, this functionality should also be provided outside of virt-manager as well via a cmdline tool and API.  This could be done as part of the overall effort to take the virt-manager/virtinst functionality and create APIs from that

Not really sure what this will entail from a dev stand point, but I'll take a stab at figuring it out for 6.2

Firstly, am I right in assuming that all these problems are windows only? Presumably linux guests will update drivers/agents through typical distro update process.

So from a high level perspective, what's the ideal user experience here?

Best case would be that nothing needs to be done host side, everything is updated within the guest. windows gets virtio driver updates from windows update, windows agents will check for updates from inside the guest, or an agent communicates with the host to easily transfer an update installer from host->guest. I assume these options have been considered at some point, any info on what the issues here are, or future plans?

Also, anyone have any idea how vbox or vmware update their windows
guest additions?

For initiating an update from the host, let's imagine a command line tool
virt-update:

1) First we want to know what OS the guest is, since there is nothing to do
for non-windows. This is hits up against the perennial problem of not tracking
OS info for a VM. If libvirt isn't tracking the guest OS, we can use
libguestfs in the local case to detect it. Barring that, have the user tell
us (virt-update --os-variant)

2) Next we need to know what updateable things are installed in the guest.
   Not sure what our options here are. We can probably glean some info from
   the guest XML: if we see virtio devs, we assume there are virtio drivers,
   if we see the matahari virtio serial port, we assume there is a matahari
   agent. Maybe we can use libguestfs to get some info from the guest.
   Barring that, allow the user to tell us.

3) Of the things from step 2), we want to know which of those things we
   have update media for. This requires some small db of known host paths
   for update media (virtio = /usr/share/virtio-win/virtio-win.iso). Allow
   the user to override

4) Of the things from step 3), we want to know what actually _needs_
   updating. Not sure how to get this info, short of libguestfs poking, or
   talking to an agent in a running guest. In case we can't tell, assume
   'needs updating'. Allow the user to override.

5) Now we have to get the update media into the guest. Simplest way is
   is just attaching an ISO. What if the guest doesn't have a CDROM already
   set up, is windows going to require a boot/reboot cycle just to install
   the new hardware? if we added a CDROM dev at the beginning of the update,
   is removing it after everything is said and done going to be fine for
   windows (not force a reactivation or anything)? do attach multiple CDROM
   at a time, or process updates serially? do we expect the virt-update
   command to have to be invoked for each thing that needs updating? are
   there alternate ways of getting this data into the guest, like using
   libguestfs to dump an installer in a known location and have it
   autostart on VM boot?

6) If we are attaching ISO media, we then need to boot the guest, and once
   its booted, redefine the VM with the media removed, so the media doesn't
   stay attached indefinitely. user probably needs to click through an
   install manually.

7) Ideally after the guest has shutdown, we would confirm the update was
   actually installed. Otherwise just assume it worked and exit.


So, ideally one could run

virt-update $vmname

it would determine what needs to be updated, either transparently queue those
updates to autostart at next VM boot, or manually connect media and start
the VM immediately, redefining the VM back to normal when it shutsdown.

In reality, the best we can probably do right now is
    virt-update $vmname --os-variant win7 --matahari
    virt-update $vmname --os-variant win7 --virtio

Which isn't too bad.

However to expose this nicely in virt-manager we really
want a lot of the above pieces, otherwise it's not even worth implementing
the UI if we are going to require users to tell us their OS and the pieces
that need updating, while we can't even tell them that there are new
if anything actually _needs_ updating.

Maybe it's worth just writing a kbase article about how to do this by hand,
and instead we focus on the first case I mentioned of doing theses updates
natively from the guest, or being able to seemlessly push an update from
the host to an agent in a running VM.

(In reply to comment #3)
> Firstly, am I right in assuming that all these problems are windows only?
> Presumably linux guests will update drivers/agents through typical distro
> update process.

This surely must be Windows only, since only Windows has such a
half-assed updated mechanism.

Perry, I'm assuming that these ISOs all get installed into
some host directory, eg. /usr/share/kvm-guest-updates/*.iso
Is any metadata available for them?  eg. What sort of guest
each update applies to?

> Also, anyone have any idea how vbox or vmware update their windows
> guest additions?

VirtualBox does this using an over-the-internet update mechanism,
entirely driven from inside the guest.  VMware looks like you have
to do it manually.

> For initiating an update from the host, let's imagine a command line tool
> virt-update:
> 
> 1) First we want to know what OS the guest is, since there is nothing to do
> for non-windows. This is hits up against the perennial problem of not tracking
> OS info for a VM. If libvirt isn't tracking the guest OS, we can use
> libguestfs in the local case to detect it. Barring that, have the user tell
> us (virt-update --os-variant)

libguestfs is pretty reliable.  You just need to check if
g.inspect_get_type() == "windows".  Example code is here:
http://libguestfs.org/guestfs-python.3.html#example_2__inspect_a_virtual_machine_disk_image

> 2) Next we need to know what updateable things are installed in the guest.
>    Not sure what our options here are. We can probably glean some info from
>    the guest XML: if we see virtio devs, we assume there are virtio drivers,
>    if we see the matahari virtio serial port, we assume there is a matahari
>    agent. Maybe we can use libguestfs to get some info from the guest.
>    Barring that, allow the user to tell us.

This is similar to what we get out of the guest for virt-v2v.
It's not trivial, but it is at least reliable for us to read
out any part of the Windows Registry, even from running guests,
and that should contain the information needed.  Example code:

https://rwmj.wordpress.com/2010/11/28/use-hivex-from-python-to-read-and-write-windows-registry-hive-files/
http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/Windows.pm;hb=HEAD

> 3) Of the things from step 2), we want to know which of those things we
>    have update media for. This requires some small db of known host paths
>    for update media (virtio = /usr/share/virtio-win/virtio-win.iso). Allow
>    the user to override
> 
> 4) Of the things from step 3), we want to know what actually _needs_
>    updating. Not sure how to get this info, short of libguestfs poking, or
>    talking to an agent in a running guest. In case we can't tell, assume
>    'needs updating'. Allow the user to override.

Perry, I agree with Cole that some sort of metadata is required
on the host side.  It could be something simple like:

  /usr/share/kvm-guest-updates/virtio-drivers.iso
  /usr/share/kvm-guest-updates/virtio-drivers.info

where the *.info files contain roughly:

  - description of the ISO contents
  - what type(s) of guests the update applies to

> 5) Now we have to get the update media into the guest. Simplest way is
>    is just attaching an ISO. What if the guest doesn't have a CDROM already
>    set up, is windows going to require a boot/reboot cycle just to install
>    the new hardware? if we added a CDROM dev at the beginning of the update,
>    is removing it after everything is said and done going to be fine for
>    windows (not force a reactivation or anything)? do attach multiple CDROM
>    at a time, or process updates serially? do we expect the virt-update
>    command to have to be invoked for each thing that needs updating? are
>    there alternate ways of getting this data into the guest, like using
>    libguestfs to dump an installer in a known location and have it
>    autostart on VM boot?

Example code:
https://rwmj.wordpress.com/2010/04/29/tip-install-a-service-in-a-windows-vm/
You can only do this when the guest is powered off.

(In reply to comment #3)
> Firstly, am I right in assuming that all these problems are windows only?
> Presumably linux guests will update drivers/agents through typical distro
> update process.

Correct, Windows only.  Other non-Windows guests will use their standard update mechanisms
 
> Best case would be that nothing needs to be done host side, everything is
> updated within the guest. windows gets virtio driver updates from windows
> update, windows agents will check for updates from inside the guest, or an
> agent communicates with the host to easily transfer an update installer from
> host->guest. I assume these options have been considered at some point, any
> info on what the issues here are, or future plans?

I don't know if there are any concrete plans to put virtio-win drivers into Windows update.  Even if we do get virtio-win drivers in Windows Update, we still have guest agents (Matahari, Spice, etc) that will never be in Windows Update so we'll have to be able to update them by pushing updates via host/guest mechanism
 
> 5) Now we have to get the update media into the guest. Simplest way is
>    is just attaching an ISO. What if the guest doesn't have a CDROM already
>    set up, is windows going to require a boot/reboot cycle just to install
>    the new hardware? if we added a CDROM dev at the beginning of the update,
>    is removing it after everything is said and done going to be fine for
>    windows (not force a reactivation or anything)? do attach multiple CDROM
>    at a time, or process updates serially? do we expect the virt-update
>    command to have to be invoked for each thing that needs updating? are
>    there alternate ways of getting this data into the guest, like using
>    libguestfs to dump an installer in a known location and have it
>    autostart on VM boot?

I think we can keep this simple.  If the guest has a virtual CDROM drive that you can attach an ISO to, great.  Update away.  If it doesn't have a virtual CDROM device, then you can't get updates.

By default we should be creating all guests with a virtual CDROM right?  If not, then we probably should.
 
> 6) If we are attaching ISO media, we then need to boot the guest, and once
>    its booted, redefine the VM with the media removed, so the media doesn't
>    stay attached indefinitely. user probably needs to click through an
>    install manually.

If the device is present, can't attaching an ISO to it be done w/o guest reboot? 
 
> 7) Ideally after the guest has shutdown, we would confirm the update was
>    actually installed. Otherwise just assume it worked and exit.

Most of these updates won't require a guest reboot... if they do then we're probably doing something wrong.  (Thinking agents here not virtio drivers)
 
> So, ideally one could run
> 
> virt-update $vmname

Do we want a new cli tool here, or should this just be part of the libvirt GObject API that DanB has been thinking about?  If so, then ideally this is just exposed via smth like:

virsh update-guest $vmname
 
> it would determine what needs to be updated, either transparently queue those
> updates to autostart at next VM boot, or manually connect media and start
> the VM immediately, redefining the VM back to normal when it shutsdown.

I think the default should be to do the update immediately by hotplugging an ISO into the virtual CDROM and running the updates.  If the updates require a reboot, we just let the user of the guest respond to a "Your OS needs to be rebooted before all updates can be completed" message that normally happens in Windows when you do updates that require a reboot to complete
 
> In reality, the best we can probably do right now is
>     virt-update $vmname --os-variant win7 --matahari
>     virt-update $vmname --os-variant win7 --virtio
> 
> Which isn't too bad.

Agreed, it's a good first step
 
> However to expose this nicely in virt-manager we really
> want a lot of the above pieces, otherwise it's not even worth implementing
> the UI if we are going to require users to tell us their OS and the pieces
> that need updating, while we can't even tell them that there are new
> if anything actually _needs_ updating.
> 
> Maybe it's worth just writing a kbase article about how to do this by hand,
> and instead we focus on the first case I mentioned of doing theses updates
> natively from the guest, or being able to seemlessly push an update from
> the host to an agent in a running VM.

Updates from the guest won't work.  The only thing we _could_ get into Windows Update would be the virtio-win drivers.  So Windows Update is not viable as a general purpose solution.

So the only other options are:
* agents update themselves directly from the guest
* agents are updated via host push

Agents updating directly inside the guest is a lot harder than you think... What do these agents talk to to get updates?  We don't have any infrastructure to be able to download Windows exe/msi's like we have for RPMs via RHN/yum. 

So that really only leaves us with the host/guest push mechanism I think

> Perry, I'm assuming that these ISOs all get installed into
> some host directory, eg. /usr/share/kvm-guest-updates/*.iso
> Is any metadata available for them?  eg. What sort of guest
> each update applies to?

The two I know of right now are:
/usr/i686-pc-mingw32/sys-root/mingw/share/matahari/matahari-0.4.0-win32.iso
/usr/share/virtio-win/virtio-win-1.2.0.iso

No metadata other than what is provided in the rpm database, but that actually might be sufficient since we can determine the version of the software from that.

> Perry, I agree with Cole that some sort of metadata is required
> on the host side.  It could be something simple like:
> 
>   /usr/share/kvm-guest-updates/virtio-drivers.iso
>   /usr/share/kvm-guest-updates/virtio-drivers.info
> 
> where the *.info files contain roughly:
> 
>   - description of the ISO contents
>   - what type(s) of guests the update applies to

Can't we put this metadata in the rpm database?

For the two questions, rpm -qi for virtio-win shows:
Description :
VirtIO para-virtualized Windows(R) drivers for 32-bit and 64-bit
Windows(R) guests.

I'm not sure we need something more detailed here, do we?

(In reply to comment #6)
> Can't we put this metadata in the rpm database?
> 
> For the two questions, rpm -qi for virtio-win shows:
> Description :
> VirtIO para-virtualized Windows(R) drivers for 32-bit and 64-bit
> Windows(R) guests.
> 
> I'm not sure we need something more detailed here, do we?

We can do.  Be nice if it was a bit more machine-readable
than it is at the moment.

Note that virt-v2v contains a bunch of rules which map the
Windows OS (sub-)type to the correct virtio driver to install,
since the information currently in the rpm metadata is
*not* sufficient ...

http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=v2v/virt-v2v.conf;h=1b94c7673d9b85dffd97abdee3e7ac2b4a3f113d;hb=HEAD#l143

> Note that virt-v2v contains a bunch of rules which map the
> Windows OS (sub-)type to the correct virtio driver to install,
> since the information currently in the rpm metadata is
> *not* sufficient ...
> 
> http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=v2v/virt-v2v.conf;h=1b94c7673d9b85dffd97abdee3e7ac2b4a3f113d;hb=HEAD#l143

Ugh.  I was under the mistaken impression that the virtio-win iso contained a nice installer program that would sort all of this out for you.  If we want to make 'auto updating of the drivers' work properly I think we need a NSIS installer bundled on the ISO that can be run in silent mode to update the drivers and it can have the logic for 'use this .dll/.sys file for the specific version of Windows I'm running on'

@yvugenfi: what are your thoughts on the discussion on this bz?

I posted private comment. If you don't see it please notify me.

Moving this virt-manager bug to 6.3 since nothing is really ready yet.

Infrastructure to use Difx (http://msdn.microsoft.com/en-us/windows/hardware/gg463103) and MS provided installer dpinst.exe (http://msdn.microsoft.com/en-us/library/ff544842.aspx) was added to latest virtio drivers.

Additional customization of configuration XML file is needed if this will be a choice for installer provided to users.

While there's lots of useful info in this bug, tracking it against virt-manager  upstream is pretty much guaranteed to not generate a solution in the short/medium term, so I'm closing it. If this is still a priority to anyone, I'd recommend reopening this bug and maybe filing against RHEL distribution so we can figure out where the tool should live first and foremost.