On 7/6/2012 11:16 AM, Yu Mingfei wrote: > On 7/5/2012 9:53 PM, Chris Evich wrote: >> On 07/04/2012 06:50 AM, Alex Jia wrote: >>> On 07/04/2012 05:32 PM, Yu Mingfei wrote: >>>> Hi Chris,Alex: >>>> >>>> Thanks for your comments. >>>> I am sorry about making you mistake "virt-edit" with "virsh edit". >>> NP. >>>> >>>> We need to test virt-edit here, >>>> and virt-edit modifies a file in a domain's img directly. >>> You mean to modify VM's disk path? or relevant XML configuration? >>>> >>>> However, create_new_vm() just renames a vm. >>>> Sometimes, we want to test a vm with different names, right or wrong. >>>> For example: 12345678, -vm1, #, and so on. (Please refer to patch 3/3 >>>> v2) >>> As I said, you may write 'virsh edit' or 'virsh define' case to test >>> VM's XML configuration change >>> such as changing VM's name, VM's disk bus, VM's network mode, etc. and >>> virsh_define() has been >>> encapsulated in libvirt_vm module, but if you just check different VM's >>> name, it's incomplete >>> for 'virsh edit' or 'virsh define'. >>>> >>>> To keep the vm1(main test vm) object safe, we decide to define a new >>>> vm object with a new name. >>>> All the new-name tests are based on the new vm object, and vm1 will be >>>> shutdown before new vm is defined. >>> In fact, if you don't change VM's disk path then the new VM will use >>> previous VM's disk image, if you have other >>> operation on the disk later such as writing data into the disk, it's not >>> safe. >>>> After the test, the new vm will be undefined. >>>> This is why this function is created. >>>> >>>> This function is also used in many other tests of ours. >>> Please show some examples if you don't mind, I'm interested in your test. >>>> And according to Cleber's suggestion, I put it into a seperate file >>>> libvirt_xml_utils.py. >>>> >>> IMHO, you may write some small functions to construct different VM's XML >>> in libvirt_xml_utils.py then >>> the module should focus on XML generation and shouldn't mix other API >>> functions such as >>> libvirt_vm.virsh_define(), libvirt_vm.VM(), etc. >>>> >>>> Maybe the create_new_vm() or its name confused your guys. How about >>>> the following idea ? >>>> >>>> Implement a vm.rename() function in libvirt_cm.py, doing the following >>>> things: >>>> 1. xml_bak = self.backup_xml() >>>> 2. self.undefine() >>>> 3. change the name in xml_bak into a new one >>>> 4. self.define(xml_bak) >>> s/xml_bak/new xml/. >>>> >>>> 5. self.name = new_name >>>> 6. remove xml_bak >>>> >>> If you use 'virsh edit' to do this, you don't need 2, 4 steps, 'virsh >>> edit' will automatically define a VM with new name, >>> of course, you need to remove<uuid>..</uuid> line from VM's XML via >>> 'virsh edit'. >>> >>> Anyway, if you want to implement a new vm.rename() in libvirt_vm.py, >>> it's okay for me, in addition, you also >>> need to write some cases to test it. thanks. >>> >>> Regards, >>> Alex >>> >> >> FWIW, I would like to take whomever named virt-edit / virsh edit to beat >> them with a dead tuna fish :D But onto the technical discussion... >> >> I'd like to know more about why you think you need a separate/backup VM >> from main_vm. The reason is, I wonder if it is really necessary or if a >> simpler way could provide same functionality. Can you explain more your >> thinking why you need separate VM? > As you know, many virsh commands will take a dom name or uuid or id, as well > as virt-edit. > For this reason, in our tests, we test both right and wrong name. > So in many cases, we separate a new VM from the main_vm, for example, -vm1, > #, 123456 and so on.
> >>> In fact, if you don't change VM's disk path then the new VM will use >>> previous VM's disk image, if you have other >>> operation on the disk later such as writing data into the disk, it's not >>> safe. > As Alex said, it risks damaging disk, but we have kept previous VM shut down > before new vm is started. > And we are sure our operation will not effect guest's normal running. > For example,we virt-edit "/etc/hosts" in a VM's disk,and we just add > a comment in it, like "#foo". > >> >> Assuming you don't need an entire cloned VM, how about just backing up >> (or snapshot somehow) the VM's disk image? This could be as simple as a >> os.copy() and os.unlink() when done. > Do you mean we shouldn't only create a new xml configuration, > and we should create a new VM with a new disk? IMO,clone a guest will take too much time,because we have too many cases for one command, if we put clone into out testcases,that will be redundance. But if we just separate/backup VM from main_vm, any problem but disk data's error can be solved by undefine and define. As we test both right and wrong value, unkown error may happen. It can't be more easy to define it with backup xml configration.^_^ In addition, It is impossible for us to damage vm's disk as I have explained. > >> >> or >> >> If you do need a separate VM, why not implement one/more of the libvirt >> clone features? Later, I'm sure somebody will want to test the clone >> features anyway, so this could possibly support additional testing. >> >> Thanks for the discussion! >> > -- Best Regards Yu Mingfei _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
