On 09/23/2013 07:17 AM, Hu Tao wrote: > On Tue, Apr 23, 2013 at 05:20:12PM +0200, Jiri Denemark wrote: >> On Tue, Apr 23, 2013 at 10:47:58 -0400, Cole Robinson wrote: >>> On 04/23/2013 08:06 AM, Martin Kletzander wrote: >>>> On 04/23/2013 01:56 PM, Guannan Ren wrote: >>>>> On 04/23/2013 07:37 PM, Martin Kletzander wrote: >>>>>> On 04/20/2013 10:09 PM, Cole Robinson wrote: >>>>>>> On 04/18/2013 03:47 AM, Guannan Ren wrote: >>>>>>>> v1 to v2: >>>>>>>> removed UPDATE_CPU flag checking >>>>>>>> renamed helper function name from reset() to clear_attrs() >>>>>>>> change the check box to be labeled 'Use host CPU model' >>>>>>>> remove the lightbulb icon, use tooltip instead >>>>>>>> reword the tooltip from Cole's >>>>>>>> remove the WARN image icon from UI >>>>>>>> >>>>>>>> Add a checkbox for 'host-model' mode and removed 'Copy host CPU >>>>>>>> configuration' >>>>>>>> button. >>>>>>>> >>>>>> Sorry for not catching this thread earlier, but IIUC, the 'host-model' >>>>>> doesn't make up for the button. XML is saved with 'host-model' then, >>>>>> right? >>>>>> >>>>>> Unfortunately, I can't see that easily right now as git virt-manager >>>>>> consistently crashes for me on all VMs and bare metal as well and I made >>>>>> that one of my priorities in order to speed up the bug hunt on it. >>>>>> >>>>> >>>>> Martin, I am using virt-manager git head now, it seems fine for me. >>>>> Is there anything wrong about 'host-model', I can't quite follow you >>>>> here. >>>>> >>>>> Guannan >>>>> >>>> >>>> I was just wondering if dropping the button isn't a bad idea, some guest >>>> OS might have problems when it is ran on different CPU, which is what >>>> might happen with host-model after destroy/start, but would be avoided >>>> with 'Copy host configuration'. I'm not saying 'host-model' is wrong, >>>> we definitely want the support for that. >>>> >>> >>> Hmm, how would host-model change CPU between destroy/start... like a libvirt >>> update supporting more flags? I didn't think about that, and it is >>> problematic. Libvirt goes to great lengths to try and preserve hardware config >>> for a VM across libvirt updates, host-model potentially throws that out the >>> window... >>> >>> Unless there's some clever way of getting around that it makes me think >>> host-model just doesn't fit in the UI. Trying to explain all the nuances of >>> this stuff in the current UI is impossible, so until we come up with something >>> different we should go with the safest bet, which is only providing the old >>> button press behavior. >> >> I agree that currently copying host CPU XML into guest CPU is safest >> than using host-model (which is just a shortcut for it but the config is >> not preserved after domain shutdown). However, host-model will be >> improved (hopefully soon) to provide more. And I think we (libvirt) >> should come up with something that would preserve the configuration, >> too. > > If we preserve cpu configurations when host-model is specified, what to > do with situations where the preserved configurations are different with > what host-model gets? > > - VM is copied to another host with a different cpu. The new cpu may > have all features in preserved configurations, or may not. Using > preserved configurations may fail to start VM. > > - VM is migrated to another host with a different cpu. Same as above. > Yes, without host-model handling those bits for us, virt-manager would need to explicitly handle it. Thankfully libvirt already has APIs that could help us here. But really I'm less concerned with cross host, non-uniform hardware migration compatibility than I am with a libvirt upgrade implicitly changing guest hardware. > - libvirt is updated to support more flags. It's better to update the > preserved configuration. > If libvirt supports more flags, we update libvirt, restart VM, guest sees the CPU is different... wouldn't this cause Windows reactivation? - Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
