Hide Forgot
Description of problem: Windows virtio-win drivers and Matahari Agents are provided by taking the Windows binaries and encapsulating them in Windows installers that are put onto ISO images inside of RPMs that can be installed on the virtualization host. virt-manager should be able to read these guest driver/agent ISOs from the host system and offer to update running guests by attaching the ISO as a virtual cdrom device to the guest and letting autorun (or smth like CDUpdater project) to update the guest drivers/agents.
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.