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? 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. 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! -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
